Changing Profiles in Productions

Question: Can someone tell me the reason why we should not change profiles in production. I mean I understand, the loss of authorizations, and the users having to log back in, but I am more interested in the technical aspects that are not so easy to identify. For instance is there a chance the PFCG tool in PRD will rename or renumber the profiles in the list (the sub profiles) so that they have different numbers than the one in DEV? I have been reading SAP notes but have not found this explained yet.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net

Answer:
Hi,
Yes, if you regenerate profiles from activity groups in expert mode, the system can asign different names for profiles in PRD and in DEV. This is not really a problem if you assign always activity groups in SU01, SU10,....
But the real problem is that, when you generate profiles in PRD, the affected users (the ones that have that activity group) get no autorizations at all in their current sessions, and they need to logout and in again to be able to do anything in the system. (At least in SAP 4.6B)
regards

Answer:
Another reason is that if Financial and system auditors audit your system they would look view this as a red alert on the security system and report this back to Senior Mangement within your company. I know of this through audits performed by Price Waterhouse Coopers who audit our systems world wide.

Answer:
Thanks. From a daily work routing perspective I can certainly see the danger in changing the authorizations in Production as there is no accountabiblity, (unless you are doing a daily checklist and submitting it to management on who changed what roles ) but then if you are the one changing the roles and doing the checklist, it would be easy to fudge the checklist to hide your activity. The Transport method at least flags the BASIS team that a security profile is being changed and the Security Admin is not the only one that knows it happened.
Thanks for the input, I thought that the names of the sub profiles could change, I had looked through several that had been changed in Production and did not see any differences, but maybe I would have found some if I looked long enough.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net

Answer:
My 2 cents. If you have parameter auth/new_buffering set to 4 you won't need to be concerned about messing up the user buffer when making changes in production, initially 46C functionality. If on 46B, when making changes in expert mode the customer su24 values get pulled in to the profile as you know, if you put a new auth in the profile or change the profile in such a way that say auth 02 is now auth 01, SAP gets lost, the user buffer still has 02 but the ust12 table now has 01 from the update of the profile and a auth error takes place. After making a profile change, you can run function module 'SUSR_USER_BUFFER_AFTER_CHANGE' and put a '4' in the profile field to force an automatic update of the a specific users buffer, pending the time amount for setting rdisp/bufreftime, but you must also be on basis support pack 46B52.

Hope this helps.

Answer:
The reason i have found are:

the number generation can get out of synch and if you transport it will overwrite.
is auditor like it the transporting of profiles because it provides a way of having checks and controls
if your are performing massive changes, the pfcg tool will affect other users in the system when generating the profiles as it consumes buffer.

Answer:
Hi Gary

For the reasons already mentioned by others we don't change profiles in Production, except in emergencies.

Our emergencies always come from the highest level of management and usually result from lack of organisation on their part. Eg not ensuring a back up is arranged for high level Purchasing delegations when someone leaves.

Permission is granted for me to make the change and to ensure consistency I download the changed Prod Role/Profile, upload it into Dev and initate a transport, within 24 hours all systems match.

These changes are only made where it is a case of adding another Purchasing Group or similar, never anything complex which requires QA testing. I do not create Roles in Prod ever.

Cheers
_________________
Sandi
~~~~

Apparently Father Christmas, the Easter Bunny, the Tooth Fairy and Star Wars aren't real

Tuly kiwi.

Answer:
Gary, in our PROD (4.6C), changes are allowed but only in emergencies & never to the original role.
Our process is to copy the existing role naming it as Z:TEMP.original role name. ( this clearly allows people to know it was a temp emergency ). We use COPY ALL so all users are also copied.

Changes are applied to the copied role and then profile is generated . Then a USER Compare is completed.

This forces the user to log off andf back on to get the new authorization... but hey...they're the ones with the problem.

Other changes are done to the copied role as required i.e. more authorization failures. I track these in the COPIED role by changing the text on the changed authorization object in the role indicating what i am putting in and why.

Once the client is happy with the access, the changes made to the copied role are made to the orginial role in DEV and transported to QAS & PROD. Once in PROD, the copied role is deleted.

It works, keeps track of the changes, all roles are the same in D/Q/P and if i get hit by a truck someone will be able to see why and when the changes was done.

Lastly when th DEV role is updated , we use the description to explaing what was changed and why. Even then i sometimes change the auth object text to document...