topic Re-generating derived roles shows changes in Application Development and Automation Discussions

Re-generating derived roles shows changes

Former Member — Mon, 13 Oct 2014 15:14:07 GMT

Hello,

I respectfully ask for your guidance as I am unable to find the necessary documentation needed to support a request for our auditors. Currently, we utilize a derived role methodology with organizational definition restriction within the child roles. The Compliance Director has taken measures to reduce the level of access issued to the SAP Security team.

Given some of the role changes and activity within the company lately, the Security team has started reviewing the role status to ensure all roles are generated within Production. (PFCG, Utilities, Overview Status). We are seeing a high number of roles that are going into an ungenerated state and are not sure why. Due to our restricted access level, our team is unable to re-generate/re-derive a role(s) within Production which means it requires a transport, change management request, approval, etc. Our auditors are now requesting proof that nothing changed when the role(s) are regenerated. This is a an easy task when it is just a child role that is re-generated. When a Parent {and its child/ren} require re-generation and re-deriving the change logs show activity which our Compliance team 'see's' as change. No changes are being made to the role other than the parent being re-derived to the child roles. Although this is what has been explained, it had been noted that it will be written up as a finding.

We have been explaining this for weeks now and are still on square one. Can someone point me in the right direction of documentation that this is the process. We have already addressed the access issue and have been told, rather emphatically, no changes will be made.

I appreciate your time and consideration.

Re: Re-generating derived roles shows changes

Colleen — Mon, 13 Oct 2014 15:23:04 GMT

HI Katherine

would the auditors accept table comparison as the evidence. Agr_1250/agr_1251/agr_1252/agr_1016 are the pfcg build tables. Generating the profile updates ust* tables.

could you compare DEV tables post generation to PROD table pre-transport to prove no changes to permissions?

Before I transport a role or group I always run SUPC to check that all are generated. Also, if you transport a derived it always includes the imparting, if you have made a change to the imparting then when you move the transport to production all the other derived roles in prod turn yellow as the auth tab status is based on a time stamp. It means roles appear to gave a profile issue but they don't.

regards

Colleen

Re: Re-generating derived roles shows changes

Former Member — Mon, 13 Oct 2014 15:29:47 GMT

Hi, Colleen.

We have been performing the table assessments, grabbing screenshots, etc as evidence to show we are not introducing any new changes. However, the auditors have pulled two change requests that were not part of the role overview status project. Rather, they were roles that were causing production issues and were handled ad hoc. No evidence was captured at the time to show no changes only a role regeneration. Short of saying its just a role regen, pulling the change history for the roles, I don't know what else I can show for this one. The parent was re-generated and the child roles re-derive given the nature of the issue.

Re: Re-generating derived roles shows changes

Colleen — Mon, 13 Oct 2014 15:34:53 GMT

If it was just regeneration and no change then shouldn't the change docs be able to cancel each other Out? For every added authorisation for the object there will be a deletion? It might take a bit if effort to reconcile but you should be able to prove. Just to confirm what is your sap system version for basis stack?

in terms of why roles appear ungenerated in production, have you investigated the root cause?

Re: Re-generating derived roles shows changes

Former Member — Mon, 13 Oct 2014 17:03:10 GMT

Yes, you are correct. However; since Compliance is seeing that a 'change' occurred even though it is cancelled they believe that something was changed. I am trying to find documentation on the process for what occurs when a role is regenerated (re-derived) to support our efforts.

To answer your other questions:

- ERP 640

- Root cause is currently underway. We believe there are multiple contributing factors but need to get the roles stable before identifying a clear root cause. There were too many roles with too many issues to safely say one way or the other what was happening. Once they are stable we will be in a better position to diagnose.

Thank you! I do appreciate your input on this matter.

Re: Re-generating derived roles shows changes

niteshgupta87 — Tue, 14 Oct 2014 06:59:02 GMT

Hi Katherine,

While creating a transport request in Development system, there is an option to transport generated profile for the role also. If you don't select that option, then the profile in target system (QA and Prod) will remain Yellow. This could be one possible. But again as you said, there could be multiple reasons.

Regards,

Nitesh

Re: Re-generating derived roles shows changes

Former Member — Tue, 14 Oct 2014 09:46:08 GMT

Are there multiple landscape in your current client where roles are common and also moved from one landscape to another ?

If yes, then one of the other reasons could be that the Parent role (With Ungenerated status) might have moved from some other landscape to your current landscape making it in ungenerated status in your current landscape too.

Re: Re-generating derived roles shows changes

Former Member — Tue, 14 Oct 2014 19:05:31 GMT

Hi Katherine

I agree with no access to generate (repair) directly in production as the next transports will over-write and destroy the temporary fix in PRD if the roles have the same state in DEV/QA.

You need to move incorrectly transported roles to PRD to solve the problem permanently.

Are the roles generated (or is it that they require profile comparision)?

Moving SOME derived roles for your own change is 'selfish' if this is the real cause rather than all of the roles not being 'generated'.

Best wishes

David

Re: Re-generating derived roles shows changes

Former Member — Wed, 15 Oct 2014 07:32:37 GMT

Hi Katherine,

You have done what can be reasonably expected: Provide the explanation, demonstrate the behaviour & provide the logs proving nothing has changed.

If the compliance team are not happy with that then the onus is on them to design an alternative control to cater for this situation.

No-one like audit points raised against them (unless you are using them to get funding/raise attention) but you have an appropriate rebuttal.

Cheers

Re: Re-generating derived roles shows changes

Colleen — Wed, 15 Oct 2014 14:12:49 GMT

Hi Katherine

Alex and few others have already beat me to a response. Alex is right here, you can only justify the actions to the compliance person as much as possible.

In relation to explaining what the change is my approach is to usually show that the cancellation of ADD/DELETE proves that it was just a table re-adjustment

Normally I show the auditor a picture (one example below) to explain the PFCG through to user buffer tables. So PFCG entries (AGR*) might valid but some corruption has occurred with the profile (UST*) and user buffer (USR*). I usually step them through the diagram and show how that. If I'm not adding anything to the AGR* tables then I'm not granting more access (this assumes no naughty efforts of writing custom code to insert entries directly to UST* or USR* tables)

Diagram - Update roles on the PFCG side (AGR tables) to generate the Profiles (UST*) tables. Right hand side is the User Assignments and the connection between users and roles/profiles.

With the 640 release I cannot remember how some of change documents are stored. I just recently did a big clean up on a 4.6B (don't ask) and found I had to run the change documents for the profile to obtain add and remove of object/authorisations as well as change documents at the authorisations to find add and remove of field values. A lot of reconciliation to prove no changes!

Again, part of my response to compliance would be acknowledge that updates are being made and understanding the root cause. Part of this needs to be an analysis of change request process to ensure right sequencing of roles changes to production. And, as mentioned again, a profile without a green authorisation tab in Production does not mean that the profile is corrupt and user doesn't have access.

Does your team have a defined process with approval for making edits to Production? I've worked in other sites where we've had emergency process for direct updates to Production. Typically, we would use a Firefighter Id to login and generate the profile. In the FF session log on we would process the CR number to link back to approval for this activities.

Root Cause Analysis Recommendation

Next time you get this happening, do not generate the profile for the role in Production. Have the a look at the following (these checks and analysis can cover more than the scenario you are facing)

Compare the role in Production the Developer (assuming no change is in progress that has not been migrated from Dev to Production). Use SUIM cross system compare is you can for changes. Also, compare AGR* and UST* entries
Verify that you are transported the generated profile with the role (mentioned by a few others in this thread)
PFUD cleanups should be scheduled to run weekly to remove orphan entries
Check change documents in Production (if there are changes for a role then someone did make an update directly in Production. Pretty much situation you are in with the auditors).
Check there aren't any in progress transports and may have been a transport.
Is the role a Derived Role? I mention this one as I assume this is where bulk of issues are from
- yes - did the Imparting Role get imported to Production more recently than the derived role? If it did, the yellow/red tab in PFCG is due to a timestamp comparison between the two roles. If the imparting role has a more recent date, then it assumes that the imparting values in table AGR_1251 are different to that of the derived role and must be compared.

Regards

Colleen

Re: Re-generating derived roles shows changes

shivraj_singh2 — Wed, 15 Oct 2014 15:50:11 GMT

Katherine,

There are already some great solutions and suggestions offered in this discussion, just adding few thought to those.


We are seeing a high number of roles that are going into an ungenerated state and are not sure why.

I think your first line or point of attack should be to investigate these transports which are resulting in un-generated roles. Please make sure transports are created properly i.e. the profile button is checked (most likely you are already checking it). Also what are the results when transports go to QA first? If they are causing the non-generation problem in QA, then obviously you can catch it before production and create a fix transport. One more thing that caught my eye is that you mentioned it is master-derived roles so there are Organizational levels involved. Please check if the table USORG is in sync in DEV/QA/PRD, from what you have described I have a strong suspicion that it may be the reason transports are failing when it comes to transporting the generated profile.


our team is unable to re-generate/re-derive a role(s) within Production which means it requires a transport, change management request, approval, etc. Our auditors are now requesting proof that nothing changed when the role(s) are regenerated.

Security team should not have access to change the roles in PRD. You should immediately remove the change (02) access from Security (Role) Admin roles (add that to Firefighter roles) and present it to Audit as a control that is in place to check any role changes in PRD. However, ability to assign the role (in regular roles) and ability to generate the profile should stay (firefighter roles). You can certainly use the firefighter to log all the activity when it comes to generating or changing the roles.

Regards,

Shivraj Singh

Re: Re-generating derived roles shows changes

Former Member — Wed, 15 Oct 2014 16:40:51 GMT

Nitesh,

Yes, we do transport the profiles from DEV to QA. One of the steps we perform before assigning the roles to test users in QA is to verify/validate that the transport moved over to QA successfully. Once the transports are verified as being successfully moved into QA, role assignments occur.

We are seeing the isssue of roles going ungenerated within PROD on roles that have resided in PROD for quite some time without any recent updates. {how's that for a twist }

Re: Re-generating derived roles shows changes

Former Member — Wed, 15 Oct 2014 16:54:53 GMT

Hello, Shivraj.

I will definitely check table USORG within DEV/QA/PROD to ensure sync.

As to the transports, we do verify the roles are generated before adding to a transport, generated after reaching the QA systems so that user assignment may occur for testing. The roles that are becoming ungenerated within the PROD system are a mix of roles that have been there for quite some time as well as newer roles. They do not fall over immediately after a transport, user assignment or user compare.

The Security team does not carry an 02 value for generating roles in PROD in our regular access or Firefighter access. The Compliance team has directed the removal from both accesses calling it a 'critical transaction' and any assignment to Security is a violation.

Re: Re-generating derived roles shows changes

Former Member — Wed, 15 Oct 2014 16:58:26 GMT

I would like to thank everyone for taking the time to weigh in on this question. Your suggestions and feedback has been extremely helpful and validates what we thought was correct. Your input has provided me with a few items to verify while we continue to troubleshoot and pinpoint a root cause for this issue. Thank you, again.