User Comparison - Roles contantly going to 'red' inactive

[Former Member]

Hi,

Can someone shed some light on this issue i'm having here.

I noticed today while working with a user in SU01 that the role assigned to the user switch from green 'active' to 'red' inactive. There were updates made to the master role and then passed to the child (derived) roles. I manually ran user comparison and then verified in SU01 that the roles were still green. Couple hours later I noticed the child role went to 'red' inactive. Why is this happening. This happened and I took at as one time incident but this happening more frequently.

-Wes

[Former Member]

Hi Wes,

What I can understand from your post is that, some master roles have been updated and passed on to the child roles. These child roles are assigned to some users where it is going to " inactive " status from " active " status.

Well what it seems to me that, the profiles of the child roles are not being generated properly for which it is going RED in user assignment.If that is the case then, I believe you will find the same status of the roles in PFCG authorization tab as well.

Or else, it might be that even though the single roles are assigned to user, their profiles might not be assigned to the user, check that also by going to the PROFILE tab in SU01.

Bidisha

[Former Member]

Also check if the profiles of the child roles are properly transported as well.

[Former Member]

Hi,

I hope you are generating the derived roles also from the parent role. If not please do so and your issue would get resolved.

Regards,

Varadharajan M

[arpan_paik]

Hi Wes,

Roles in user buffer turns red if their corresponding profile get removed from user buffer. I suggest you to check user change history for profile assignment and see if any data can be found in there.

Arpan

[Former Member]

Hi Wes,

i did face this problem when i started working with the inheritance concept, but i figured the reason on why this happens. I think it could be the same reason at your end, do read the explanation

If authorizations are to be built for 10 Countries, say C1, C2, C3, C4........

and the master roles are defined as M1, M2, M3, M4.......

the derived roles for country C1 are: D1C1, D2C1,D3C1.......and for country C2 are D1C2, D2C2,D3C2......

in this situation, if you add/modify M1 and transport country by country, (first C1 and then C2) then your roles in the target system would be RED in olour, the correct way would be to transport all country roles from C1 to C10 for role 1, then transport all derived roles for role 2 for all countries

M1...............M2.................M3........................M4

D1C1...........D2C1.............D3C1....................D4C1

D1C2...........D2C2.............D3C3....................D4C4

D1C3...........D2C3.............D3C3....................D4C4

you should transport( D1C1,D1C2,D1C3 + M1) in one transport and not (D1C1,D2C1,D3C1,D4C1)

[Former Member]

I had faced similar problems, I observed that when you make changes to the parent role and derive it to child roles:

If a user was still using that child role and working , I performed the user comparision , those child role which were still being used show up as inactive.

My conclusion for this kind of issue was that :

Users with the child role in question should not be logged in when you derive.

End result: I went and derived one more time when the user was not logged in , ran PFUD again the roles turned active/green.

I dont know if there is any other easier way/idea.

[Former Member]

Two other possible explanations for this are:

1) Someone is running upgrade steps in SU25. If the role is "touched" by a suggested change, it turns "red" in SU25 and in PFCG as you can process them there as and when you get around to upgrading the roles themselves. It makes sense to run steps 2b and 2c with care, so that these "red" roles can be processed easily (particularly if you have a lot of them...).

2) You have been creating and generating profiles in production and there is a namespace collision. The new role definition with new profiles is rejected in the import events of the STMS.

Please check whether someone is active in SU25 and whether the transport logs show any errors / warnings related to roles.

Cheers,

Julius

[Former Member]

Thanks all, I was able to resolve.

[Former Member]

Was it Gremlins?

[Former Member]

Looks like we'll never know....

[Bernhard_SAP]

Hi,

propably it was a problem caused by profile names used. I am just collecting data on such issues when the characters '*', '+', or '?' are used in the profile name. Some DB interfaces seem to have problems with such wildcards and may cause such issues, I suppose...

in the moment: just a guess....

b.rgds, Bernhard

[Former Member]

Hi

It's been nearly a year since I last saw a derived 'go red' during transport, it seemed to happen during mass transports for derived singles/composites in Russia.

I can remember checking the transport logs and their having details in there about the problem (think it was a missing new auth object only in DEV but that's a long shot and never proved).

The comments about moving parent/derived in specific chunks does sound interesting.

I hate derived...

Cheers

David

[Former Member]

Could be...

According to Wes's Business Card he (?) is from the US and for some reason (probably the training documentation in ADM940...!) I have more often than not noticed that US based systems tried to allign the profile names to the "activity group" names when building little single roles - sometimes one role per transaction - as "building blocks" for activities clubbed together into composites.

@ David: I also hate composites...

Unless Wes clarifies, I would however still place my bets on a profile name collision as a result of the DEV, QAS and PROD having the same first and third characters in the SID name, or a client disorder in DEV from which the roles are being transported (e.g. "golden security client" implemented later than the productive client transport routes, or a customizing client was used to make the changes).

AGR_NUM_2 has MANDT as a key field and with derived roles and small singles the limit can be reached with ease, particularly if these were download / uploaded in the past to avoid transport request sequence confusion - which is reasonable in my opinion.

Cheers,

Julius

[fredrik_borlie]

Hi,

I do not remember if it was the kernel or any patches. But there was a bug causing this error to happen.

Look in notes to verify that you are not on the level where this error is appearing.

[Former Member]

This is also typical of changes being made to a master role in Dev and not all the child roles being transported to prod. The non-transported roles are flagged as red in the UMR to highlight that they are not in sync with the master role. Access is still provided through the profile as that still contains valid data albeit incorrect.