S_RFC and role maintenance

Technical checks on the server

auth/rfc_authority_check controls the technical S_RFC check. Value 0 disables it. Value 1 is the historical recommendation for many systems, with exceptions for the SRFC function group; additional values provide different scopes of protection. Review NETCF and the target release when selecting the setting.

Value 9 also covers internal RFC and is not a universal recommendation: it can require roles to include internally used functions. A higher numeric value should not automatically be treated as better protection.

Checks can operate at function-group or individual function-module level. Availability of FUNC-level checks depends on the release and installed corrections.

Short-term tracing of a specific scenario

Use STAUTHTRACE to identify authorization checks during a representative integration run. Where load balancing is used, include a system-wide trace. S_RFC authorizations with RFC_TYPE = FUNC support analysis at function-module level.

Use trace results to maintain SU24 proposals. Add RFC modules to the PFCG role menu so that S_RFC and associated authorization proposals can be calculated. Maintain proposals and roles in DEV, then transport them through the landscape.

Long-term analysis: functions and users

STUSOBTRACE documents the checks performed by an application; it does not by itself identify which users need access. Use UCONCOCKPIT, STRFCTRACE or statistical analysis to associate users with functions.

auth/authorization_trace controls long-term tracing, with Y or F configured through STUSOBTRACE for the described approach. Statistical analysis can use stat/rfc/distinct = 1 with the required kernel corrections. Filter statistical data to separate external calls from internal RFC.