S_TABU_DIS and non-classified tables (&NC&)

[Former Member]

Does anyone have any insight into providing display access to non-classified tables (&NC&) via authorization object S_TABU_DIS. Our specific issue at this point is via SE16 with display only access. Our testing has shown that tables without any authorzation group assigned required a value of (&NC&) in field DICBERCLS in order to make SE16 work. The challenge is that we have a number of custom tables without any authorization group which means we need to provide &NC&. If we do this the users automatically get access all the non-classified tables.

[Former Member]

>

> Does anyone have any insight into providing display access to non-classified tables (&NC&) via authorization object S_TABU_DIS.  Our specific issue at this point is via SE16 with display only access.  Our testing has shown that tables without any authorzation group assigned required a value of (&NC&) in field DICBERCLS in order to make SE16 work.  The challenge is that we have a number of custom tables without any authorization group which means we need to provide &NC&.  If we do this the users automatically get access all the non-classified tables.

If there is an intention / requirement to display a table, then the best practice way is to create a view in SM30, assign an auth group to the table via SE54, and then create a transaction in SE93 to call that view. Or search for an existing one.

There are parameter transactions; basically the same thing as SM30.... except the users dont know that. You can also add your own additional checks on other auth objects.

''&NC&' means "not classified" as there is no requirement to control the access for the data browser transactions, because there is no intention that a user should display or change them in your concept.

Cheers,

Julius

[Former Member]

Hi Ed,

Julius is right

Create authorization group in SE54 and transport it till prod

then add this group in S_TABU_DIS in proper role (where SE16 display access is given)and transport the role

hope this helps

[Former Member]

While both of the first two posts confirm my assumptions of what the proper approach is, we're still stuck with the original question. Is there any risk / harm including &NC& in a role that provides display access to users via SE16. The role in question is only assigned to support people in our organization and not end users.

[Former Member]

I think it would depend. Do you have HR implemented and do you have custom HR tables ? These

custom HR tables would be accessible since it would default with &NC&.

As a practice, I have required all custom tables to be defined with a custom auth group. This has

been made a part of our development standards. The custom auth group design can be anything

you want. It can be as simple as tables that are restricted and tables that are not.

[Former Member]

Ed,

If you mean SARBOX, then you should have a problem.

If you have VIRSA installed in your system, try to run it to this specific role, and you'll see that VIRSA will report as a problem.

The best way to go is to follow Julius' suggestion.

Any questions please let me know.

Best Regards,

Lucas

[Former Member]

hi Ed,

I would suggest you, it is always a good practice to assign the authorization group to table from security point of view.even if the role is assigned to support.

If you want to do this, whatever ztables are created please assign authorization group to them.

There may be some tables where business doesn't want support to see the values, bu they will be visible if &NC& is given to support.

Hope this helps