S_TABU_DIS Table Auth Group &NC& in SAP Delivered Defaults

[Former Member]

Hi All,

I'm currently working on an implementation where there has been very little historical control over table access, and as a result there is a large number of roles containing display and / or change activity on S_TABU_DIS for table auth group &NC&.

I am about to begin a project which will attempt to bring the provision of &NC& in our roles back under control. I am not expecting this to be an easy or enjoyable task, but fortunately we have a relatively small number of roles and a small number of custom transactions, so I think it will at least be possible, especially with S_TABU_NAM now available to us.

So, one early step that I decided to carry out was to check if any role admin had erroneously updated SU24 defaults to propose S_TABU_DIS with a table auth group of &NC&. The intention was to correct these first, so that when we have eventually got ourselves clean, we would not then have the &NC& creeping back in again.

And here is where I noticed a large number of transactions (100) have SAP delivered default values for S_TABU_DIS with table auth group &NC&. Our SAP default data is quite well up to date, so I am wondering why SAP proposes this value, and would really appreciate any help you can give me with this.

None of our roles actually contain any of these 100 transactions, so they are not causing me any problem, but I would like to know why the SAP proposals are still for &NC&.

Thanks for any comments.

Message was edited by: Will Dunkerley - spelling error

[Former Member]

Hi Will,

please check out SAP Note 1434284 and read below topic carefully inside solution

3. Scenario II: Table access control via table names or

table authorization groups

Also S_TABU_NAM is not by default activated. If you chose to use both S_TABU_NAM and S_TABU_DIS then you have to activate S_TABU_NAM=Y in SU24.

I guess, S_TABU_NAM usage is recently started for EHP5 etc.., hence SAP has not completely stopped &NC& in S_TABU_DIS. In later stages, they might de-activate &NC& completely.

Best Regards

Imran

[Former Member]

HI Imran,

Thanks for this - the note is very helpful.

[Former Member]

Hi,

Why not we go ahead and assign the separate authorization group for the customized table to avoid confusion and avoid security issues.

[Former Member]

.... (note editied and some content deleted because it was concerning some other message that was also deleted...)

The question is why are so many SAP standard transactions maintained in SU24 with &NC&, and in some cases with 02 change activity by the standard SAP defaults.

[OttoGold]

Hi Will,

maybe you want to join me with this one:

http://scn.sap.com/community/security/blog/2012/06/20/su24-related-oss-notes-with-sap-support

how is life by the way? Working or managed to go leave for some vacations?

Cheers Otto

[Former Member]

Hi Otto,

I've been following your blog with great interest for a couple of weeks now - but I decided to start this thread rather than commenting on your blog, because I figured there was probably a good reason for SAP to specify these defaults.

If you think they should be corrected, I would be very happy to report them to SAP and update you on the progress; I would welcome your opinion.

Life is great thank you - yes, I'm working but I had a few weeks vacation before I started this role, so I can't complain. Hope Julius isn't making you guys work too hard 😉

Cheers,

Will

[OttoGold]

Hi Will,

we must take small steps, I think. I am now busy reporting &NC& that have been replaced by real groups, but &NC& wasn`t replaced in SU24. &NC& is not a simple thing.. they can start stories like "it will affect everybody" (because now everybody is surfing on &NC& because of one out of dozens in menu the pull it in)...

I don`t know frankly. Maybe we can ask for opinion...?

We must reduce the evil but in a politically correct way. I am quite successful with my OSS messages about SU24, I am updating the blog with every message I get/ every correction I am informed about... but it is donkey`s work. I could use a thousand donkeys to join me:))

I have 172 items on my SU24 buglist and all our lowbrainers so there should be no argument about it. With more serious things we need to stand the ping-pong:))

Have you opened any Su24 related notes yet?

Cheers Otto

[Former Member]

Proposing the value &NC& in SU24 clearly means that the developer of the table or the creator of the transaction code did not RTFM..  🙂

NC = Not Classified = No intention to be displayed directly as table. Some folks think it means "Not critical"...

Granting &NC& is another topic. Once you have given it, the cat is out of the bag and you are in most cases wasting your time in trying to get it back again. Particularly as they use SE16 all they could give you is a list of tables and views --> so you stand a chance using S_TABU_NAM.

Best is never to allow &NC&. Otherwise you will never get it back again and the number of tables without groups assigned and views created will grow and grow.

For this same reason you should not use the edit function of SE16N. You create a mess of the authorizations as well because folks don't create and authorize on views anymore and it is a big clean-up to get it all straight again in Se11 and PFCG.

That is my opinion on this.

Cheers,

Julius

[OttoGold]

That means we want all &NC& proposals out of SU24, is it so. How can we get there in your opinion? Can we classify this as a bug? It gives hell a lot of access and yes, somebody was lazy, but can one report this on OSS with a statistical chance to "win the case"?

Cheers,

Otto

p.s.: could NC means = developer not competent?

[Former Member]

Hi Otto,

Yes, I have opened a message about the 100 &NC& defaults in our system. However, SAP are not very quick to respond to messages from the customer that I am working for , so it may be some time before I get an answer.

But yes, I think you are right that it is easy for SAP to reply that it would affect many people - and they would be correct, although that does not make it right.

But maybe by highlighting the existence of them we can get them resolved in future. I will add a post to your blog as soon as I get a reply.

[Former Member]

Julius von dem Bussche wrote:
Best is never to allow &NC&. Otherwise you will never get it back again and the number of tables without groups assigned and views created will grow and grow.

Hi Julius,

This is why I have a problem with SAP defaults containing &NC& - it only takes one role admin to misunderstand the meaning of this value and to accept the proposal, and then you have it out in the wild in your production system. By having &NC& in their defaults, SAP are contributing to the problem.

I like Otto's definition of &NC&

[OttoGold]

I try to always add a link to my SU24 blog here to explain what I am doing, sometimes the support people don`t understand the whole picture. I hope my blog explains I am not a troublemaker (ok, I am, but for public good:)) and try to help.

It is also very important to point out the fact they are much better with support if you explain how do you want the thing to be fixed. I am not sure message like "please remove all &NC&s because I am allergic" can work. One should also point out that the transaction that gives access to the table should be removed (which is not going to happen), because &NC& means "don`t access" (as Julius pointed out) or the table should be moved to a group so the access can be restricted. Removing &NC& does not make things 100% right, I think.

Good luck with your messages I am looking forward to the update.

Cheers Otto

[Former Member]

Haha, I have just this moment had a reply from Bernhard - I think maybe he has been reading this conversation.

SAP wrote:
26.07.2012 - 14:00:24 CET - Reply by SAP 


Hello Will,

I understand your requirement, but:

as not every customer has activated the s_tabu_nam functionality
yet, we cannot change that default proposals in SU22.
But with the additional s_tabu_nam check you can assign appropriate
rights to 'normal' users after removing s_tabu_dis from their
profiles.

If you have doubts regarding the admins who maintain the
authorizations, I suggest to remove that proposals in SU24....

Maybe in some time, when s_tabu_nam has become state of the art,
the s_tabu_dis proposals can be replaced in su22 (after cleaning up
TSTCA settings...)


Best regards
Bernhard

Bernhard Hochreiter

So you were correct in predicting the response Otto. I attached a download of our customer tables for all transactions maintained with an &NC& proposal, so I think I gave as much information as I could, and Bernard certainly seems to understand the problem.

However, I am going to reply asking SAP to tell me what tables I should include in S_TABU_NAM, rather than having to reasearch it all myself. I just did this for 140 custom programs and I'm tired of looking at ABAP code... And anyway, since SAP will have to provide this data when S_TABU_NAM becomes the standard, then they might as well start the work now. Maybe it will help ensure that all developers RTFM in the future.

I also do not agree with the comment about having doubts about role admins - yes, I would expect a role admin to know what &NC& meant, but we all know plenty who do not, and to expect a less able role admin to overrule a default value proposed by SAP seems to me to be a little unfair.

So I will reply to Bernhard and update your blog on his reply

[Former Member]

SAP would have to deliver the SU22 data with a support package (no upload would be made available I think) because the views which have these &NC& groups would have to be assigned to proper values at the same time.

Some applications might not have a concept for that yet (there are only 4 characters to play around with, and you should have seperate groups for customizing, master data and transaction data) so the SP would have to wait for a concept to be developed first by the application owner.

However, customers would only run SU25 to replace the &NC& with the real values at release changes, so chances are very good that you will not get these SU22 values delivered earlier than the next major release change.

At the latest then you will have S_TABU_NAM available and working stabily anyway...

So making a big fiasco out of &NC& now is very unlikely to happen, in my opinion.

My suggestion: if any views are missing auth groups AND are used in production by end users --> assign the views a group value and maintain SU24. When S_TABU_NAM becomes available for you, add S_TABU_NAM to SU24 and deactivate the S_TABU_DIS in SU24 or the role (if TSTCA lets you!). If they are accessing tables directly without views, give them a better reporting option than milling around in single fields of tables unclassified tables.

Cheers,

Julius

[Former Member]

Thanks Julius,

S_TABU_NAM is already available to this customer, so I can fix this for myself fairly easily. But I wanted to highlight the presence of &NC& in SU22 anyway, and this seemed the best place to do it.

It's been a good conversation

[Former Member]

When you save in SU24, you sometimes see a popup stating that data has been automatically corrected.

That will be your problem, in addition to the correct auth group proposal being &NC& because that is what is in SE54 of the view.

What else do you want to maintain in SU24 than the correct value, which is needed but you do not want it in the auths? Hard stone to break..

One thing is for sure --> wait for S_TAB_NAM to further stabalize and maintain only those groups in SU24 (and SE54) which you infact use and realy need. For the rest you are waiting your time. In many cases you can find better reporting options and ween them of se16 etc with table "queries", if you can push that through.

For this you need either a big hammer to push it through, or, tell them to ugrade and head for the beach to meditate about the easiest migration plan in the mean while... 🙂

Yes, indeed an interesting discussion. I am a bit surprised that one see's recommendations to use S_TABU_NAM here but is also seems that not many folks have actually made intense use of it.

Cheers,

Julius

[OttoGold]

Dear sir,

you obviously have no idea. That`s why I had to report this comment as abuse. Please read through the notes your mentioning to "get" what they say. Then we can try again maybe. Until then please don`t touch any authorization objects and report yourself to authorities within your company.

Have a nice summer,

cheers Otto