Maintaining Access Control and User Administration

The following slides show you the most important settings, and the profile parameters with which you can control password and logon rules. Control using these values should protect your system against any type of misuse by users.

There are two ways in which you can control the choice of user passwords:

• You can use the system profile parameters to assign a minimum length for passwords and define how often users must set new passwords.

• Invalid passwords can be entered in the table of reserved passwords, USR40. This table is maintained with transaction SM30. The entries can also be made generically:

  • "?" denotes a single character

  • "*" denotes a character string

Example:

• If you enter "123*" in table USR40, passwords may not begin with the character string "123*".

• If you define "*ABC*", passwords cannot contain the character string "ABC" in any position.

There are general rules for passwords that cannot be deactivated. A password:

• Must be at least six characters long (by default)

• Must not begin with "?" or "!"

• Must not be "pass"

• The new password must differ from the old one by at least one character

There are also a number of predefined password rules, which are shown on the next slide.

There are now around 30 profile parameters in the SAP system that start with "login". Due to the large number of parameters, only a few have been listed here as examples. For more information, see the parameter descriptions (for transaction RZ11) or the online documentation.

login/min_password_lng

You can set the minimum length for passwords with the parameter login/min_password_lng. By default, the password must be at least "6" and no more than "40" characters long. The parameters login/min_password_digits, login/min_password_letters, login/min_password_lowercase, login/min_password_uppercase, and login/min_password_specials specify the minimum number of digits, letters (number of upper and lower case) or special characters that a password must contain. The value range is 1 to 40.

login/password_expiration_time

The parameter login/password_expiration_time specifies the number of days after which a user must set a new password. If the parameter is set to 0, the user does not need to change his or her password.

login/password_max_idle_initial

The parameter login/password_max_idle_initial indicates the maximum length of time during which an initial password (a password selected by the user administrator) remains valid if it is not used. Once this period has expired, the password can no longer be used for authentication. The user administrator can reactivate the password logon by assigning a new initial password.

login/password_max_idle_productive

This parameter indicates the maximum length of time a productive password (a password chosen by the user) remains valid when it is not used. Once this period has expired, the password can no longer be used for authentication. The user administrator can reactivate the password logon by assigning a new initial password.

login/min_password_diff

With the parameter login/min_password_diff, the administrator can determine the number of different characters a new password must possess in comparison with the old one when users change their passwords. This parameter does not take effect when a new user is created or passwords are reset (==> initial password).

login/fails_to_session_end

You can set the number of failed logon attempts after which SAP GUI is terminated using the parameter login/fails_to_session_end. If the user wants to try again, he or she must restart SAP GUI.

login/fails_to_user_lock

You can set the number of failed logon attempts after which a user is locked in the SAP system using the parameter login/fails_to_user_lock. An entry is written in the system log at the same time. The failed logon counter is reset after a successful logon attempt.

login/failed_user_auto_unlock

At midnight (server time), the users that were locked as a result of incorrect logon attempts are no longer automatically unlocked by the system (default value since SAP NetWeaver 7.0). You reactivate this automatic unlocking with the parameter login/failed_user_auto_unlock = 1.

The administrator can unlock, lock, or assign a new password to users in user maintenance (transaction SU01).

login/disable_multi_gui_login

If the parameter login/disable_multi_gui_login is set to 1, a user cannot log on to a client more than once. This can be desirable for system security reasons. This parameter applies to SAP GUI logons. If the parameter is set to 1, the user has the following options when he or she logs on again: "Continue with this logon and end any other logons in the system" or "Terminate this logon". Users to whom this should not apply should be specified in the parameter login/multi_login_users, separated with commas, and with no spaces.

login/min_password_lowercase

login/min_password_lowercase: In accordance with the parameter value, the password must contain at least "x" lowercase letters. The default value is "0".

login/min_password_uppercase

login/min_password_uppercase: The parameter value defines the minimum number of uppercase letters a password must have. The default value is "0".

login/password_change_waittime

login/password_change_waittime: Users can change their passwords again only after waiting for a specified amount of time. The default value is "1", which means the user must wait a day to change his or her password again. User administrators, however, can change or reset the password of users as many times in a day as they need.

login/password_charset

login/password_charset: The default value is "1". This parameter is used only if downward compatible passwords need to be generated. It specifies which characters can be used in the password. All Unicode characters are allowed, by default.

login/password_downwards_compatibility

login/password_downwards_compatibility: The system generates downward compatible password hashes, which correspond to an "8" character long password. Downward compatibility is required for RFC communication with older SAP releases. The default value is "1".

Essentially, there are two types of special users: those created by installing the SAP system and those created when you copy clients.

During the installation of the SAP system, client 000 is created. Depending on the SAP system that is installed clients 001 and 066 are created in addition. Special users are predefined in the clients. Since there are standard names and standard passwords for these users, which are known to other people, you must protect them against unauthorized access.

SAP* is the only user in the SAP system for which no user master record is required, since it is defined in the system code. SAP* has, by default, the password "PASS", and unrestricted access authorizations for the system.

When you install the SAP system, a user master record is automatically created for SAP* in client 000 (and in 001 if it exists). At first, this still has the initial password "06071992". The administrator is required to reset the password during installation. The installation can continue only after the password has been changed correctly. The master record created here deactivates the special properties of SAP*, so that only the authorizations and password defined in the user master record now apply.

This user is responsible for maintaining the ABAP Dictionary and the software logistics.

When you install the SAP system, a user master record is automatically created in client 000 [001] for the user DDIC. With this user too, you are requested to change the standard password of "19920706" during the installation (similar to the user SAP*). Certain authorizations are predefined in the system code for the DDIC user, meaning that it is, for example, the only user that can log on to the SAP system during the installation of a new release.

The EarlyWatch user is delivered in client 066 and is protected with the password "SUPPORT". The EarlyWatch experts at SAP work with this user. This user should not be deleted. Change the password. This user should only be used for EarlyWatch functions (monitoring and performance).

How can you counter this problem to protect the system against misuse?

• You can deactivate the special properties of SAP*. To do this, you must set the system profile parameter login/no_automatic_user_sapstar to a value greater than zero. If the parameter is active, SAP* no longer has any special properties. If the user master record SAP* is deleted, the logon with PASS no longer works.

• If you want to reinstate the old behavior of SAP*, you must first reset the parameter and restart the system.

Sometimes users require a different security policy for log on and passwords than the default values. For example, powerful users such as administrators should have passwords with a higher level of protection than standard users. Such users should be forced to change their passwords more often or have more complex rules for their passwords. However, such requirements, if applied widely, can cause an increase in help desk requests if you force standard users to comply with such requirements.

Use this field to choose a security policy for the user. Otherwise, the user uses the standard security policy.

With this procedure, you create security policies with attributes, for which you explicitly do not want to use the default value. For example, you assign a new security policy called Digits, and change, as described below, the standard value for the attribute MIN_PASSWORD_DIGITS from 0 to 4. The new security policy Digits then uses the standard values for all security policy attributes, with the exception of the attribute MIN_PASSWORD_DIGITS. You can, however, also create a security policy without defining attributes. This policy then uses the default values for all security policy attributes.

Procedure:

1. Start the maintenance tool for security policies (transaction SECPOL).

2. In change mode, choose New Entries.

3. Enter a name in the Security Policy field and a description in the Short Text field.
4. Double-click the Attributes node.
5. Select the security policy, and double-click the Attributes node again. The change view for attributes appears.

6. Choose New Entries.

7. In the field Policy Attribute Name, enter, for example using the input help, a security policy attribute and, in the Attribute Value field, a value.

   Hint

   Once you have specified all of the attributes to be changed, you can display the attribute values that actually apply for the policy. To do this, choose the Effective button. The system displays both the attributes that you changed and the attributes that have been retained with default values in the security policy.

8. Save your entries.

The security policy could be assigned to a user by using the user maintenance tool (transaction SU01), or assign it to multiple users using mass user maintenance (transaction SU10). On the Logon Data tab, enter a security policy for the user, in the Security Policy field.

During maintenance work, only certain administrators should be able to log on to the system. The logon of users to the application server could be restricted by setting the new profile parameter login/server_logon_restriction.

The following values are possible:

• 0: No restriction.

  All users can log on to the application server.

• 1: A logon to the application server is allowed only with special rights.

  Only those users whose assigned security policy contains the new attribute SERVER_LOGON_PRIVILEGE with the value 1 can log on to the system. To change the security policy, use transaction SECPOL. Change the relevant security policy that you have assigned only to your administrators. Include the guideline attribute SERVER_LOGON_PRIVILEGE in the security policy and set the value to 1. Users who log on to the system without special rights see the following error message: Server is currently not generally available (restricted logon).

• 2: No logon is allowed to the application server.

  Users who log on to the system see the following error message: Server is currently not available (logon not permitted).

• 3: An external logon to the application server is allowed only with special rights.

  Only those users whose assigned security policy contains the attribute SERVER_LOGON_PRIVILEGE with the value 1 can log on to the system externally. Users who try to log on to the system externally without special rights see the following error message: Server is currently not generally available (restricted logon).

• 4: No external logon to the application server is allowed.

  Users who try to log on to the system externally without special rights see the following error message: Server is currently not available (logon not permitted).

To lock all inactive users, use the report RSUSR_LOCK_USERS with which you can automatically select and lock. On the selection screen of the report RSUSR_LOCK_USERS, select the criteria that you want to apply for locking the user. You have the option to check the result of the selection and display the users that you found or to lock the users immediately. Bear in mind that only a local user lock is set. You can execute the report online and in the background.

In the area of authorizations, there are a few objects that occur regularly, and are used and specified for daily queries. To clarify their use, some of these objects are described in the following pages.

Example:

• Authorization 1:

  The user calls transaction PFCG (Role Maintenance). He or she can only call Role Maintenance if he/she has authorization for this transaction code.

• Authorization 2:

  The user calls report "Display users with incorrect logons" from the area menu. Transaction code S_BCE_68001402 is assigned to this report. The user can only execute this report if he or she has authorization for this transaction code.

All the objects of an area menu are checked with authorization object S_TCODE since a transaction code is assigned to each executable menu entry (reports, transactions). This was implemented during the migration of report trees to area menus.

Authorization object S_TABU_DIS defines which table contents may be maintained by which employees.

The authorization object S_TABU_DIS controls only complete accesses, which are made using standard table maintenance (SM31), advanced table maintenance (SM30), or the Data Browser (SE16). These group assignments are defined in table TDDAT.

The object consists of the following fields:

• DICBERCLS: Authorization group for ABAP Dictionary objects (description - maximum of 4 characters)

• ACTVT: Activity (02, 03).

Authorization 1:

In this case, table entries may be added, changed or deleted (ACTVT:=02), but only tables/views assigned to authorization group "V*" (DICBERCLS=V*) may be maintained.

SAP standard tables are assigned to authorization groups. These assignments can be changed ("SM30"). You should consider this carefully, however. Depending on the setting, some maintenance dialogs could produce data inconsistencies thereafter.

The important tables are:

• V_DDAT_54: Assignment of authorization group to tables/view.

• V_BRG_54: Assignment of authorization groups to tables/views.

The table authorization group of a table or maintenance view can be assigned using transaction SE11 or SE54. The permitted table authorization groups are defined using transaction SE54 or those defined in the maintenance dialog V_TBRG_54.

The maximum length of a table authorization group name is only four characters. It is therefore very difficult to represent a meaningful name concept. Using a parameter namespace is not possible.

In addition to the previous maintenance tools for the authorization groups based on the table TBRG, a central maintenance environment (transactions STBRG and STBRG_OBJ) is provided. As well as the ability to define authorization groups independently of the client, these can now also be provided as workbench objects (transport object SUCU) across clients. As part of this enhancement, the authorization field for table authorization groups was extended from four to fourteen characters, so that namespace-based authorization groups could be defined and assigned for the authorization object S_TABU_DIS as of this maintenance level (see SAP note 1645260 - Enhanced maintenance of table authorization groups).

The authorization concept for generic table access using such standard transactions as SE16, SE17, SM30, SM31 or SM34 was previously only bound to the authorization object S_TABU_DIS. With SAP note 1481950 - New authorization check for generic table access, the authorization concept was enhanced with the authorization object S_TABU_NAM that checks access at the table name level. If a user does not have any S_TAB_DIS authorization for a certain table, the system also checks whether the user has an S_TABU_NAM authorization. The access is permitted if the user has an S_TABU_NAM authorization.

The authorization object S_TABU_NAM contains the fields:

• ACTVT: Activity (02, 03).

• TABLE: Name of table or view to be checked

With this object, the system checks the view names or table names directly so that an exact authorization check is possible.

Authorization object S_TABU_CLI: Grants authorization to maintain cross-client tables with the standard table maintenance transaction (SM31), extended table maintenance transaction (SM31), and the Data Browser, and also in the Customizing system. It also acts as an additional security measure for cross-client tables and enhances the general table maintenance authorization S_TABU_DIS.

The object has the following field:

CLIIDMAINT: If identifier "X" or "*" is set, cross-client tables can be maintained.

By introducing organization criteria, you can restrict a user's access rights to specific parts of a table. A possible use for S_TABU_LIN is to display and to change content for only a certain work area, such as a country or a plant.

As you can see in the graphic, the object consists of fields.

• 02: Add, change, or delete table entries

• 03: Only display table contents.

Table key fields/row authorization, such as organizational criteria (defined in Customizing)

Attributes 1 to 8 for the organizational criterion; each attribute for a certain table key field.

As is familiar from previous releases, it is possible to check programs using the authorization object S_PROGRAM.

The programs (reports) are combined into program authorization groups and can be protected against unauthorized access using the groups. The authorization group is stored in the properties of the programs.

You can also store your own authorization groups in SAP programs (without making modifications).

You can assign authorizations for the following activities by program groups:

• Starting a program (SUBMIT)

• Scheduling a program as a background job (BTCSUBMIT)

• Variant maintenance (VARIANT)

The object S_PROGNAM is used to supplement the start authorization check for programs. Authorizations for this object are checked exclusively with method CL_SABE=>AUTH_CHECK_PROGNAM() in the context of scenarios for switchable authorizations (maintenance transaction SACF). The check does not take place with each submit command, but only if it is called explicitly. If the associated scenario is activated, all programs are checked in addition to the existing authorization checks (for example, with authorization groups).