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. In the meantime, I’d like to quickly write about a behavior of Security Policies, which might lead to an unexpected situation, if you’re not aware of it (fortunately you will be).

Circumstances

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.

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.

Result

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 🙂

Cheerio!

4 comments

  1. Thanks for posting this. This behavior was interpreted as bug by me as well but, it looks like SAP intended security policy to work this way.

  2. Hi Daniel,
    is this still working the way you stated “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!” or has SAP fixed this?

    1. Hi Karthik,
      I’m afraid, SAP doesn’t considers this behavior a bug – it just “works as designed”… so I don’t expect any fix.

      I asked SAP some time ago and received this official answer:
        [... this] is not an error, but a desired standard behavior. [...]

      Regards, Daniel

  3. Good job explaining the behavior – which unfortunately is required as it doesn’t work as most people would expect!

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.