Show TOC Anfang des Inhaltsbereichs

FunktionsdokumentationSecurity Policy  Dokument im Navigationsbaum lokalisieren

Use

The user management engine (UME) enables you to define a security policy that controls aspects such as the length and content of user passwords and logon IDs, or how the system carries out password checks. The UME checks for compliance to this policy in the following instances:

·        When users log on to SAP NetWeaver Application Server (AS) Java

Disabled by default, but you can enable it.

·        When users register themselves using the self-registration features of the UME

·        When users or administrators change user passwords with the UME

·        When administrators create new users with the UME

If the security policy is not adhered to, the UME provides detailed error messages where possible.

Integration

Integration with Security Policy of UME Data Source (ABAP or Directory Server)

You configure the UME security policy independently from the security policy of the ABAP or directory server data source. The UME does not take into account any special features of the data source’s security policy. If the data source has defined its own security policy, there is no standard interface to pass on any error messages from the data source to the UME user in the same level of detail and in the correct language. The user only receives a generic error message.

Beispiel 

The UME security policy specifies a minimum password length of 6 whereas a directory server defines a minimum password length of 8. When an administrator creates a user and enters a password with a length of six for the user, the password adheres to the UME policy but not to the directory server policy. As a result, the administrator gets a generic error message saying that the password is invalid, but not specifying why it is invalid.

To prevent the UME policies from getting in the way of the ABAP policies, the UME ignores its own security policies if you use an ABAP data source with the following exceptions:

·        When you create a new user, the UME checks the user name against its own security policies.

·        If you allow the UME to automatically generate a password, the UME generates the password according to its own security policy.

·        When a user creates a new password, the new password must conform to the UME password rules; for example, number of upper case letters or length. However, the system performs the password history check in the system where the password is stored. For a user stored in the ABAP system, the password history check takes place in the AS ABAP.

In contrast to when you use an AS ABAP as the data source, the UME security policies apply without exception if you use the Java database or a directory server for the data source.

Configuration Options

You have the following options to configure the security policy of the UME, both with different implications:

...

       1.      Define a security policy for the UME that is the same or stronger than the corresponding security policy in the back-end system.

Result: Users and administrators receive detailed error messages.

Implication: Error tracing is easier because you only need to look in the log files of the UME. Only in rare cases will you need to look in the log files of the data source (ABAP or directory server)

Disadvantage: Users or administrators might get different reactions for different access paths if the security policy is not the same such as in the following cases:

       The back-end system can be accessed directly (for example an ABAP system).

       The back-end system serves as a data source for other systems using a UME with different security policy settings.

       2.      Define a relaxed security policy for the UME.

Result: The UME security policy is so relaxed that only the data source catches any violations against the security policy. The UME cannot pass error messages from the back end in full detail, and as a result, users and administrators receive generic error messages.

Implication: Unexplained policy violations confuse users and administrators as to how they violated the security policy. Error tracing becomes more difficult because you must look in two locations to determine the cause, both in the UME log files and in the back-end log files.

Hinweis

Even if detailed error messages do not appear in the user interface of the UME, the UME writes error messages from the data source in the log files of the AS Java. Where it writes an error message depends on the data source.

       If the UME uses ABAP user management as a data source, detailed error messages are written in the security.log file.

       If the UME uses a directory server as a data source, the error messages depend on the directory server being used and are written as error codes in the default trace.

For more information, see Logging and Tracing.

       3.      Combine options 1 and 2. This makes error tracing difficult.

Beispiel

Define the minimum and maximum password lengths the same or more stringent than in the back-end data source so that users receive detailed error messages. You define all other security policy settings in the UME to be very relaxed. This means that all other settings are checked by the back-end data source.

Recommended Configuration

We recommend option 1. As far as possible configure the security policies of the UME and its data source to be the same. As a consequence, the UME catches any violations to the policy. This has the following advantages:

·        Users get meaningful error messages.

·        Error tracing is easier for the system administrator.

·        You obtain a homogenous security policy, regardless of whether you create users in the data sources using the UME tools or another means.

We recommend the following exceptions to the recommended configuration:

      Set the auto-lock capability of the UME for locking users who have made several unsuccessful attempts to log on dependent on whether the data source also provides this capability.

¡        If the UME data source provides this auto-lock capability, you should deactivate the check in the UME. For example, ABAP user management provides this feature, so if you use ABAP user management as a data source, you should deactivate the auto-lock feature in the UME.

To deactivate the auto-lock feature in the UME, set the security policy setting Maximum Number of Failed Logon Attempts to 0.

       If the UME data source does not provide the auto-lock function, you can activate it in the UME. In this case, it only applies for logons through the UME.

      If all your users are in the user management of an AS ABAP, deactivate the password history in the UME.

Features

The UME security policy provides the following features:

For more information configuring the security policy, see Configuring the Security Policy for User ID and Passwords.

·        Define the rules governing what a password looks like.

This includes:

¡        The maximum and minimum length of passwords

¡        Whether an old password can be part of a new password

¡        The number of alphabetic and numeric characters required

¡        The number of upper and lower case letters required

¡        The number of special characters required

¡        Whether the user ID can be part of the password

¡        How often a user can use the same password (the number of past passwords saved)

¡        If there are any passwords that are not allowed.

·        Define the rules governing what a user ID looks like.

This includes:

¡        The maximum and minimum length

¡        The number of numeric characters required

¡        The number of special characters required

·        Specify the number of failed logon attempts after which a user account is locked. Optionally the system can unlock the user after a certain amount of time elapses.

·        Define the conditions for password expiration. The user must set a new password after a set number of days. A default start value exists for when the user has never logged in and was created in an external system. You can also define a period of days after which a user, who has not logged in has his or her password deactivated. The user must contact the system administrator to get a new password. The user can still log on with other authentication mechanisms, such as client certificates. Here too, you can set a default start date.

      Specify whether business users can change passwords.

·        Specify whether the UMEchecks passwords for compliance with the security policy during password logon. If the user password does not comply, the user must change the password during logon. Use this feature to ensure password compliance after you make changes to the security policy.

Hinweis

Before you enable this feature, think if you want to force users in an existing data source to use the current UMEsecurity policy. This is especially true if the UMEsecurity policy is more stringent than an external data source, like a directory server.

      Specify whether the UME logs client host information.

To enable this function, you must edit the relevant UMEproperties.

For more information about editing UMEproperties, see Editing UME Properties.

For more information about UME properties for security policy, see Security Policy.

The relevant UME properties are:

¡        ume.logon.security_policy.log_client_hostaddress

¡        ume.logon.security_policy.log_client_hostname

Ende des Inhaltsbereichs