R/3: Cause of generated, but still inconsistent profile?

[Former Member]

Hi all,

Does anyone know how you can create the following situation:

I have a role with profile status "generated" (both SUPC & PFCG show green light).

Yet in UST12 I find objects for that profile that are not in AGR_1251 or PFCG.

SUIM confirms that the role/profile still contains the objects.

I found several roles like this and wonder what the cause is of this and how to detect & prevent it.

Some screenshots to illustrate:

[01.jpg|http://users.telenet.be/dunkelburg/SAP/01.JPG] - querying tables AGR_1251 & UST12: M_* objects found in Finance role

[02.jpg|http://users.telenet.be/dunkelburg/SAP/02.JPG] - PFCG shows that the profile is generated

[03.jpg|http://users.telenet.be/dunkelburg/SAP/03.JPG] - PFCG says role doesn't contain M_* auth objects

[04.jpg|http://users.telenet.be/dunkelburg/SAP/04.JPG] - in SUIM: looking for roles that have M_BANF_EKO

[05.jpg|http://users.telenet.be/dunkelburg/SAP/05.JPG] - SUIM agrees that the role contains the object

[06.jpg|http://users.telenet.be/dunkelburg/SAP/06.JPG] - SUPC shows that the role is generated

Thanks in advance for your response,

Tom

[Former Member]

Hi Tom,

Start transaction SUIM_OLD and wait about 10 seconds. Then they will be gone and corrected.

HOWEVER, take note that this will also impact the users who might have been "surfing" on these orphaned authorization records!

Cheers,

Julius

[Former Member]

Hi Julius,

Thanks for your reply.

Do you have any idea what causes this issue?

Best regards,

Tom

[Former Member]

weird. what product/version is this from? how did you detect this problem? I'd like to check our systems.

[Former Member]

SAP ECC 6.0

I'm currently performing an audit.

I was wondering what causes this to be able to recommend how to prevent further issues.

[Former Member]

There can be various reasons for this - anything from program errors to human errors.

For example you have the habit in PFCG of maintaining some objects but leaving some fields open. Or you save in PFCG but don't always generate the profiles, which in turn generates the authorizations in UST12 and USR12.

There are also some old inherited problems from active and plan versions of manual profiles and which tables should SUIM read. This made SUIM notoriously "buggy" for a long time...

An example of this is [SAP Note 489887|https://service.sap.com/sap/support/notes/489887] . The program behind transaction SUIM_OLD does exactly that which this function module mentioned did.

However! If this is a 7.00 system or higher then the cause is likely to be something else which I have also seen before.

--> go to SE11 and do a where-used-list on table UST12 and verify whether any Z or Y or / programs have a reference for the table. If yes, then chances are fairly good that you have a very juicy issue for your audit report...

Cheers,

Julius

[Former Member]

Hi Julius,
> 
> 
> Thanks for your reply. 
> Do you have any idea what causes this issue?
> 
> 
> 
> Best regards,
> Tom

Data is kept in the USR tables but UST tables are frequently used to report from (have a look at USR12 'vs' UST12 and you will see why...). The tx & FM that Julius pointed you at will sync these tables & reporting can improve.

[Former Member]

The bet is on again: I will eat my hat if UST12 is only for reporting purposes...

USR12 is for old manual profiles and AFAIK only kept backwards compatible because of some ancient old checks which reverse engineered the authority-check statement or wanted to avoid trace confusion. An example of this is the session_manager itself --> when you logon then if you have full access to user and role admin it wil display the button for "Create Role", otherwise not. This is built from such "probing" of the tables.

However an authority-check looks for the object and your user ID in the client you are in as keys of table USRFB2. If it finds the keys, then it uses the object and field AUTH to find the corresponding values in UST12.

If you directly manipulate UST12 (which is another possible explanation for this inconsistency..) then you instantly have the additional access and PFCG knows nothing of it.

The same is true of USRBF2, however that is nearly impossible to observe and tends to corrects itself automatically after a while or whenever anyone next saves a change in SU01.

@ Tom: For the generated profiles of the PFCG roles, do they have generated unique names? Or did someone think it a good idea to manually name the generated profiles? The profile name also determines the authorization instance name and this might have produced collisions!

Cheers,

Julius

[Former Member]

Thanks, Julius & Alex,

I'm still a little in the dark about what caused this issue and especially how to prevent it, but I have now a better understanding of the content, structure, difference & impact of UST12 & USR12.

While I was focusing on UST12, I should have taken USR12 instead as input.

However, my results are still the same and I have some interesting material to show to my customer.

I did a test in the system and the roles that contain auth values in USR12 that are not shown in PFCG definitely give access to the phantom authorizations.

Best regards,

Tom