SAP Password Policies

 SAP, and by extension, SAP Basis, has robust password policies to ensure the security of user accounts.¹ These policies are highly configurable, allowing organizations to tailor them to their specific security requirements and compliance standards.²

There isn't a separate "SSAP Basis" as a distinct entity from "SAP Basis." SAP Basis refers to the administration of SAP systems, and password policies are a core component of this administration within the SAP NetWeaver (ABAP) application server.³

Here's a detailed breakdown of SAP password policies and how they are managed in SAP Basis:

I. How SAP Password Policies are Defined

SAP password policies are primarily controlled by profile parameters in the instance profile (maintained via transaction RZ10 or RZ11). In newer SAP NetWeaver versions (SAP_BASIS 7.03 and higher), SAP introduced Security Policies (SECPOL), which allow for more granular password policies to be applied to different user groups, overriding the global profile parameters.⁴

A. Global Password Policies (via Profile Parameters in RZ10/RZ11)

These parameters apply system-wide unless overridden by a security policy.⁵

1. Password Length and Composition:

• login/min_password_lng: Minimum password length.⁶ (Default is often 3, but a secure system should set it to 8, 10, or even 12+ characters).
• login/min_password_digits: Minimum number of digits (0-9) required.⁷
• login/min_password_letters: Minimum number of letters (A-Z, a-z) required.⁸
• login/min_password_lowercase: Minimum number of lowercase letters required (available in newer versions, after NW 6.40).⁹
• login/min_password_uppercase: Minimum number of uppercase letters required (available in newer versions, after NW 6.40).¹⁰
• login/min_password_specials: Minimum number of special characters required (e.g., ! @ # $ % & ( ) = ? \ ' * + ~ - _ . , ; : { [ ] } \ < > |).
• login/password_charset: Defines the allowed character set for passwords (e.g., restrictive ASCII, backward compatible, or any Unicode characters). Setting it to Unicode (value 2) allows for a wider range of characters, increasing complexity.¹¹

2. Password Lifetime and History:

• login/password_expiration_time: Defines the validity period of passwords in days.¹² After this period, dialog users are forced to change their password. A value of 0 means passwords never expire (generally not recommended for dialog users).
• login/password_history_size: Specifies the number of past passwords that the system stores and prevents users from reusing.¹³ (Commonly set to 5 or 10).
• login/password_change_waittime: Specifies the minimum number of days a user must wait before changing their password again.¹⁴ This prevents rapid password cycling to bypass history rules.
• login/password_max_idle_initial: Defines the maximum validity period for an unused initial password (set by an administrator). If the user doesn't log on and change it within this time, the initial password expires.¹⁵

3. Logon Attempt Restrictions:

• login/fails_to_session_end: Number of incorrect password attempts before the current logon session is terminated.¹⁶
• login/fails_to_user_lock: Number of incorrect password attempts after which the user account is automatically locked.¹⁷
• login/failed_user_auto_unlock: Controls whether automatically locked users are unlocked at midnight (1 for auto-unlock, 0 for no auto-unlock, meaning an administrator must manually unlock).¹⁸ For high-security environments, 0 is preferred.

4. Prohibited Passwords:

• Table USR40: This table contains a list of impermissible passwords or patterns (e.g., PASS, SAP*, or common dictionary words, company names, etc.). Administrators can maintain this table via SM30. Wildcard characters (* for a sequence, ? for a single character) can be used.¹⁹

5. Other Important Rules/Parameters:

• login/no_automatic_user_sapstar: If set to 1 (recommended for production), the emergency user SAP* can only log on if its user master record exists and is not locked. This prevents a "backdoor" scenario where SAP* can log in if its record is deleted.
• Password Case Sensitivity: As of NetWeaver 7.0, SAP distinguishes between upper and lower case in passwords, increasing complexity. Before that, passwords were often case-insensitive.
• Restrictions on First Characters: Certain characters (e.g., ! or ?) or patterns (first three characters cannot be the same) might be restricted as first characters in a password.
• Difference from Old Password: login/min_password_diff specifies the minimum number of characters that must be different between the new password and the old password.²⁰

B. Security Policies (SECPOL - Transaction SECPOL)

Introduced in SAP NetWeaver 7.03 (SAP_BASIS 7.03), security policies allow you to define different password policies (and other logon/user attributes) for specific sets of users or user groups, overriding the global profile parameters.²¹

• Granularity: You can define a security policy for, say, "BASIS_ADMINS" requiring a 15-character password, 2 special characters, and 3 digits, while "END_USERS" might have a less stringent 10-character policy.
• Assignment: Security policies are assigned to users in their user master record (SU01 -> Logon Data tab).²²
• Attributes: SECPOL allows you to configure attributes like:
  • Password Rules (length, complexity, history, expiration)²³
  • Locking behavior
  • Validity period for unused passwords
  • Login restrictions (e.g., disallowing access during specific system maintenance times using SERVER_LOGON_PRIVILEGE).²⁴
• Hierarchy: Security policies take precedence over profile parameters for the users they are assigned to.²⁵ If a user is not assigned a security policy, the global profile parameters apply.

II. How to Implement and Manage Password Policies in SAP Basis

1. Define Requirements:

   • Collaborate with your organization's security team, compliance officers, and auditors to define robust password policies that meet corporate standards (e.g., NIST, ISO 27001).
   • Consider different user types (dialog vs. system/communication) and their specific needs. System/communication users often have "password never expires" as they are used for automated processes.

2. Configure Profile Parameters (RZ10):

   • Access RZ10 (Edit Profiles).²⁶
   • Select the instance profile (e.g., DEFAULT.PFL, <SID>_DVEBMGS<XX>_<HOSTNAME>).
   • Navigate to "Extended Maintenance" to view and edit parameters.²⁷
   • Modify the login/* parameters as per your defined policy.
   • Important: Changes to most login/* parameters in RZ10 require a restart of the SAP application server instance(s) to take effect.²⁸ Some parameters can be changed dynamically via RZ11, but the persistent change is in RZ10.

3. Implement Security Policies (SECPOL):

   • If granular control is needed, use SECPOL to create specific security policies.²⁹
   • Define the attributes for each policy (e.g., password length, complexity, expiration).³⁰
   • Assign these security policies to relevant users or user groups in SU01 or via mass maintenance tools.³¹

4. Maintain Prohibited Passwords (SM30 for USR40):

   • Add common, easily guessable passwords, company names, or other sensitive terms to table USR40 to prevent users from using them.³²

5. Educate Users:

   • Communicate the password policy clearly to all users. Provide guidelines for creating strong, memorable passwords.

6. Monitor and Audit:

   • Security Audit Log (SM20): Configure and regularly review SM20 to track failed logon attempts, user master record changes (including password resets), and adherence to password policies.³³
   • SUIM (User Information System): Use SUIM reports to analyze user master data, including last password change dates, password expiration status, and users assigned to specific security policies.³⁴
   • GRC (Governance, Risk, and Compliance): SAP GRC Access Control provides advanced capabilities for continuous compliance monitoring, SoD analysis, and reporting on password policy adherence.³⁵

Key Considerations

• Balance Security and Usability: While strong passwords are vital, overly complex or frequently expiring passwords can lead to users writing them down or resorting to easily guessable patterns, ironically reducing security.³⁶
• System/Communication Users: For non-interactive user types (System, Communication), "Password never expires" is often acceptable, as they are used for automated processes and typically don't have interactive logon capabilities. However, their passwords should still be very strong and managed securely.
• Emergency Users (SAP*, DDIC): These users have default passwords upon installation. It is critical to change these immediately to strong, complex passwords and ideally keep them locked in production systems, only unlocking them for planned maintenance or emergencies.
• Multi-Factor Authentication (MFA): For even stronger security, integrate MFA with your SAP system. This adds an extra layer of protection beyond just passwords.

By carefully configuring and enforcing these password policies, SAP Basis administrators play a crucial role in maintaining the overall security posture of the SAP landscape.