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.
Effect
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.
Creation
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:
… then mark it and switch to the attribute maintenance screen by double-clicking on “Attributes”.
Attributes
The following attributes are available:
| Type | Security policy attribute | Corresponding profile parameter | Description |
|---|---|---|---|
| Password rules | CHECK_PASSWORD_BLACKLIST | ( none ) | Check the password blacklist |
| MIN_PASSWORD_DIGITS | login/min_password_digits | Minimum number of digits | |
| MIN_PASSWORD_LENGTH | login/min_password_lng | Minimum password length | |
| MIN_PASSWORD_LETTERS | login/min_password_letters | Minimum number of letters | |
| MIN_PASSWORD_LOWERCASE | login/min_password_lowercase | Minimum number of lowercase letters | |
| MIN_PASSWORD_SPECIALS | login/min_password_specials | Minimum number of special characters | |
| MIN_PASSWORD_UPPERCASE | login/min_password_uppercase | Minimum number of uppercase letters | |
| Password change policies | MIN_PASSWORD_CHANGE_WAITTIME | login/password_change_waittime | Minimum wait time for password change |
| MIN_PASSWORD_DIFFERENCE | login/min_password_diff | No. of different characters when changing | |
| PASSWORD_CHANGE_FOR_SSO | login/password_change_for_SSO | Password change requirement for SSO logons | |
| PASSWORD_CHANGE_INTERVAL | login/password_expiration_time | Interval for regular password changes | |
| PASSWORD_COMPLIANCE_TO_CURRENT_POLICY | login/password_compliance_to_current_policy | Password change after rule tightening | |
| PASSWORD_HISTORY_SIZE | login/password_history_size | Size of the password history | |
| Logon restrictions | DISABLE_PASSWORD_LOGON | login/disable_password_logon, login/password_logon_usergroup | Disable password logon |
| DISABLE_TICKET_LOGON | ( none ) | Disable ticket logon | |
| MAX_FAILED_PASSWORD_LOGON_ATTEMPTS | login/fails_to_user_lock | Maximum number of failed attempts | |
| MAX_PASSWORD_IDLE_INITIAL | login/password_max_idle_initial | Validity of unused initial passwords | |
| MAX_PASSWORD_IDLE_PRODUCTIVE | login/password_max_idle_productive | Validity of unused productive passwords | |
| PASSWORD_LOCK_EXPIRATION | login/failed_user_auto_unlock | Automatic 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).
Assignment
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:
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!
I don’t see CUA support SECPOL. But you mentioned it does. Does this support available in Solman 7.2 version?
We have Solman 7.1 and don’t have SECPOL.
Hi Gaurav,
the CUA does support Security Policies (provided you have a SAP_BASIS version, which supports SECPOL). If so, you can open transaction SCUM and determine in the “Logon data” tab, if the field will be distributed to the systems, which are connected to your CUA. Of course they need to have the proper SAP_BASIS version, too…
SECPOL was introduced with NetWeaver 7 EhP 3 (SAP_BASIS 7.03).
Regards, Daniel
Is there a report where we can see which users are not complying with the security policy defined?
Hello Erika,
what exactly are you expecting from such a report?
Kind regards, Daniel
This document about security policy and subsequent questions and answers really helps.
Thanks a lot and much appreciated!
Hi
I have a case, where I would like to create a security policy where the only difference from my general password policy (RZ11) is, that the users should change password every 30 days instead of every 90 days. I would assume that I should create a security policy where I set PASSWORD_CHANGE_INTERVAL to 30 and then all other parameters would be inherited (= match general policy) but the “Effective” button shows different values that I would expect. It does not reflect my current values from RZ11 but the kernel default values.
I would characterize this as a bug. Do you aggree?
Hi Morten,
please check my post on this behaviour: A note on SECPOL behavior.
It’s really strange behaviour… but SAP would probably argue that it “works as designed”… 🙁
Kind regards, Daniel
Thank you. It explains the issue perfectly. I think I will raise an OSS and tell SAP that if it is “works as designed”, then the design is bad 🙂
Kind regards, Morten
Hi Daniel,
is it possible to have a security policy for a group rather than users? – such that once I maintain the user group for a user, policy associated with that group gets applied by default?
This would mean higher flexibility, while managing the users (for e.g. say disable password logging for firefighter IDs).
Nope – not possible (currently)…
Hi Daniel.
From an auditing perspective, is there an easy way to see which users have security policies assigned to them?
Regards, Peter
Hi Peter,
you can check the assignment of users to security policies via:
➡ SUIM: “Users > by Complex Selection Criteria” or “Users > by Logon Date and Password Change”
or
➡ directly in table USR02 (field SECURITY_POLICY).
Regards, Daniel
Great, thanks for that. Will add this to our SAP audit plan.