You might already know that, as of Release 7.40 Sp8, you can use SAP security policies to define user-specific security parameters, contrary to the system profile values. But did you also know that you can inadvertently weaken secure values such as login restrictions and password complexity as a result?
Our practical tip will show you how to effectively prevent such a weakening.
You can set the parameters of your security policies in a different manner according to:
1. password complexity
2. password change interval
3. login restrictions
You use transaction “SECPOL” to maintain the security policies and you have the option of defining as many policies as you wish.
The relationship between “Security Policy Tag” and system profile values at a glance:
Transaction SU01 is then used for the assignment to users:
But be careful because there’s a major catch!
Security Policies do not overwrite individual profile values, but replace ALL values.
This means that values that you do not define in a Security Policy are not set to the secure values according to RZ10 parameters, but to insecure kernel values in user context.
Thus, you can inadvertently weaken secure values such as login restrictions and password complexity. The following example shows such behavior:
Our experience in projects has shown that many customers do not expect this behavior. The general expectation is that parameters can be set contrary to the default settings. However, this is not the case.
Our tip for you:
– Use Security Policies only if you define ALL values in a completely similar manner to the RZ10 parameters and make only a few values stronger or weaker.
– Remember that you are adjusting all Security Policies when you strengthen corresponding RZ10 system parameters.
To secure your SAP systems, our SAST SUITE provides extensive testing in the context of Security Policies specifically for this case. The SAST SUITE immediately shows relevant misconfigurations, weaknesses, and assignments of insecure values to users.
Contact us: knowhow@akquinet.de
