Daniel Berlin on Security Insight on SAP security, development stuff… and all the rest

4Oct 15

A note on SECPOL behavior

Howdy!SECPOL pitfall
Currently a lack of time prevents me from finishing a post, which is in the pipeline for weeks now. Nevertheless I'd like to point out a behavior of Security Policies, which might lead to an unexpected situation, if you're not aware of it (fortunately you will be).


Let us assume that you have hardened your system and set the password-related profile parameters login/min_password_lowercase = 1 and login/min_password_uppercase = 1. This forces users to include at least one lower- and one uppercase character in new passwords. The kernel default for both parameters is 0.
Additionally you set the parameter login/min_password_lng = 10 to enforce a minimum password length of 10 characters.

Unfortunately, there is an RFC user on your system, which must – for whatever technical reason – not have a password longer than 8 characters. As you don't want to lower the system setting, you choose to create a new SECPOL with just the attribute MIN_PASSWORD_LENGTH = 8 and leave the profile parameter as it is (= 10). The desired result is obviously to override the minimum password length with a lower value for just the one RFC user and stay with the more secure value for all other users.

(Possible) expectation

The SAP Help Portal says:
you create security policies with attributes, for which you explicitly do not want to use the default value.

So my initial expectation was, that a SECPOL attribute overrides the corresponding profile parameter (in our example MIN_PASSWORD_LENGTH overrides login/min_password_lng)… and all other profile parameters, for which SECPOL attributes exist, stay as they are set in the profile.
So login/min_password_lowercase could potentially be overridden by MIN_PASSWORD_LOWERCASE – but since we did not add it to our SECPOL, one could assume that the profile value stays intact.


Security Policies do not override profile parameters - rather they replace them! All of them.
All profile parameters, for which a SECPOL attribute exists, are replaced – so if an attribute is not explicitly set in a SECPOL, the kernel default value is used! Not the profile parameter value.

SECPOL vs. Profile Parameters

The bottom line

If you've set any of the profile parameter values, which can be influenced by a Security Policy, you have to make sure that all those profile parameters are explicitly set again in all of your SECPOLs!
So once you choose to make use of SECPOLs, you have to maintain all values at least twice: in RZ10 and in your Security Policy/ies… otherwise you end up using default values by mistake.

Yep... unspectacular... but still interesting :smile:


11Jan 15

New GitHub repository for REPOSRC decompressor

Hi all.
Some time ago, I posted a small C++ program that decompresses the source code stored in table REPOSRC
(⇒ check this article).
New GitHub repository
It was never intended to be more than a proof of concept, but since many people showed interest in it (and found bugs), I decided to create a GitHub repository:


It contains the history of my ancient CVS repository (converted thanks to this great how-to).

So… if you find any bugs or want to help improve it — please go there and either create an issue or simply fork it and unleash the developer in you).

See you!

14Nov 14

Weak parameter transactions in SAP

Hi there.Weak parameter transactions
In this article, we'll take a look at a potential weakness that is often considered minor and thus underrated – but might still be used to lever out important security measures: parameter transactions.
They basically execute another tcode… along with pre-defined screen input – the "parameters".

For example, the transaction code SM30_PRGN_CUST is a shortcut to SM30 for the maintenance view PRGN_CUST:
When you call it, SM30 is executed and table PRGN_CUST is opened in maintenance mode. Since the option "Skip initial screen" is enabled, it jumps directly into the table maintenance view itself – if it was disabled, one would be able to override the given screen options in the SM30 dynpro… including the table name! That's the point where the weakness starts.

Now let's select some more parameter transactions from table TSTCP.
They start with either "/*" or "/N" — the first one skips the called tcode's initial screen, the latter one doesn't.
Below you can find the selection options for all SE38 parameter transactions:

Selection for table TSTCP

Now let's have a look at the lines marked red and green in our result:

Table TSTCP: Result

The first one – SE38L – is unsafe, because the "/N" indicates that the SE38 selection screen is just filled out – but the report name can be overridden easily.

This means that SE38L is equivalent to SE38

Well… for SE38L, -M, -N this might not be a big surprise, but what about RBDCPCLR? … I never would have guessed!

Transaction SE38L

The second sample – SE38N – calls SE38 and executes report RDELALOG immediately: nothing to see here, move along.

Lessons learned

  • When you limit access to a transaction, always keep in mind that insecure parameter transactions might represent a backdoor.
  • Customer parameter transactions should always use the "Skip initial screen" option.

See you soon!

1Oct 14

Mass user creation in the Java UME

Welcome (back)!
User and authorization administration in the Java stack is a pain in the neck – that's a fact! The identity management tools are inferior as compared to the ABAP stack, but nevertheless there are ways to make your life a bit easier…

Mass user maintenance in the UME

When it comes to mass user creation/modification in the Java UME (database only, no ABAP- or LDAP-data source), no tool like SU10 exists and many admins choose the hard way of creating users one by one... but wait... the "Identity Management" screen has an "Import" button:

Java UME User Import

Standard Format for UME imports

The screen behind that "Import" button provides not much more than a text field, which needs to be populated with user master data in the correct format (btw.: the amount of importable data is limited to 1 MiB).
The import format is documented here, but SAP provides no easy solution to create data in that format.
This is – you probably guessed it – the point, where my solution comes in.

Generally speaking, the "Standard Format" – as SAP calls it – is similar to the format of many .ini files and thus quite simple.
It can be used to create and modify users, groups, and roles — for users, a typical import record looks like this:


Squeeze mass user data into the Standard Format

For this task, I've prepared a very simple Excel file for you… download it here:

Microsoft Excel file



You can insert the user name, first and last name, password and up to three roles for up to 100 users into column A-G.
The formula in column H generates the expected format from the input data.
Java UME user import: Excel sample
When finished, simply mark the cells in column H starting from line 2 (i.e. without the header).

Unfortunately, Excel is a very smart tool 😕 and automagically inserts quotation marks around the copied cells.
You need to remove these quote signs manually from the copied data…
Alternatively, you can also copy the clipboard's contents into an empty Word document, then copy everything again – that way the quotes are removed, too.

Afterwards, paste the data into the text area on the Import screen of the Identity Management; then click "Upload".

Java UME user import: Upload textarea

The protocol on the next screen contains information about the import result.

Java UME user import: Protocol

See you next time!

16Sep 14

Authorization trace with comfort function: STAUTHTRACE

Hey everybody.
Recently I wrote an article for a magazine published by the German-language SAP users group (DSAG).
In this post, I’d like to share an English translation with you (the original German version is available here: http://blaupause.dsag.de/berechtigungstrace-mit-komfort-funktion).

Have fun:

Authorization trace with comfort function:

One of the numerous new features of Enhancement Package 6 is the authorization trace via transaction STAUTHTRACE. In principle, it works like the system trace ST01, but is limited to authorization checks. This makes it a valuable tool for authorization admins and provides comfortable functions.

So far, it was necessary to start an authorization trace on all application servers of a system separately, unless the relevant server was known beforehand. Transaction STAUTHTRACE simplifies this and allows starting a trace on one or more servers in a single step:

Start STAUTHTRACE (system-wide)
Without an explicit selection, the system-wide trace is automatically started on all available servers:

STAUTHTRACE is running on all servers
The evaluation section in the lower half of the screen offers detailed options to analyze the result and is much advanced in comparison to ST01.
In a system-wide trace, the selection of the application server in the topmost section is also taken into account.

STAUTHTRACE evaluation options
The option "Evaluate Extended Passport" is extremely handy, as it enriches the trace result with data from the system's kernel statistics (transaction STAD).
This additional information is helpful when it comes to RFC calls from other systems and consists of the following fields:

  • "Initial Component" — the calling system, instance and client
  • "Action Type" — e.g. a batch job run or a transaction call
  • "Initial Action" — e.g. the name of the job or transaction code

The result is finally displayed in a nice, filterable ALV grid and not in that ugly ST01 list view.

Additionally, it is possible to dive into each line and jump to the affected user, the authorization object and its documentation as well as the line in the source code that triggered the authorization check. Simply double-click in the list or use the menu:
Further options in STAUTHTRACE result

How to use the trace result in PFCG

The result of an authorization trace can be used in PFCG directly now - no matter, whether it comes from STAUTHTRACE or the traditional ST01.

This can be achieved in two ways:

  • Maintenance via the role menu

The "Import from Trace" option in a role's "Menu" tab allows importing the called applications from the trace: Transactions (S_TCODE), External- or Web-Services (S_SERVICE) and RFC Function Modules (S_RFC).

Unfortunately, if you import a transaction call, only the tcode is adopted from the trace - the other values that are checked during transaction start and execution are ignored; instead, the suggested values from SU24 are used.

Import STAUTHTRACE result in role menu

  • Maintenance of authorization values

In the role's authorization data maintenance screen, the new button "Trace" can be used to import the values that were checked from the result into the role.
Trace button in PFCG authorization data screen
In the below example, the role already contains the object S_USER_GRP – but no values yet. The actual check in this case used 02 for the field ACTVT and the user group (CLASS) was "SUPER" – these values can easily be imported from the trace data with some clicks.

Import STAUTHTRACE result in role authorization data

Bottom line
💡 The new trace functionality of EhP 6 is a great feature for the analysis of authorization needs and problems - a neat enhancement of the existing toolbox!

Page 1 of 612345...Last »