SE16 table access

[Former Member]

Hello all,

I am currently building SAP support team roles for each of the functional areas, HR, FI, Property etc...

The team needs access to various tables. I am going to create new auth. grps. and add the required tables to the new grps..

These would be defined in the Auth. Obj. S_TABU_DIS in the new roles.

Questions:

Is this how you give SE16 table access in your organisations or do you have any other ways of doing this?

Do you use a naming convention for the new Auth. Grps. i.e with a Z prefix?

Thanks in advance..

[jurjen_heeck]

For support teams I suggest that SE16 is not too big a problem. Do indeed mind S_TABU_DIS. An alternative could be SAP query (SQ01, SQVIU etc) as these transactions do not provide any change options.

Starting the auth. group name with a Z is always good. That way you know the'll never be overwritten or changed with upgrades.

[Former Member]

Hi Gorasia,

instead of giving SE16 you can give SE17 it is only dispaly

thanks

kishore

[Former Member]

Hi Kishore,

> instead of giving SE16 you can give SE17 it is only dispaly

What would the difference be?

Regards,

Julius

[Former Member]

Hi Julius,

i preferred because SE17 is purely display transaction

SE16 can give change and create access also

if i have access to S_TABU_DIS with any of the activity 02 or 01

thanks

kishore

[Former Member]

SE16 will only allow create or change access if user has DEBUG and REPLACE or the table is specifically set to allow maintenance (example would be KBEROBJ)

SE17 looks like it is display only but could possibly be manipulated by DEBUG/REPLACE??

[Former Member]

ONE thing i miss in this discussion is to create custom transactiossn (variant of SE16) as that is a far more secure solution that grating access to SE16 or 17, Whil it is not possible to go to anyother table than the one assigned to teh custom transaction.

S_TABU_DIS is secure by itselve, but there are many roles in the system that allow acces to other tables and if the users has one of thes roles as well, all your good security intentions are simply bypassed!

[Former Member]

Parameterised tx is always a good bet, though might be overkill for project team in Dev & QA environment

[Former Member]

The problem I have with "using lots of transactions", is that it is often used as a front for relaxing the S_TABU_DIS access.

Regardless of the transactions, if the person can break out of their S_TCODE restrctions (or stop a parameter transaction while processing the screen which is to be skipped), then they can also toast your security with broad S_TABU_DIS.

If you give functional folks SE11 for example, then you know exactly what they have (via S_TABU_DIS / S_TABU_CLI) and they know it as well. You could try to restrict org values within the tables (using S_TABU_LIN) as well.

Of course, "using lots of transactions" can be very usefull to further restrict the appearance on the front end, for maintaining check indicators (SU24), and building intuitive menus.

My 2 cents,

Julius