Today in the Office... (Security)

[Former Member]

Problem: Some users were able to maintain several tables using TCODE SE16 in a production system. For example currency exchange rates.

Solution: Take away TCODE SE16, create a custom TCODE that executes a custom coded SE16 version that does not allow modification of data.

Some highlights of the discussion:

• “We will raise a message with SAP because this is a bug. SE16/SE16N is a data browser and should not allow modification of data”
• “Users got activity 02 through some other role”
• "Some tables are maintainable in production. No idea why"
  
• “User needs maintenance permission of another table of the group, so he got it for all tables”

[VeselinaPeykova]

Interesting... the question 'why users have access to SE16N in PRD' never came up...

It must be a lot of fun to work in your company... love the discussion highlights and the brilliant solution.

[yakcinar]

Hello,

As my experience and in my opinion authorization group is not enough for SAP table authorizations.

There are alot of Non-classified tables (&NC&) tables including SAP objects and customer objects.

If you give &NC& auth to anyone and SE16 it means that that person can display all non-classified tables.

There must be an authorization with table names.

I also created ZE16 tx with Z_TABU_NAM auth object. So I can give table display authorization using table name.

AFAIK SE16N is restricted anymore and cannot be used for changing tables.

Regards,

Yuksel AKCINAR

[VeselinaPeykova]

AFAIK SE16N is restricted anymore and cannot be used for changing tables.

There are companies running outdated systems, where note 1420281 is not implemented.

Anyway, I can't think of a business scenario where users need SE16N.

Support consultants or developers - ok, they need SE16 in PRD from time to time, but I thought they get only display authorizations (for any kind of stuff) out of Firefighter (or whatever SAP calls it now).

[Former Member]

Veselina Peykova wrote:

I can't think of a business scenario where users need SE16N.

This does exist and is frequently caused by tables without maintenance views and transport connection. Mainly caused by the convenience of SE16N itself.

A means to an end.

Cheers,

Julius

[VeselinaPeykova]

I am not a security expert or a developer, but this seems rather sloppy.

If it is just to display some data to a business user, even a functional consultant knows how to create and assign queries and add authorization checks (if you can't afford an ABAPer).

And if the business has to maintain stuff in PRD in z-tables- is it really that hard to create a transaction, which calls a maintenance view and assign it to a role?

I've never seen SE16 granted to the business in any system... still digesting the idea... especially as for exchange rate display/maintain there is absolutely no reason to give SE16N - TCURMNT works just fine (in my sandbox table TCURR is the only one with authorization group FB32).

This means - either the FI consultant was not aware of a common standard transaction or somebody granted SE16N for all authorization groups... In both cases this is scary, but in the second case - I wonder if the users found PA0008/PA0015