Quantcast
Channel: SCN: Message List
Viewing all articles
Browse latest Browse all 9080

Re: Re-generating derived roles shows changes

$
0
0

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)

 

PFCG tables.jpg

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


Viewing all articles
Browse latest Browse all 9080

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>