Access to Transaction SE16 on Production

[Former Member]

Hello All - Have a question with SE16, appreciate your thoughts?

In my company all users have access to SE16 on production system, HCM project is in pipeline..

1) Is access to SE16 on production system "Critical" ? (even though its "read only")

2) If I assign SE16 to users on production, can I restrict them to only few tables?

3) I want to show my management good practices followed across in industry, do you know where I can find them any knowledge sites?

We have implemented SCM Demand Planning and I came across a ticket requesting SE16 to all users on production system.

Thank you.

[Former Member]

> 1) Is access to SE16 on production system "Critical" ?

Not really if the user does not have any S_TABU_DIS access, but it's reputation precedes it as a "developer tool" and if the user does have S_TABU_DIS then they will bypass most of the other application security for granular access to the tables (which might also be the wrong table, but that is a different topic).

Generally, over-emphasized fear of S_TCODE = SE16 is often accompanied by badly designed security concepts and insufficient understanding of the system.

> (even though its "read only")

It's not read only, depending on the authority of the user for S_TABU_DIS and S_DEVELOP.

If the user has the correct activity access to change tables, then they will do so to a few hundred of them which permit it in their technical attributes, by entering the "Entries" option before hitting "Enter" in the initial screen.

In the debugger this is also possible by changing the CODE field.

> 2) If I assign SE16 to users on production, can I restrict them to only few tables?

You can restrict them to groups using S_TABU_DIS and even to relevant fields of tables using S_TABU_LIN to some extent (if activated).

> 3) I want to show my management good practices followed across in industry, do you know where I can find them any knowledge sites?

This one here isn't too bad...

Common practice is to avoid SE16, but more important is to get the S_TABU_DIS right in my opinion.

> We have implemented SCM Demand Planning and I came across a ticket requesting SE16 to all users on production system.

Then you will have another reason to have more granular control on S_TABU_DIS.

Often the choice of transaction is incorrect, and in the case of the SE16* transactions it is also true.

Butr relying on S_TCODE only to protect your tables is a big mistake...

Cheers,

Julius

[Former Member]

Hi Anil,

The table level security can be maintained through authorization groups.

The primary method for restricting direct table maintenance is through the authorization object S_TABU_DIS and S_TABU_CLI.

1. S_TABU_DIS controls access at the table level via transactions SM31, SE15, and SE16; along with IMG level access

2. S_TABU_CLI grants permission to client independent tables.

You can find the link between authorization group and table in table TDDAT.

You can restrict access to group of tables by creating new authorization group and assigning it to the table.

You can assign this new authorization group through table SM30 and SE54.

Be cautious while handling table level security as this effect user when they will try to execute the tcodes which updated the table directly.

Regards,

Smeja

[Former Member]

Hi

I think it's important to know that auth groups for tables (in table TDDAT) are not unique for each table. This means that by restricting the access to one specific group it means that the access is open for ALL tables containing in that group

There are thousands of tables unprotected! Good luck

Nadia

[Former Member]

> There are thousands of tables unprotected! Good luck

That is not correct. The system will replace an empty auth-group in the table's DDIC attributes with a symbolic one called '&NC&' => meaning "Not Classified".

This can be understood as "not worth protecting" but a better interpretation is "not intended to be viewed directly" ....

Unfortunately, the view maintenance development tools will default this value when creating a view... I never understood why this is the case, because it is a contradiction.

Cheers,

Julius

[Former Member]

Hi Anil,

I've found that the safest way to manage my environment has been to grant access to transaction SE17 which is display only to the general users, and then grant SE16 to select users.

Also, the above posts are absolutely correct in that you have to be careful managing access via S_TABU_DIS, and it's highly risky managing your tables via S_TCODE.

Hope this helps.

[Former Member]

I had some idea about this objects but was not really sure the functionality, I really appreciate your ideas and your ideas will not go free I gave you $..let me do some research around these objects and will talk to you soon.

Thank you.

[Former Member]

>

> I really appreciate your ideas and your ideas will not go free I gave you $..
> 

Are they buying points on eBay already?

Let us know how your tests work out.

Cheers,

Julius

[Former Member]

Hi Julius - I was thinking on what you all suggested:

To start with how would I identify sensitive tables? It may sound silly, but how to start like what tables should be protected from tampering. Could you suggest me a path to get this things in to play.

For end users I can make a list of tables they will need and restrict them with groups, but how about IT users how will I protect the tables and what tables should I protect?

We have no HCM in our landscape!

It seems like got in to a play with no game plan, any suggestions from Gurus/Experts is much appreciated.

Thanks in Advance!

[Former Member]

Thanks All

[jim_donahue]

One inconvenience we have with SE16 restricted is that we cannot browse contents from SE11 as it is hard coded in SE11's PAI XX_COMMS. Are there any newer versions where this can be configured?