Lesson 3 of 5
Default values
10 min
Listen to this lesson
When an app is added to a role's menu, how does PFCG know which authorization objects to propose and with which values? The answer is the authorization default values, maintained in transaction SU24. Good SU24 data means roles that are right the first time; poor SU24 data means every role builder reinvents the same values by hand, slightly differently each time.
Where defaults live
SAP delivers default values for its applications in tables USOBX and USOBT. Customers do not change those. Instead, SU25 copies them into the customer tables USOBX_C and USOBT_C, and SU24 maintains the customer copies, which are what PFCG actually reads. SAP's course describes USOBX as controlling which checks run and which objects are maintained in role maintenance, and USOBT as holding the default values per application and object.
What you maintain in SU24
For each application and object, SU24 holds two independent settings, kept separate since SAP NetWeaver 2004s.
| Setting | Values | Meaning |
|---|---|---|
| Default status (proposal) | Yes | The object is needed; PFCG adds it to the role with the proposed values |
| Default status (proposal) | Yes, without values | The object is needed but values are set per customer; PFCG adds an empty authorization |
| Default status (proposal) | No | The object is not needed; PFCG does not add it |
| Check indicator | Check | The default: the object is checked at runtime |
| Check indicator | Do not check | The check is switched off at runtime; not allowed for HR and Basis objects |
The two SU24 settings, as described in SAP's authorization course.
"Do not check" deserves caution. It removes a control for every user who runs the application, not just for one role, so it belongs in the security design, with a reason and an approver, not in a quick fix during testing.
Improving defaults with traces
SAP's course shows that SU24 can take values from a trace: run the application with the authorization trace on, then evaluate the trace in SU24 for that application and adopt the checks it found. This is how Kenji's team should treat custom code. Every custom transaction or app carried over in the conversion needs SU24 data, otherwise PFCG proposes nothing and each role builder guesses.
- TraceRun the custom app in CMD with STAUTHTRACE on for a test user
- Evaluate in SU24Open the app's defaults and use the trace to find the checks performed
- Set proposalsYes with values where they are generic; yes without values for organizational fields
- TransportSU24 changes create a transport request automatically
- Refresh rolesRoles containing the app pick up the new proposals when they are next maintained
- TestPositive and negative tests with the roles in CMQ
Upgrades, conversions and SU25
When SAP's defaults change in an upgrade or conversion, SU25 brings them into the customer tables. SAP's course lists the post-upgrade steps: an automatic comparison, a modification comparison with SAP's data, a search for obsolete applications, updating application groups in role menus, and a list of roles to be checked where the new defaults should be merged. Two warnings stand out: re-running the initial fill overwrites customer changes, and SAP says not to run the step for installing the profile generator after an upgrade. SU25 can also generate SAP_NEW, a temporary role covering new checks that is very broad and should be removed from users once roles cover the new checks.
What would you do?
In CMQ, Contoso's custom fleet rebate report fails for every tester with an authorization error on a company-code object. Kenji suggests setting the check to "Do not check" in SU24 so testing can continue. What should Nadia do?
- SU24 maintains the customer default values (USOBX_C, USOBT_C) that PFCG reads; SU25 fills them from SAP's tables.
- Each application-object pair has a default status (yes, yes without values, no) and a check indicator.
- "Do not check" removes a control for all users and is not allowed for HR and Basis objects.
- Maintain SU24 for custom apps from traces; an SU24 change affects every role containing the app.
Check your understanding · not graded
Lesson check
1. What does SU24 maintain?
2. Which customer tables does PFCG read for default values?
3. What does the proposal "Yes, without values" do?
4. For which objects does SAP not allow "Do not check"?