11-19-2013 8:58 PM
Hello all,
We are going through an SAP new implemenation and I have to create a PRD ready GRC compliant role for our security team that does the following:
Allows them to display the role via PFC so that they can validate authorizations (yes we can use SUIM but PFCG is visually more friendly)
Allows them to maintain user's to assign roles to their UME records and save them.
Currently I have found (maybe incorrectly) that S_USR_AGR with 02 allows me to update a user record with the correct role, but this also allows the user "Change" access in PFCG.
I can restrict the generating of profiles S_USR_AUT and also the adding of authorizations by disabling S_USER_TCD adn S_USER_VAL which gets me 95% complete but the only thing that I cannot do is stop a user from doing so far is clicking on the "disable authorization" icon in the profile itself or clicking the save button.
If a user clicks on the disable it will disable the object, and even though a user cannot generate the profile if the user gets out without saving the profile will now be "ungenerated"
I have disabled the ability to "enable" the authorization object...just not disable or save.
any insite as to what activity will allow me to disable either of these would be helpful.
11-19-2013 9:22 PM
You are obviously on a bit of an older SP level. But even there you can change the behaviour.
Go to table PRGN_CUST and in the ID field hit F4. There is an ID called ROLE_AUTH_ASSIGN or very similar. In the long text a SAP Note is mentioned. That is your solution -> change the param to ASSIGN and then only ACTVT 22 is checked on the user tab and SU01 and the BAPIs.
Cheers,
Julius
11-19-2013 9:22 PM
You are obviously on a bit of an older SP level. But even there you can change the behaviour.
Go to table PRGN_CUST and in the ID field hit F4. There is an ID called ROLE_AUTH_ASSIGN or very similar. In the long text a SAP Note is mentioned. That is your solution -> change the param to ASSIGN and then only ACTVT 22 is checked on the user tab and SU01 and the BAPIs.
Cheers,
Julius
11-19-2013 11:29 PM
Julius you are a beautiful person!!! Thank you very much for this very concise answer. It resolved everything.
I will state though that this is a brand new install and we are on the following versions below and the notes state that this is resolved after 4.6, but when I went to the table that you were referring to and viewed ASSIGN_ROLE_AUTH there were no entries. The complimentary note (565108) for message maintenance was completed just not the items in your note.
updated the entries as detailed in the notes and tested and it works fine (zipping to prd in a CHARM request as we speak!!)
(BTW** I'm assuming this wasn't an obvious fix as (a) I couldn't find it in my normal SAP Security Forum searchs and (b) I didn't get rediculed mercilessly as someone looking for a free education )
SAP ECC 6.0
SAP_BASIS 702
SAP_ABA 702
PI_BASIS 702
ST-PI 2008_1_700
FLDQ 440_702
SAP_BS_FND 702
SAP_BW 702
GRCPINW V1000_700
SAP_AP 700
WEBCUIF 701
SAP_APPL 605
SAP_HR 604
SAP_HRCAR 604
SAP_HRCAT 604
SAP_HRCAU 604
SAP_HRCBE 604
11-20-2013 7:20 AM
Hello Michael,
The ID was introduced and back ported back in 4.6 days.
Changes to default logic usually require a major release to be switched (that is what I meant). With 7.31 the default changed to ASSIGN if not found in the table. Prior to that (regardless of SP level) the backward compatibility with the default CHANGE value appears to have been respected.
But ASSIGN makes much more sense and does not open a security gap even although it reduces the severity of the check. The old check was (as you observed) too strict, and forced you to give the user too much access.
BTW: There is also another new table now for similar but client dependent customizing switches --> USR_CUST. Worth keeping an eye on the F4 and where-used-list of that one as well as there are some useful switches in it. If you take the SAP Security Certification exam then question 7 also asks about a 3rd table.. 🙂
Cheers,
Julius
11-20-2013 11:53 PM