field DICBERCLS (S_TABU_DIS) defined as an orgnanization field value

[Former Member]

Hello Folks,

During a check i was doing on the table USORG for implementation work i am about to start with a client, i found that the field DIBERCLS (authorization group) used in S_TABU_DIS, has been defined as an org field value. This is the first time i have come across auth group being defined as organization field value.

I don't quite like the idea and want to redefine it as a standard autorization field value (PFCG_ORGFIELD_DELETE). But i am putting up a question in the forum just to see if there are indeed any benefits of leaving it as an orgfield value.

From my point of view, there would be too many duplication of authorizations using this concept, especially in roles were we define access to lots of tables.

Can you please help me out by putting across your ideas?

Regards,

Prashant

[Former Member]

Prashant - Interesting to see the explained scenario.. Auth groups is a technical field and generally its values (Auth groups) are decided by technical/security teams...So i dont think it is a good idea either to make it an org field unless your client has a set strategy and compelling need to keep it an ORG field.

I am with you in the clean up..

~Sri

[Former Member]

Hi,

The simple question is: with your planned activities, do you forsee having roles with different sets of table auth groups and activity pairings?

If you do then -> PFCG_ORGFIELD_DELETE

If you don't then -> have a cup of tea

[Former Member]

Strange candidate because the field is not used by multiple objects.

Check in table TOBJ whether there are others?

There are only 2 commonly used activities for the 1 object, so the impact is low at first. However... the org. fields are in the tables so S_TABU_LIN would (have been) a more likely candidate.

Someone once before promoted RFC_NAME to an org-level. Here also I just don't "get it" what the benefit is.

Cheers,

Julius

[Former Member]

Julius,

There is one other object, S_RS_GVAR- Business explorer- Global variables, which uses this the field DICBERCLS, and even though we are implementing BI Security as well, i am not worried aout this object(i dont tink i'll be using it), and more so in the ECC system.

Regards,

Prashant

[Former Member]

Hi Prashant

Does your remit cover this work and if not who can you refer this to please? If you have a security manager they should pick this up as you obviously cannot make any decisions until you have found the documentation (if it exists) as to why this is the position in the first place and not just the 'techie' view-point.

Not a technical answer - just wondering what the background was...

Regards

David

[Former Member]

Alex,

This implementation is the first in a series of roll outs across Eurpe (starting with UK). So i want to factor in the scenario that there will be different sets of authorization groups depending on which country groups want what table data secured. So yes, i guess i should delete it from list of org values.

More over, as Julius pointed out S_TABU_LIN would have been a better option keeping mind that multiple countries will be accessing the table data and securing at the row level would be a good option.

To answer Davi'd question on the background, the organization's parent company (which uses its own set of SAP systems) has set of guidelines vis a vis role naming conventions, global template roles (for all its group companies), local template roles (to be used withing each subsidary organization's SAP system) and so on... i guess S_TABU_DIS has been defined as an org field value in their SAP servers and so they have done the same in our servers. But on this aspect, i guess i am free to decide whether or not to go forward with it as an org values. I vote to remove it from the list of org field values...

Any further thoughts would be welcome

Regards,

Prashant