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.

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:

Security policy creation

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

Attributes

The following attributes are available:

TypeSecurity policy
attribute
Corresponding
profile parameter
Description
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
policies
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,
login/password_logon_usergroup
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

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:

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!

13 comments

  1. 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.

    1. 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

  2. Is there a report where we can see which users are not complying with the security policy defined?

  3. This document about security policy and subsequent questions and answers really helps.
    Thanks a lot and much appreciated!

  4. 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?

      1. 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

  5. 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).

  6. Hi Daniel.
    From an auditing perspective, is there an easy way to see which users have security policies assigned to them?

    Regards, Peter

    1. 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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.