Question:
Hi,
I have deactivate e.g. s_btch_adm, so it is in red with maintained status. Next time I made a change to this role, no matter I click on "change authorisation data" or "expert mode - read new merge old", this configuration will be overwritten, it will be in yellow. Problem is, if there are too many similar configurations, and next time they are in yellow again, then I have remember them and change all of them.
if I use expert mode, edit old status, then newly added tcodes cannot be brought in, I have to maually insert.
How can I keep the configurations when a role is modified? It doesn't seem happen to me before. Anything special with this role? I am confused.
Answer:
HI,
I understand "read old merge new" is a standard way to modify roles. And "edit old status" is not recommended. How can we solve the proble I posted?
Can any one give some idea so that I know the best practice?
Thanks a lot.
Answer:
If you have maintained the config tables for PFCG via SU24, you will not get this problem. You should use SU24 to pull through the objects required by the transactions. If you do this, you do not need to worry about read old, merge new. Time invested to set this up is more than recouped further down the line.
Answer:
Hi,
If you are on 4.7, there was / is a problem on 4.7 where the status of the authorisations kept getting reset to status standard. Have a look on OSS for PFCG and version 4.7, there was more than one note.
Unfortunatly I don't have them handy at the moment. If I find them I will post the numbers.
Cheers
Peter
Answer:
Hi,
Look at oss note 766483. You may need to apply 679050, which was the first correction.
However 679050 had other errors corrected by 766483, just not sure if you need to apply both.
Cheers
Peter
Answer:
Thank you very much guest and Peter. I am on 46B.
I understand we should always use su24 to configure PFCG values, but just for example, tcode sm37, authorisation object s_btch_adm, the system default for this one is unconfigured and hence a yellow light. I would assume this would be correct for many projects? As sm37 can be assigned to normal end users as well as super users who can be background job administrator. If use su24, which value would you configure? I might leave it unconfigured so that in a role given to normal users I deactivate it, in a role given to super user I will give a 'Y'. If the way I am configuring su24 is correct, then I will have the problem I listed before.
The same thing will happen to object s_btch_job, the default value is DELE, LIST, PROT, RELE, SHOW, which is OK for super users, and it comes with green light in PFCG. But for normal users' role I will only grant RELE. Then next time the default value will be brough in, since it is in green light, it is almost undetectable if you forget there is such an object in this role.
Another two things I observed are:
1. the behaviour of s_batch_adm described above, I changed this role again by "read old merge new", it remained in red, unlike last time in yellow. Same role, I can't understand why.
2. I used to think button "change authorisation data" is the same as the "read old merge new" in expert mode, but I noticed for example the default values for s_btch_job, will not be brought in if there is no changes but just click on "change authorisation data". However, if no changes but just click on "read ole merge new", then the default values for s_btch_job will still be broght in.
Can you guys help me to get clear about the correct industry practice?
Many thanks.
Answer:
Hello Wander,
Please look at OSS 113290 Note it describes how the merging function works. There are other notes around.
The button change auth data determines whihc action to perform depending on whether you have chnaged the role menu. No changes then does a read old data. if there are changes then does a read old and merge with new.
I rarely select expert mode unless I have made a technical build error and want to bring back standard auths into the role.
As for best practice. The ideal scenario is to have all authorisations defined with status standard or maintained. If the status is manual then add it to su24 for the relevant transaction. If the status is changes then consider changeing the definition in SU24, if possible.
In the example you give for S_BTCH_ADM you would leave the vale blank in SU24. This enables the authorisation to be defined as status maintained when you change the value.
it is not always possible to change SU24 as it doesn't make sense due to the transaction being assigned to multiple processes with different requirements. You could make all the fields blank or you could let the authorisation have status changed and document the link to a txn by changing the text on the authorisation name in PFCG. If you set an authorisation to changed then you should always make a copy and set the standard inactive and leave it in the role.
Cheers
Peter
Answer:
S_BTCH_ADM along with F_BKPF_BUP and S_ALV_LAYO should be removed from ALL transaction codes in SU24. Thesew are all SOX violations and should only be given to a few individuals who need the access.
S_BTCH_ADM is replaced with S_BTCH_JOB and prevents the user from assigning a high class onthe jobs.
F_BKPF_BUP is ONLY fo a select few in the financial close process and S_ALV_LAYO is for the functional team super user respinsible for corporate reporting.
Answer:
Thanks Peter and John,
This really solves all my concerns.