Hi J K
I take the following approach with SU24:
- Complete Proposal - completely maintain an authorisation proposal when that values applies for any situation in PFCG role build. E.g. transaction FB03 for object F_BKPF_BUK has fields ACTVT and BUKRS. You can allow the value as ACTVT = 03 and BURKS = $BUKRS (org value) or each scenario
- Partial Proposal - only maintain some of the fields where it will be consistent. E.g transaction OB52 for posting periods and S_TABU_DIS with field ACTVT and DIBERCLS. You leave ACTVT blank as sometimes you want change whilst DIBERCLS for auth group is static so you can enter a value there
- Empty Proposal - leave the proposal values completely blank as the requirement will depend on the scenario. E.g transaction SM30 you might leave S_TABU_DIS empty as it will depend on the role for both fields.
If you take this approach, you minimise the need for deactivating object, copying/changing and manual objects in PFCG. You maximise role authorisation under status of Standard or Maintained.
Now if we set the proposals in su24, it will be applicable for other new roles as well for which we DO want the proposals to exist.
Yes if you change SU24 you should clean up all impacted roles but before you build roles you should review
At the end of the day your need to have competent security administrators who know what a display activity is and have attention to detail/meticulous enough to build the role with appropriate restrictions (i.e. do not put change access in a display role).
How can we avoid the "new authorizaiton objects" to be added to this display role.
To avoid this you are trying to avoid using SU24 integration. If you are tying to build a SAP display all role then you might as well copy SAP_ALL and go through and deactivate/remove any display access from the role. In this case you would not use the role menu.
Not all solutions are technical. It's why you need to have a clearly defined process that is adhered to.
My trick of display roles - I got the AGR_1251 role and look at the entire contents of the role and scan this list of objects and what's in the role. However, I do this as I know the objects relatively well and can identify the specific objects that are change/display but do not use ACTVT field (e.g. PLOG/P_ORGIN/P_PERNR)
Wonder why SAP prompts warning and errors messages doing a business/financial transaction and not security.
Exactly what would you want the system to prompt? How would SAP know what a display role is?
We noted that every time we add a t-code, the authorization object added is marked as "new" in the list. we jsut disable those and generate it
If you take this approach you cannot guarantee the transaction code will work. The user may need the underlying values and that is why SU24 has them marked as proposal.
My summary - defined your process to include a quality check after building a role and hire security administrators who know more than how to tick and click buttons in PFCG (i.e. they understand security objects and why some are sensitive).
Regards
Colleen