Sniffing SAP GUI passwords // Part 2

Hello and welcome (back)!

In my article about Sniffing SAP GUI passwords in Nov. 2012, I took a look at several state-of-the-art sniffing tools for capturing SAP GUI passwords.
One of those tools was a Wireshark plugin by Martin Gallo of CoreLabs — unfortunately, it refused to compile over and over again, which is why I never tested it… but meanwhile, Martin released an improved version.

Fortunately, I took the time to try it, because it turned out to be a real gem — a bit hard to obtain, but pretty useful once you got it. 😉

The nice part: Usage

In contrast to the other Wireshark plugin by Positive Research, this one does not only decompress but also dissect almost all parts of the traffic and shows the respective fields and values (below you can see a DDIC login with the password in plain text).
Another invaluable advantage is of course its availability as source code!

Sniffing the SAP DIAG protocol: Wireshark with CoreLabs plugin

The nasty part: Compilation

The following script does the trick, although you’ll probably want to adjust it to the build environment, the Wireshark version and your needs…
(It assumes to be run from the directory, where the plugin tarball is located.)

#!/bin/bash -ex
rm -rf wireshark
svn co wireshark
mkdir wireshark/plugins/sap
tar -C wireshark/plugins/sap -xzf sap-wireshark-plugin-0.1.3.tar.gz
cd wireshark
cat plugins/sap/wireshark.patch | patch -p0
test -x /usr/bin/python2 && export PYTHON=/usr/bin/python2
./configure --prefix="$PWD" --disable-warnings-as-errors
make install

See you soon!

+++ End of article +++
+++ Begin of article +++

SAP security policies

Hi there.

This time I’d like to present a hot new SAP feature to you: Security Policies!
It is available starting from ERP 6.0 EHP6.


The system behavior regarding password rules and logon restrictions is controlled by profile parameters, e.g. “login/min_password_lng” for the minimum password length. These parameters are valid system-wide and could not be overridden by any means.
With the new security policies, it is now possible to define different sets of password rules, password change policies and logon restrictions and assign these policies to users.

This provides the flexibility to segregate users and assign an appropriate policy to each of those groups of users!
For instance, you can enforce strict rules on the global level (= profile parameters) and loosen them on user level via a security policy (e.g. increased validity period of unused initial password for users, who use SAP less frequently).

For users with a security policy assignment, the attributes defined therein override replace the profile parameters – for users without a SecPol the parameters stay relevant.


The administration of security policies can be performed via the new tcode SECPOL, which is secured by two brand-new authorization objects: S_SECPOL is checked during the maintenance of the policies themselves, while S_SECPOL_A is used to define the values that may be assigned to the security policy attributes.
First of all, let’s create a new policy:

Security policy creation

… then mark it and switch to the attribute maintenance screen by double-clicking on “Attributes”.


The following attributes are available:

TypeSecurity policy
profile parameter
Password rulesCHECK_PASSWORD_BLACKLIST( none )Check the password blacklist
MIN_PASSWORD_DIGITSlogin/min_password_digitsMinimum number of digits
MIN_PASSWORD_LENGTHlogin/min_password_lngMinimum password length
MIN_PASSWORD_LETTERSlogin/min_password_lettersMinimum number of letters
MIN_PASSWORD_LOWERCASElogin/min_password_lowercaseMinimum number of lowercase letters
MIN_PASSWORD_SPECIALSlogin/min_password_specialsMinimum number of special characters
MIN_PASSWORD_UPPERCASElogin/min_password_uppercaseMinimum number of uppercase letters
Password change
MIN_PASSWORD_CHANGE_WAITTIMElogin/password_change_waittimeMinimum wait time for password change
MIN_PASSWORD_DIFFERENCElogin/min_password_diffNo. of different characters when changing
PASSWORD_CHANGE_FOR_SSOlogin/password_change_for_SSOPassword change requirement for SSO logons
PASSWORD_CHANGE_INTERVALlogin/password_expiration_timeInterval for regular password changes
PASSWORD_COMPLIANCE_TO_CURRENT_POLICYlogin/password_compliance_to_current_policyPassword change after rule tightening
PASSWORD_HISTORY_SIZElogin/password_history_sizeSize of the password history
Logon restrictionsDISABLE_PASSWORD_LOGONlogin/disable_password_logon,
Disable password logon
DISABLE_TICKET_LOGON( none )Disable ticket logon
MAX_FAILED_PASSWORD_LOGON_ATTEMPTSlogin/fails_to_user_lockMaximum number of failed attempts
MAX_PASSWORD_IDLE_INITIALlogin/password_max_idle_initialValidity of unused initial passwords
MAX_PASSWORD_IDLE_PRODUCTIVElogin/password_max_idle_productiveValidity of unused productive passwords
PASSWORD_LOCK_EXPIRATIONlogin/failed_user_auto_unlockAutomatic expiration of password lock

The button “Effective…” shows the relation of the policy values to the default ones (=, ≠ or not set), while the “Superfluous Entries” button identifies unnecessary entries (i.e. identical to the default ones).

Security policy attribute maintenance


To assign the newly created security policy, just edit a user in SU01, switch to the “Logon Data” tab and enter the SecPol name in the “Security Policy” field:

Security policy assignment via SU01

Mass-assignments via SU10 are of course possible, too!

To be able to assign a SecPol, you’ll need the authorization object “S_SECPOL”, which behaves similar to S_USER_AGR – i.e. activity 22 (assign) and the policy’s name are checked.

If you want to select users by their security policy assignment, you can simply use the User Information System:

SUIM » User » by Logon Date and Password Change

Central user administration

The security policy ↔ user assignment is supported by the CUA and its distribution can be configured via SCUM as usual.

See you soon!

+++ End of article +++
+++ Begin of article +++

Cross-client SAP user listing


You might be faced with the task to create a really comprehensive user listing for an SAP system with several productive clients – even including 000 and 066.

This is usually a boring task, as you have to log in to every client… gather the list… proceed to the next client… and so on…
Apart from dying of boredom, you might run into the problem of not having access to all clients (e.g. 066). 😕

Mediocre solution:

Write a report like this:

TABLES: usr02.
  WRITE: / usr02-mandt, usr02-bname.

Pro: Easy, simple, fast.
Con: Has to be transported, protected… and using “CLIENT SPECIFIED” is considered “bad code” by many companies! So you might get problems during transport.

Slick solution:

Use the report RSUVM005, which is intended for system measurement: it gives you a list of (almost!) all users on the clients you specify on the selection screen.
Still, the list is missing a few users, because SAP quite rightly considers them irrelevant for licensing — they are automatically filtered out by the report (or more specifically: by the function module SLIM_EXCLUDE_USER):

SAP clientExcluded user
( all other clients )ALEREMOTE

To get the comprehensive user listing, we just need a cross-client selection for those excluded user names in addition.
Fortunately, you can simply achieve this via tcode SM21 and (mis-)use the “User” field to check for the existence of the missing users on other clients.

SM21 cross-client user selection

Now you can compile the cross-client user listing from within one client… 😎


+++ End of article +++