S_TABU_NAM and restricting access to 2 tables within a group

[Former Member]

Hi,

I have been reading all of the threads on the site, but no-one appears to have the same issue that I am finding. I wish to restrict access to 2 specific tables within the group FA - the group also includes a further 936 tables (probabaly many of which are not used within my company) for txn codes SE16, SE16N, SE17, SM30, SM31 and SM34.

I have activated S_TABU_NAM and deactivated S_TABU_DIS - but this means now that I have to add the 936 tables to S_TABU_NAM, as I do not know which are active and which are used by the business.

If I put in a wildcard for the tables in S_TABU_NAM, I could potentially open up tables which the users are definately not allowed to see, such as HR tables for example (I know that I could change the wildcard not to include PA tables, but there may be some tables that I am not aware of. If I only add tables into S_TABU_NAM, that I think are required, I could potentially upset my user community, as I may miss a table (or several) that they require access to.

The system logs are only available for a week at a time, so I cannot do a long term review of what tables are accessed.

What have other people done to get over this issue?

Kind regards

Jake

[Former Member]

Jackie,

Have you considered changing the authorization group assignment of these specific tables from FA to a custom authorization group? You can create custom authorization groups in SM30 using V_TBRG link to object S_TABU_DIS.

Once you have created the authorization group, you can change the authorization group assignment of the two tables in V_DDAT_54. You can create a separate role or add the custom authorization group to an existing role as per your requirement.

Regards,

Prashant

[Former Member]

Hi Prashant,

Yes I have considered this, but written this off, incase in the future SAP make a change or enhancement (via patch or upgerade) that affect Table class FA. If I create a new class ZFA (for example) and move my two new tables to this group, then any future changes will be missed.

regards

Jackie

[Former Member]

As you cannot eliminate S_TABU_DIS completely (yet) my suggestion would be to use S_TABU_NAM for building new roles and switch some existing ones to S_TABU_NAM when you do maintenance on them and have a standard or maintained authorization in the role - this means the transaction in the menu will tell you which table / view it is accessing.

In contrast SE16 & Co do not tell you which table(s) are being accessed in the group as not all of the transactions you have mentioned are report generators (the generated report tells you the table name in STAD / ST03 / SM20, etc) and the table / view name can be freely attempted by user input. If they use the search help, then they can see all tables and attempt to select them...

So... those users who want to keep generic table browser transactions (which includes SA38 & Co as well) must give you the list of table names they want to access... otherwise you have little chance in building a robust role with S_TABU_NAM.

Cheers,

Julius

[Former Member]

Hi,

Please go through SAP Note 1434284.

Regards

[Former Member]

I have. I didn't feel like it was proposing a solution - if you could suggest which part of the note fulfills my requirements I would be more than happy to look again.

Thanks

[Former Member]

None does.

Julius summed up your options. There are none other (as of yet).

Besides: if you confront the business people with having to think about what they need, they might find they don't need so much after all. I think the modus operandi as proposed by Julius is the proper way to come to some kind of business-blueprint (and after GoLive to a solid documentation, veryfied by management/PM/TL) that gives you a base for an audit.

[Former Member]

Hi Mylene,

I am in complete agreement with you - with regards to Julius' comments - I was being a bit flippant to the other comment re the OS note.

Thanks

Jake

Edited by: Jackie Watkins on Jun 29, 2011 9:12 AM