SAP Security policies / Group policies
Introduction
With the increased importance of information security and demand for securing systems, SAP started introducing a new feature called Security policies which are similar to Group policies in Active directory.
Basic use of these policies is to control set of users with the required options, which means today in SAP all the security related parameters are common for all users. With introduction of security policies we can now provide different restrictions for different users. For example, users in factory need more flexibility because their accounts need to be highly available.
So now companies can plan or segregate the users based on the need. The main advantage is companies can enforce strict laws on global level (for all users) and can create flexible security policies for set of users for required parameters like auto unlock accounts.
Definitions from SAP
A security policy is a collection of security policy attributes and their values. This procedure replaces the definition of behavior with profile parameters: once a security policy is assigned to a user master record, this determines the desired behavior; profile parameters are only relevant for those user master records for which no security policy has been assigned.
Security Policy Attributes (Definition)
A security policy attribute is always an element of a security policy. You can use security policy attributes to define behavior with regard to:
- Password Rules
- Password Changes
- Logon Restrictions
Use
In the application for Maintaining Security Policies (Transaction- SECPOL), you can documentation for an attribute by calling the input help (F4) for the relevant attribute value.
How to create /access Security policies:
Use transaction code SECPOL – Switch to change mode and Click on “New entries” to create a new security policy.
Once you have created the security policy, select the policy and double click on “Attributes”
Below screen will be displayed and here you need to select the attributes required for the same under “Policy attribute Name” .
Below are the available attributes for security policies.
The button “Effective” shows the result of the policy in the security policy screen shows as below.
“Superfluous” shows if there are any unnecessary entries (for example the global values and security policy values are same). In the below screen you can see that system shows “CHECK_PASSWORD_BLACKLIST” is unnecessary item as this value is same as system parameter value.
How to add this security policy to a User:
Edit the required user in transaction SU01, and enter the required security policy in Logon data tab as shown below.
Note: My ECC system’s version is EHP6 FOR SAP ERP 6.0.
Useful Links:
http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/7f/c52442ad9f5133e10000000a155106/content.htm
In my Project we are using solution manager CUA..when I tried this transaction SECPOL in solman, I'm getting error 'Transaction does not exist'
..Is it possible to use security policies in CUA
check this......http://help.sap.com/saphelp_nw73ehp1/helpdata/en/41/019a4dba8d4afcb9e6a12003e40a2a/content.htm
Hi,
I don't think this feature has been released in all kinds of SAP Systems. So far I have seen this in ECC only.
Hi,
first of all, If I am not mistaken this feature was introduced into Netweaver platform with releases 7.03 and 7.31. As far as I remember SAP is merging two branches of Netweaver and these releases are idnetical. But that's another story. So your Solman has to be on one of these versions. ECC6 with enhancement pack 6 requires 7.03 so you can use it there. Not sure if any Solman version is supported on 7.03.
Anyway, I doubt that this attribute is supported by CUA. SAP said in past that there won't be any enhancements for CUA. So even if you upgrade your Solman and all children to sufficient release then CUA won't be able to transfer this attribute from master system to child system. SAP would need to enhance IDoc that is used by CUA with a new attribute. As I said I am guessing here but I don't think that SAP will do it. But I might be wrong. So it seems that answer is no, you can't use this with CUA.
The good news is that it's supported by IdM (see note 1563386).
Cheers
The attribute is supported in CUA and that is where we started testing it. It is also controlled via a SCUM setting in CUA.
Hello,
Do you know if it's possible to add some parameters in the list of proposal parameter (login/password_max_idle_initial for example) ?
Dominique
login/password_max_idle_initial
Anyone care to resond to this? Its going to be very helpful if we can add parameters.
How do we go about adding parameter in the attributes? I want to add "login/password_max_idle_initial" in the attributes as we require different times for different users.
Hi Ruel
That parameter is already available to maintain with value "MAX_PASSWORD_IDLE_INITIAL" as per sap help instructions.
You would need to create different policies for each of these scenarios. Each user can only have one policy, however so you would need to consider the other parameters you want to set.
Regards
Colleen
Thanks! But how about other parameters that are not there? How do we add them? Like "rdisp/gui_auto_logout" and "rdisp/plugin_auto_logout"
This security policy only applies for parameter settings in reference to password security. You can not add any additional parameters from RZ10 there.
Is the Security Policy only available on ECC. And not on SRM/SCM/PI?
the security policy is a feature of the SAP basis and thus it is available for SRM/SCM/PI as well, as long as the SAP Basis level is 731 or higher. See
http://service.sap.com/sap/support/notes/2018918
for details.
BTW: the link cited in the blog is misleading, as it points to the JAVA policies.
This is the link for ABAP Defining Security Policies - Identity Management - SAP Library.
Kind regards,
Patrick
Nice.
TKS for your post.
Hi,
I have a set of ERP systems with CUA to manage all user attributes.
Child systems are EHP6 (SAP Basis 7.31) and support security policies, but SolMan is SAP Basis 7.02 and do not support it.
Security Policy filed is editable in SU01 of child systems, but is it advisable to manage it locally this way? What will happen if I decide to upgrade SolMan in the future and I have this attribute already in place in child systems?
Regards,
Monia