Mastering S_RFC authorizations // Part 1

Hi!

In this article, I’ll show you a handy way of identifying the S_RFC authorizations your users need; this method helped me a lot recently.

Generally, you might be interested in this topic, because…

• … you were asked to raise the value of profile parameter
  auth/rfc_authority_check from zero to a greater value
• … you need a practical approach to improve your S_RFC authorizations
• … you updated your SAP kernel to a patch level ≥ 7.20-400
  or ≥ 7.21-041 (see SAP Note 1785761)

The challenge

The authorization object S_RFC consists of three fields, but only one of them is of interest for us: RFC_NAME – which is checked against the called function module’s group (the other two fields have only one possible value each, so we’ll ignore them here).

I opted for a heuristic approach to determine values for that field… so first we’ll collect a list of function module calls that occur on a productive system. In part 2 of this series, we’ll use that list to determine the affected function groups and derive the required S_RFC values from that.

Unfortunately, this approach assumes that all required RFC calls succeed – so during the analysis phase, S_RFC authorizations have to be (or stay?) oversized to ensure no authorization problems distort the result. I’ll leave it to you, how you deal with that…, but you might want to think about setting the profile parameter auth/rfc_authority_check to zero… danger, Will Robinson! → this has security implementations! 😕

Your options

Obtaining a list of called function modules per user is possible in various ways:

• the Security Audit Log (tcode SM19/20 » audit class “RFC call”)
• the Business Transaction Analysis (tcode STAD)
• … if you have another good idea, please leave a comment …

Using the Security Audit Log would imply some nasty problems: the log size per day is limited (parameters rsau/max_diskspace/*); all logs generated after that limitation is reached are lost.
The functionality of tcode STAD on the contrary quite exactly matches what we need. Furthermore, there is no need to configure anything, as the statistics are recorded anyway (in fact the profile parameter stat/level has to be set to 1… but that’s the system default). The structure which is used to record the statistics contains a field that holds the called function modules — so another benefit of the latter method is that we don’t have to split a text string (like the one stored in an Audit Log message text, e.g. “Successful RFC Call RFCPING (Function Group = SYST)”).

Solution

I chose the second solution — evaluating statistics from STAD —, because it seems to be smarter, more reliable… and allows me to code a bit! 😉

The next step is to create a new report called ZS_STAD_EXTRACT_RFC_CALLS and copy-paste this source code.

Then you need to set up two new customer tables that hold the data we want to collect.
Go to SE11 and create the tables ZSSTAD_RFC_DATA and ZSSTAD_LASTRUN.
I’d suggest using the following settings in the subsequent steps:

• Delivery class “A” = application table,
• Data class “APPL1” = transaction data, transparent tables (in: Technical settings),
• Size category “0” = up to 100.000 entries (in: Technical settings) and
• Enhancement category “Can be enhanced (deep)” (menu: Extras → Enhancement category)

The field definitions can be found in the top comment of the report source code; use them as shown below:

Then please repeat these steps for the second table.

Last but not least you should schedule the report to run every hour — that’s a good value because the runtime of the report stays rather short and there’s no danger of losing data (the retention period for STAD data is usually 48 hours, because the statistics files are written every hour and the parameter stat/max_files determines the number of files kept – 48 per default).

Update 1:
You also might want to increase the profile parameter stat/rfcrec, which determines the maximum number of RFC calls in a session that will be recorded in STAD. The default value of 5 is probably not sufficient for all cases!

Update 2:
Please check SAP Note 1964997 for information on the parameters stat/rfc/distinct and stat/rfc/distinct_depth, which are also relevant. Thanks to Christian Wippermann for pointing me to this!

Functionality

So, what does it do?
The report reads all statistics records since the time it was last started (which is saved in table ZSSTAD_LASTRUN) or — if that table contains no values — the ones in the last hour. The records are filtered for RFC calls (all other record types are discarded) and the called function modules’ groups are determined.
As the last step, this information is saved to table ZSSTAD_RFC_DATA.
It contains:

• the date (DATUM),
• SAP client (MANDT),
• calling user (UNAME),
• called function module (FUMOD),
• the respective function group (FUGRP) and
• the number of calls (NCALL) per line.

In the below example, the user SAPJSF called RFCPING 22 times on the 4th of May 2013 in client 000:

The information in this table will later be used to determine the values for S_RFC.

What’s next?

In part 2 of this series, I’ll post a nice evaluation report for the above log…

See you then!