Chapter 7. Designing a secure directory designing-rhds How Red Hat Directory Server secures the data affects all design areas. Any security design needs to protect the data in the directory and meet the security and privacy needs of both users and applications. Learn how to analyze the security needs and how to design the directory to meet these needs. 7.1. About security threats The directory may be at risk of potential security threats. Understanding the most common threats helps to outline the overall security design. Threats to directory security fall into three main categories: Unauthorized access Unauthorized tampering Denial of service 7.1.1. Unauthorized access Protecting the directory from unauthorized access may seem straightforward, however implementing a secure solution may be more complex than it first appears. The directory information delivery path has a number of potential access points where an unauthorized client may gain access to data. The following scenarios describe just a few examples of how an unauthorized client might access the directory data: An unauthorized client can use another client credentials to access the data. This is particularly likely when the directory uses unprotected passwords. An unauthorized client can also eavesdrop on the information exchanged between a legitimate client and Directory Server. Unauthorized access can occur from inside the company or, if the company is connected to an extranet or to the Internet, from outside the company. The authentication methods, password policies, and access control mechanisms provided by the Directory Server offer efficient ways of preventing unauthorized access. Additional resources Selecting appropriate authentication methods Designing a password policy Designing access control 7.1.2. Unauthorized tampering If intruders gain access to the directory or intercept communications between Directory Server and a client application, they have the potential to modify or tamper with the directory data. The directory service is useless if clients do not trust the data or if the directory itself can not trust the modifications and queries it receives from clients. For example, if the directory can not detect tampering, an attacker can change a client request to the server, or not forward it, and change the server response to the client. TLS and similar technologies can solve this problem by signing information at either end of the connection. Additional resources For more information about using TLS with Directory Server, see Securing server connections 7.1.3. Denial of service In a denial of service attack, the attacker goal is to prevent the directory from providing service to its clients. For example, an attacker might use all of the system resources, therefore preventing anyone else from using these resources. Directory Server can prevent denial of service attacks by setting limits on the resources allocated to a particular bind DN. For more information about setting resource limits based on the user bind DN, see the User management and authentication guide. 7.2. Analyzing security needs Analyze the environment and users to identify specific security needs. The site survey in the chapter Designing the secure directory clarifies some basic decisions about who can read and write the individual pieces of data in the directory. This information forms the basis of the security design. How the directory service is used to support the business defines how security is implemented. A directory that serves an intranet does not require the same security measures as a directory that supports an extranet or e-commerce applications that are open to the Internet. If the directory only serves an intranet, consider what level of access is needed for information: How to provide users and applications with access to the information they need to perform their jobs. How to protect sensitive data regarding employees or the business from general access. If the directory serves an extranet or supports e-commerce applications over the Internet, consider the following additional points: How to offer customers a guarantee of privacy. How to guarantee information integrity. 7.2.1. Determining access rights The data analysis identifies what information users, groups, partners, customers, and applications need to access the directory service. Access rights can be granted in one of two ways: Grant all categories of users as many rights as possible while still protecting sensitive data. An open method requires accurately determining what data is sensitive or critical to the business. Grant each category of users the minimum access they require to do their jobs. A restrictive method requires detailed understanding of the information needs of each category of user inside, and possibly outside, of the organization. Regardless of the method used to determine access rights, create a simple table that lists the categories of users in the organization and the access rights granted to each. Consider creating a table that lists the sensitive data held in the directory and, for each piece of data, the steps taken to protect it. Additional resources For information about checking the identity of users, see section Selecting appropriate authentication methods . For information about restricting access to directory information, see section Designing access control . 7.2.2. Ensuring data privacy and integrity When using the directory to support exchanges with business partners over an extranet or to support e-commerce applications with customers on the Internet, ensure the privacy and the integrity of the exchanged data. Use the following ways to ensure data privacy and integrity: Encrypt data transfers. Use certificates to sign data transfers. Additional resources For information about encryption methods Directory Server provides, see section Password Storage Schemes For information about signing data, see section Securing Server Connections . For information about encrypting sensitive information in the Directory Server database, see section Encrypting the database . 7.2.3. Conducting regular audits As an extra security measure, conduct regular audits to verify the efficiency of the overall security policy by examining the log files and the information that SNMP agents record. Additional resources For more information about monitoring Directory Server, see Monitoring server and database activity For more information about log files, see Log file reference 7.2.4. Example security needs analysis The examples show how the imaginary ISP company example.com analyzes its security needs. The example.com offers web hosting and Internet access. Part of example.com activity is to host the directories of client companies. It also provides Internet access to a number of individual subscribers. Therefore, example.com has three main categories of information in its directory: The example.com internal information Information belonging to corporate customers Information pertaining to individual subscribers The example.com needs the following access controls: Provide access to the directory administrators of hosted companies, such as example_a and example_b , to their own directory information. Implement access control policies for hosted companies directory information. Implement a standard access control policy for all individual clients who use example.com for Internet access from their homes. Deny access to example.com corporate directory to all outsiders. Grant read access to example.com directory of subscribers to the world. 7.3. Overview of security methods Directory Server offers several methods to design an overall security policy that is adapted to specific needs. The security policy should be strong enough to prevent unauthorized users to modify or retrieve sensitive information, but also simple enough to administer easily. A complex security policy can lead to mistakes that either prevent people from accessing information that they need to access or, worse, allow people to modify or retrieve directory information that they should not be allowed to access. Table 7.1. Available security methods in Directory Server Security method Description Authentication Verifies the identity of the other party. For example, a client gives a password to Directory Server during an LDAP bind operation. Password policies Defines the criteria that a password must satisfy to consider this password valid. For example, age, length, and syntax. Encryption Protects the privacy of information. When data is encrypted, only the recipient can understand the data. Access control Tailors the access rights granted to different directory users and provides a way to specify required credentials or bind attributes. Account deactivation Disables a user account, group of accounts, or an entire domain so that Directory Server automatically rejects all authentication attempts. Secure connections Maintains the integrity of information by encrypting connections with TLS, StartTLS, or SASL. If information is encrypted during transmission, the recipient can determine that it was not modified during transit. Secure connections can be required by setting a minimum security strength factor. Auditing Determines if the security of the directory has been compromised. One simple auditing method is reviewing the log files the directory maintains. SELinux Uses security policies on the Red Hat Directory Server machine to restrict and control access to Directory Server files and processes. Combine any number of these tools for maintaining security in the security design, and incorporate other features of the directory service, such as replication and data distribution, to support the security design. 7.4. Selecting appropriate authentication methods A basic decision regarding the security policy is how users access the directory. Are anonymous users allowed to access the directory, or is every user required to log into the directory with a username and password (authenticate)? Learn about authentication methods that Directory Server provides. The directory uses the same authentication mechanism for all users, whether they are people or LDAP-aware applications. 7.4.1. Anonymous and unauthenticated access Anonymous access provides the easiest form of access to the directory. With anonymous access, anyone who connects to the directory can access the data. When you configure anonymous access, you cannot track who performs what kinds of searches, only that someone performs searches. You may attempt to block a specific user or group of users from accessing some kinds of directory data, but, if anonymous access is allowed to that data, those users can still access the data simply by binding to the directory anonymously. You can limit anonymous access. Usually, directory administrators only allow anonymous access for read, search, and compare privileges, not for write, add, delete, or self-write privileges. Often, administrators limit access to a subset of attributes that contain general information, such as names, telephone numbers, and email addresses. You should never allow anonymous access to more sensitive data, such as government identification numbers, for example, Social Security Numbers in the US, home telephone numbers and addresses, and salary information. You can disable anonymous access entirely if you need to tighten rules on who accesses the directory data. An unauthenticated bind is when a user attempts to bind with a user name but without a user password attribute. For example: Directory Server grants anonymous access if the user does not attempt to provide a password. An unauthenticated bind does not require that the bind DN be an existing entry. As with anonymous binds, you can disable unauthenticated binds to increase security by limiting access to the database. In addition, you can disable unauthenticated binds to prevent silent bind failures for clients. Some applications may believe that it authenticated successfully to the directory because it received a bind success message when, in reality, it failed to pass a password and simply connected with an unauthenticated bind. 7.4.2. Simple binds and secure binds If anonymous access is not allowed, users must authenticate to the directory before they can access the directory contents. With simple password authentication, a client authenticates to the server by sending a reusable password. For example, a client authenticates to the directory using a bind operation, which provides a distinguished name and a set of credentials. The server locates the entry in the directory that corresponds to the client DN and checks whether the password given by the client matches the value stored with the entry. If it does, the server authenticates the client. If it does not, the authentication operation fails, and the client receives an error message. The bind DN often corresponds to the entry of a person. However, some directory administrators prefer to bind as an organizational entry rather than as a person. The directory requires the entry used to bind to have an object class that allows the userPassword attribute. This ensures that the directory recognizes the bind DN and password. Most LDAP clients hide the bind DN from the user because users may find the long strings of DN characters hard to remember. When a client attempts to hide the bind DN from the user, it uses the following bind algorithm: The user enters a unique identifier, such as a user ID. For example, fchen . The LDAP client application searches the directory for that identifier and returns the associated distinguished name. For example, uid=fchen,ou=people,dc=example,dc=com . The LDAP client application binds to the directory using the retrieved distinguished name and the password the user supplies. Simple password authentication offers an easy way to authenticate users, however it requires extra security methods. Consider restricting its use to the organization intranet. To use with connections between business partners over an extranet or for transmissions with customers on the Internet, it may be best to require a secure (encrypted) connection. Note The drawback of simple password authentication is that the password is sent in plain text. If an unauthorized user is listening, this can compromise the security of the directory because that person can impersonate an authorized user. The nsslapd-require-secure-binds configuration attribute requires simple password authentication to occur over a secure connection, using TLS or Start TLS. This effectively encrypts the plaintext password so it cannot be sniffed by a malicious actor. Use the nsslapd-require-secure-binds configuration attribute to turn on a secure connection by using TLS or the Start TLS. The SASL authentication or certificate-based authentication are also possible. When Directory Server and a client application establish a secure connection with each other, the client performs a simple bind with an extra level of protection by not transmitting the password in plaintext. Additional resources Securing server connection The nsslapd-require-secure-binds configuration attribute description . 7.4.3. Certificate-based authentication An alternative form of directory authentication involves using digital certificates to bind to the directory. The directory prompts users for a password when they first access it. However, rather than matching a password stored in the directory, the password opens the user certificate database. If the user supplies the correct password, the directory client application obtains authentication information from the certificate database. The client application and the directory then use this information to identify the user by mapping the user certificate to a directory DN. The directory allows or denies access based on the directory DN identified during this authentication process. Additional resources Securing Red Hat Directory Server 7.4.4. Proxy authentication Proxy authentication is a special form of authentication because the user requesting access to the directory does not bind with its own DN but with a proxy DN . The proxy DN is an entity that has appropriate permissions to perform the operation the user requests. When a person or an application receives proxy permissions, they can specify any DN as a proxy DN, with the exception of the Directory Manager DN. One of the main advantages of proxy permissions is that an LDAP application can use a single thread with a single bind to service multiple users making requests against Directory Server. Instead of having to bind and authenticate for each user, the client application binds to the Directory Server using a proxy DN. The proxy DN is specified in the LDAP operation the client application submits. For example: With this command, the manager entry cn=Directory Manager receives permissions of a user cn=joe to apply the modifications to the mods.ldif file. The manager does not need to provide the user password to make this change. Note The proxy mechanism is very powerful and you must use it carefully. Proxy rights are granted within the scope of the access control list (ACL), and when you grant proxy permissions to a user, this user can proxy for any user under the target. You can not restrict the proxy permissions to only certain users. For example, if an entry has proxy permissions to the dc=example,dc=com tree, this entry can do anything. Therefore, ensure that you set the proxy access control instruction (ACI) at the lowest possible level of the directory. Additional resources Managing access control 7.4.5. Pass-through authentication (PTA) Pass-through authentication (PTA) is when Directory Server forwards any authentication request from one server to another server. For example, when Directory Server stores all configuration information for an instance in another directory instance, Directory Server uses pass-through authentication for the User Directory Server to connect to the Configuration Directory Server. PTA plug-in handles Directory Server-to-Directory Server pass-through authentication. Many systems already have authentication mechanisms for Unix and Linux users, such as Pluggable Authentication Modules (PAM). You can configure a PAM module to tell Directory Server to use an existing authentication store for LDAP clients. Directory Server interacts with the PAM service to authenticate LDAP clients by using PAM Pass-through Authentication plug-in. With PAM pass-through authentication, when a user attempts to bind to Directory Server, Directory Server forwards the credentials to the PAM service. If the credentials match the information in the PAM service, then the user can successfully bind to the Directory Server, with all of the Directory Server access control restrictions and account settings. Note You can configure Directory Server to use PAM, however you can not configure PAM to use Directory Server for authentication. You can configure the PAM service by using the System Security Services Daemon (SSSD). Simply point the PAM Pass-through Authentication plug-in to the PAM file that SSSD uses, such as /etc/pam.d/system-auth by default. SSSD can use a variety of different identity providers, including Active Directory, Red Hat Directory Server, or other directories like OpenLDAP, or local system settings. 7.4.6. Passwordless authentication An authentication attempt first evaluates if the user account can authenticate. The account must fall under the following criteria: It must be active. It must not be locked. It must have a valid password according to any applicable password policy. Sometimes a client application needs to perform the authentication of a user account when the user should not or cannot bind to Directory Server for real. For example, a system may be using PAM to manage system accounts, and you configured PAM to use the LDAP directory as its identity store. However, the system uses passwordless credentials, such as SSH keys or RSA tokens, and those credentials cannot be passed to authenticate to the Directory Server. Red Hat Directory Server supports the Account Usability Extension Control extension for LDAP searches. This extension returns an extra line for each returned entry that gives the account status and some information about the password policy for that account. A client or application can then use that status to evaluate authentication attempts made outside Directory Server for that user account. Basically, this control signals whether a user should be allowed to authenticate without having to perform an authentication operation. In addition, you can use this extension with system-level services like PAM to allow passwordless logins which still use Directory Server to store identities and even control account status. Note By default, only the Directory Manager can use the Account Usability Extension Control. To allow other users to use the control, set the appropriate ACI on the supported control entry, oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config . Additional resources Checking account availability for passwordless access 7.5. Designing an account lockout policy An account lockout policy can protect both directory data and user passwords by preventing unauthorized or compromised access to the directory. After Directory Server locks, or deactivates , an account, that user cannot bind to the directory, and any authentication operation fails. Use the nsAccountLock operational attribute to implement the account deactivation. When an entry contains the nsAccountLock attribute with a value of true , the server rejects a bind attempt by that account. Directory Server can define an account lockout policy based on specific, automatic criteria: Directory Server can associate an account lockout policy with the password policy. When a user fails to log in with the proper credentials after a specified number of times, Directory Server locks the account until an administrator manually unlocks it. Such a policy protects against malicious actors who try to break into the directory by repeatedly trying to guess a user password. Directory Server can lock an account after a certain amount of time passed. You can use this policy to control access for temporary users, such as interns, students, or seasonal workers, who have time-limited access based on the time the account was created. Alternatively, you can create an account policy that inactivates user accounts if the account has been inactive for a certain amount of time since the last login time. Use the Account Policy Plug-in to implement a time-based account lockout policy and set global settings for the directory. You can create multiple account policy subentries for different expiration times and types and then apply these policies to entries through classes of service. Additional resources Designing a password policy 7.6. Designing a password policy A password policy is a set of rules that manage how passwords are used in a given system. The Directory Server password policy specifies the criteria that a password must satisfy to be considered valid, like the age, length, and whether users can reuse passwords. 7.6.1. How password policy works Directory Server supports fine-grained password policies, which means Directory Server defines a password policy at any point in the directory tree. Directory Server defines password policies at the following levels: The entire directory Such a policy is known as the global password policy. When you configure and enable this policy, Directory Server applies it to all users within the directory except for the Directory Manager entry and those user entries that have local password policies enabled. This policy type can define a common, single password policy for all directory users. A particular subtree of the directory Such a policy is known as the subtree level or local password policy. When you configure and enable this policy, Directory Server applies it to all users under the specified subtree. This policy type is good in a hosting environment to support different password policies for each hosted company rather than enforcing a single policy for all the hosted companies. A particular user of the directory Such a policy is known as the user level or local password policy. When you configure and enable this policy, Directory Server applies it to the specified user only. This policy type can define different password policies for different directory users. For example, specify that some users change their passwords daily, some users change it monthly, and all other users change it every six months. By default, Directory Server includes entries and attributes that are relevant to the global password policy, meaning the same policy is applied to all users. To set up a password policy for a subtree or user, add additional entries at the subtree or user level and enable the nsslapd-pwpolicy-local attribute of the cn=config entry. This attribute acts as a switch turning fine-grained password policy on and off. You can change password policies by using the command line or the web console. In the command line, the dsconf pwpolicy command changes global policies and the dsconf localpwp command changes local policies. You can find the procedures for setting password policies in the Configuring password policies section. Password policy checking process The password policy entries that you add to the directory determine the type (global or local) of the password policy the Directory Server should enforce. When a user attempts to bind to the directory, Directory Server determines whether a local policy has been defined and enabled for the user entry. Directory Server checks policy settings in the following order: Directory Server determines whether the fine-grained password policy is enabled. The server checks the value ( on or off ) of the nsslapd-pwpolicy-local attribute in the cn=config entry. If the value is set to off , the server ignores the policies defined at the subtree and user levels and enforces the global password policy. Directory Server determines whether a local policy is defined for a subtree or user. The server checks for the pwdPolicysubentry attribute in the corresponding user entry: If the attribute is present, the server enforces the local password policy configured for the user. If the entry has the attribute but the value is empty or invalid (for example, points to a non-existent entry), the server logs an error message. If the pwdPolicysubentry attribute is not found in the user entry, the server checks the parent entry, grandparent entry, and other upper-level entries until the top is reached. If the pwdPolicysubentry attribute is not found in any upper-level entries, the server applies a global policy. The server compares the user-supplied password with the value specified in the user directory entry to make sure they match. The server also uses the rules that the password policy defines to ensure that the password is valid before allowing the user to bind to the directory. In addition to bind requests, password policy checking also occurs during add and modify operations if the userPassword attribute is present in the request. Modifying the value of userPassword checks two password policy settings: The password minimum age policy is activated. If the minimum age requirement is not satisfied, the server returns the constraintViolation error. The password update operation fails. The password history policy is activated. If the new value of the userPassword attribute is in the password history, or if it is the same as the current password, the server returns a constraintViolation error. The password update operation fails. Both adding and modifying the value of userPassword checks password policies set for the password syntax: The password minimum length policy is activated. If the new value of the userPassword attribute is less than the required minimum length, the server returns the constraintViolation error. The password update operation fails. The password syntax checking policy is activated. If the new value of userPassword is the same as another attribute of the entry, the server returns a constraintViolation error. The password update operation fails. 7.6.2. Password policy attributes Learn about the attributes that you can use to create a password policy for the server. Directory Server stores password policy attributes in the cn=config entry, and you can change these settings by using dsconf utility. Maximum number of failures This setting enables password-based account lockouts in the password policy. If a user attempts to log in a certain number of times and fails, Directory Server locks that account until an administrator unlocks it or, optionally, a certain amount of time passes. Use passwordMaxFailure configuration parameter to set the maximum number of failures. Directory Server has two ways to count login attempts and lock an account when login attempts reach the limit: Directory Server locks the account when the number hits ( n ) Directory Server locks the account only when the count exceeds ( n+1 ). For example, if the failure limit is three attempts, the account can be locked at the third failed attempt ( n ) or at the fourth failed attempt ( n+1 ). The n+1 behavior is the historical behavior for LDAP servers, so it is considered as legacy behavior. Newer LDAP clients expect a stricter hard limit. By default, Directory Server uses the strict limit (n), but you can change the legacy behavior in the passwordLegacyPolicy configuration parameter. Password change after reset The Directory Server password policy can specify whether users must change their passwords after the first login or after the administrator has reset the password. The default passwords that the administrator sets typically follow a company convention, such as the user initials, user ID, or company name. If this convention is discovered, it is usually the first value that a malicious actor uses in an attempt to break into the system. Therefore, it is recommended to require users to change their password after an administrator resets these passwords. If you configure this setting for the password policy, users are required to change their password even if user-defined passwords are disabled. If the password policy does not require or does not allow the password change by a user, administrator-assigned passwords should not follow any obvious convention and should be difficult to discover. The default configuration does not require that users change their password after it has been reset. User-defined passwords You can set a password policy to allow or not allow users to change their own passwords. A good password is the key to a strong password policy. Good passwords should not use trivial words, such as dictionary words, names of pets or children, birthdays, user IDs, or any other information about the user that can be easily discovered (or stored in the directory itself). A good password should contain a combination of letters, numbers, and special characters. For the sake of convenience, however, users often use passwords that are easy to remember. Consequently, some enterprises choose to set passwords for users that meet the criteria of a strong password and do not allow users to change their passwords. Setting passwords by administrators for users has the following disadvantages: It requires a substantial amount of administrator time. Because administrator-specified passwords are typically more difficult to remember, users are more likely to write their password down, increasing the risk of discovery. By default, user-defined passwords are allowed. Password expiration The password policy can allow users to use the same passwords indefinitely or specify that passwords expire after a given time. In general, the longer a password is in use, the more likely it is to be discovered. However, if passwords expire too often, users may have trouble remembering them and resort to writing their passwords down. A common policy is to have passwords expire every 30 to 90 days. The server remembers the password expiration specification even if password expiration is disabled. If the password expiration is re-enabled, passwords are valid only for the duration set before it was last disabled. For example, if you configure passwords to expire every 90 days, and then you disable and re-enable the password expiration, the default password expiration duration stays 90 days. By default, user passwords never expire. Expiration warning If you set a password expiration period, it is a good idea to send users a warning before their passwords expire. Directory Server displays the warning when a user binds to the server. If password expiration is enabled, by default, Directory Server sends a warning to a user, by using an LDAP message, one day before the user password expires. The user client application should support this feature. The valid range for a password expiration warning is from one to 24,855 days. Note The password never expires until Directory Server has sent the expiration warning. Grace login limit A grace period for expired passwords means that users can still log in to the system, even if their passwords have expired. To allow some users to log in using an expired password, specify the number of grace login attempts that are allowed to a user after the password has expired. By default, Directory Server does not permit grace logins. Password syntax checking Password syntax checking enforces rules for password strings so that any password has to meet or exceed certain criteria. All password syntax checks can be applied globally, per a subtree, or per a user. The passwordCheckSyntax attribute manages the password syntax checking. The default password syntax requires a minimum password length of eight characters and that no trivial words are used in the password. A trivial word is any value stored in the uid , cn , sn , givenName , ou , or mailattributes of the user entry. Additionally, you can use other forms of password syntax enforcement, providing different optional categories for the password syntax: Minimum number of required characters in the password ( passwordMinLength ). Minimum number of digit characters, meaning numbers between zero and nine ( passwordMinDigits ). Minimum number of ASCII alphabetic characters, both upper- and lower-case ( passwordMinAlphas ). Minimum number of uppercase ASCII alphabetic characters ( passwordMinUppers ). Minimum number of lowercase ASCII alphabetic characters ( passwordMinLowers ). Minimum number of special ASCII characters, such as !@#USD ( passwordMinSpecials ). Minimum number of 8-bit characters (passwordMin8bit). Maximum number of times that the same character can be immediately repeated, such as aaabbb ( passwordMaxRepeats ). Minimum number of character categories a password requires; a category can be upper-case or lower-case letters, special characters, digits, or 8-bit characters ( passwordMinCategories ). Directory Server checks the password against the CrackLib dictionary ( passwordDictCheck ). Directory Server checks if the password contains a palindrome ( passwordPalindrome ). Directory Server prevents setting a password that has more consecutive characters from the same category ( passwordMaxClassChars ). Directory Server prevents setting a password that contains certain strings ( passwordBadWords ). Directory Server prevents setting a password that contains strings set in administrator-defined attributes ( passwordUserAttributes ). The more categories of syntax required, the stronger the password. By default, password syntax checking is disabled. Password length The password policy can require a minimum length for user passwords. In general, shorter passwords are easier to crack. A recommended minimal length for passwords is eight characters. This is long enough to be difficult to crack but short enough that users can remember the password without writing it down. The valid range of values for this attribute is from two to 512 characters. By default, the server does not have a minimum password length. Password minimum age The password policy can prevent users from changing their passwords for a specified time. When you set the passwordMinAge attribute in conjunction with the passwordHistory attribute, users cannot reuse old passwords. For example, if the password minimum age ( passwordMinAge ) attribute is two days, users cannot repeatedly change their passwords during a single session. This prevents them from cycling through the password history so that they can reuse an old password. The valid range of values for the passwordMinAge attribute is from zero to 24 855 days. A value of zero ( 0 ) indicates that the user can change the password immediately. Password history The Directory Server can store from two to 24 passwords in the password history. If a password is in the history, a user cannot reset his password to that old password. This prevents users from reusing a couple of passwords that are easy to remember. Alternatively, you can disable the password history, thus allowing users to reuse passwords. The passwords remain in history even if the password history is off. If the password history is turned back on, users cannot reuse the passwords that were in the history before you disabled the password history. The server does not maintain a password history by default. Password storage schemes The password storage scheme specifies the type of encryption used to store Directory Server passwords within the directory. The Directory Server supports several different password storage schemes: Password-Based Key Derivation Function 2 (PBKDF2_SHA256, PBKDF2-SHA1, PBKDF2-SHA256, PBKDF2-SHA512) This is the most secure password storage scheme. The default storage scheme is PBKDF2-SHA512. Salted Secure Hash Algorithm (SSHA, SSHA-256, SSHA-384, and SSHA-512) The recommended SSHA scheme is SSHA-256 or stronger. CLEAR This means no encryption and is the only option that can be used with SASL Digest-MD5, so using SASL requires the CLEAR password storage scheme. Although passwords a directory stores can be protected through the use of access control information (ACI) instructions, it is still not a good idea to store plain text passwords in the directory. Secure Hash Algorithm (SHA, SHA-256, SHA-384, and SHA-512) This is less secure than SSHA. UNIX CRYPT This algorithm provides compatibility with UNIX passwords. MD5 This storage scheme is less secure than SSHA, but it is included for legacy applications that require MD5. Salted MD5 This storage scheme is more secure than plain MD5 hash, but still less secure than SSHA. This storage scheme is not included for use with new passwords but to help with migrating user accounts from directories that support salted MD5. Password last change time The passwordTrackUpdateTime configuration attribute tells the server to record a timestamp for the last time Directory Server updated a password for an entry. Directory Server stores the password change time as an operational attribute pwdUpdateTime in the user entry, which is separate from the modifyTimestamp or lastModified operational attributes. By default, the server does not store the password last change time. Additional resources Configuration attributes under cn=config entry 7.6.3. Designing a password policy in a replicated environment Directory Server enforces password and account lockout policies in a replicated environment as follows: Password policies are enforced on the data supplier. Account lockout is enforced on all servers in the replication setup. Directory Server replicates password policy information in the directory, such as password age, the account lockout counter, and the expiration warning counter. However, Directory Server does not replicate the configuration information, such as the password syntax and the history of password modifications. Directory Server stores this information locally. When configuring a password policy in a replicated environment, consider the following points: All replicas issue warnings of an impending password expiration. Directory Server keeps this information locally on each server, so if a user binds to several replicas in turn, the user receives the same warning several times. In addition, if the user changes the password, it may take time for replicas to receive this information. If a user changes a password and then immediately rebinds, the bind may fail until the replica registers the changes. The same bind behavior should occur on all servers, including suppliers and replicas. Always create the same password policy configuration information on each server. Account lockout counters may not work as expected in a multi-supplier environment. 7.7. Designing access control After deciding on the authentication schemes, decide how to use those schemes to protect the information contained in the directory. Access control can specify that certain clients have access to particular information, while other clients do not. Use one or more access control lists (ACLs) to define access control. The directory ACLs consist of a series of one or more access control information (ACI) statements that either allow or deny permissions, such as read, write, search, and compare, to specified entries and their attributes. Using the ACL, you can set permissions at any level of the directory tree: The entire directory A particular subtree of the directory Specific entries in the directory A specific set of entry attributes Any entry that matches a given LDAP search filter In addition, you can set permissions for a specific user, for all users belonging to a specific group, or for all users of the directory. You can define access for a network location, such as an IP address (IPv4 or IPv6) or a DNS name. 7.7.1. About the ACI format When designing the security policy, you need to understand how ACIs are represented in the directory, and what permissions you can set. Directory ACIs use the following general form: The ACI variables have the following description: Target Specifies the entry, usually a subtree, that the ACI targets, the attribute it targets, or both. The target identifies the directory element that the ACI applies to. An ACI can target only one entry, but it can target multiple attributes. In addition, the target can contain an LDAP search filter. You can set permissions for widely scattered entries that contain common attribute values. Permission Identifies the actual permission the ACI sets. The permission variable states that the ACI allows or denies a specific type of directory access, such as read or search, to the specified target. Bind rule Identifies the bind DN or network location to which the permission applies. The bind rule may also specify an LDAP filter, and if that filter is evaluated to be true for the binding client application, then the ACI applies to the client application. Therefore, for the directory object target, ACIs allow or deny permission if a bind rule is true. Permission and a bind rule are set as a pair, and every target can have multiple permission-bind rule pairs. You can set multiple access controls for any given target effectively. For example: Additional resources For a complete description of the ACI format, see Managing access control 7.7.1.1. Targets An ACI can target a directory entry and attributes on the entry. Targeting a directory entry includes that entry and all of its child entries in the scope of the permission. If you do not explicitly define a target entry for the ACI, then the ACI targets to the directory entry that contains the ACI statement. An ACI can target only one entry or only those entries that match a single LDAP search filter. Targeting attributes applies the permission to only a subset of attribute values. When you target a set of attributes, specify which attributes an ACI targets or which attributes an ACI does not target explicitly. Excluding attributes in the target sets permission for all but a few attributes an object class structure allows. Additional resources Targeting a directory entry Targeting attributes 7.7.1.2. Permissions Permissions can allow or deny access. Avoid denying permissions, for more details, see Allowing or denying access Permissions can be any operation performed on the directory service: Permission Description Read Indicates if a user can read directory data. Write Indicates if a user can change or create a directory. In addition, this permission allows the user to delete directory data but not the entry itself. However, to delete an entire entry, the user must have the delete permissions. Search Indicates if a user can search the directory data. This differs from read permission in that read permission allows a user to view the directory data if it is returned as part of a search operation. For example, if you allow searching for common names ( cn ) and reading a person room number, then Directory Server can return the room number as part of the common name search. However, a user cannot use the room number as the subject of a search. Use this combination to prevent people from searching who sits in a particular room. Compare Indicates if a user can compare the data. The compare permission implies the ability to search, however, Directory Server does not return actual directory information as a result of the search. Instead, Directory Server returns a simple Boolean value that indicates whether the compared values match. Use compare operation to match userPassword attribute values during directory authentication. Self-write Use the self-write permission only for group management. With this permission, a user can add to or delete themselves from a group. Add Indicates if a user can create child entries under the targeted entry. Delete Indicates if a user can delete the targeted entry. Proxy Indicates that the user can use any other DN, except Directory Manager, to access the directory with the rights of this DN. 7.7.1.3. Bind rules The bind rule defines the bind DNs (users) to which an ACI applies. It can also specify bind attributes, such as time of day or IP address. In addition, bind rules easily define that the ACI applies only to a user own entry. Users can update their own entries without running the risk of a user updating another user entry. Bind rules indicate the following situations when an ACI applies: If the bind operation arrives from a specific IP address (IPv4 or IPv6) or DNS hostname. You can use it to force all directory updates to occur from a given machine or network domain. If a user binds anonymously. Setting permission for anonymous bind means that the permission applies to anyone who binds to the directory. For anyone who successfully binds to the directory. You can use it to allow general access while preventing anonymous access. If a user has bound as the immediate parent of the entry. If a user meets a specific LDAP search criteria. Directory Server provides the following keywords for bind rules: Parent If the bind DN is the immediate parent entry, then the bind rule is true. You can grant specific permissions that allow a directory entry to manage its immediate child entries. Self If the bind DN is the same as the entry requesting access, then the bind rule is true. You can grant specific permissions to allow individuals to update their own entries. All The bind rule is true for anyone who has successfully bound to the directory. Anyone The bind rule is true for everyone. Use this keyword to allow or deny anonymous access. 7.7.2. Setting permissions By default, Directory Server denies access of any kind to all users, with the exception of the Directory Manager. Consequently, you must set ACIs for users to be able to access the directory. 7.7.2.1. The precedence rule When a user attempts any type of access to a directory entry, Directory Server checks the access control set in the directory. To determine access, Directory Server applies the precedence rule . This rule states that when two conflicting permissions exist, the permission that denies access always takes precedence over the permission that grants access. For example, if Directory Server denies write permission at the directory root level, and that permission applies to everyone accessing the directory, then no user can write to the directory regardless of any other permissions that may allow write access. To allow a specific user to write permissions to the directory, you need to set the scope of the original deny-for-write so that it does not include that user. Then, you need to set an additional allow-for-write permission for the user. 7.7.2.2. Allowing or denying access You can allow or deny access to the directory tree, but be careful of explicitly denying the access. Because of the precedence rule, if Directory Server finds rules that deny access at a higher level of the directory, it denies access at lower levels regardless of any conflicting permissions that may grant access. Limit the scope of allow access rules to include only the smallest possible subset of users or client applications. For example, you can set permissions to allow users to write to any attribute on their directory entry, but then deny all users except members of the Directory Administrators group the privilege of writing to the uid attribute. Alternatively, write two access rules that allow write access in the following ways: Create one rule that allows write privileges to every attribute except the uid attribute. This rule should apply to everyone. Create one rule that allows write privileges to the uid attribute. This rule should apply only to members of the Directory Administrators group. Providing only allow privileges avoids the need to set an explicit deny privilege. 7.7.2.3. When to deny access It is rarely necessary to set an explicit deny privilege, however it is useful in the following cases: You have a large directory tree with a complex ACL spread across it. For security reasons, Directory Server may need to suddenly deny access to a particular user, group, or physical location. Rather than spending the time to carefully examine the existing ACL to understand how to restrict the allow permissions, temporarily set the explicit deny privilege until you have time to do the analysis. If the ACL becomes this complex, then the deny ACI only adds costs to the administrative overhead in the future. As soon as possible, rework the ACL to avoid the explicit deny privilege and then simplify the overall access control scheme. You set access control based on a day of the week or an hour of the day. For example, Directory Server can deny all writing activities from Sunday at 11:00 p.m. ( 2300 ) to Monday at 1:00 a.m. ( 0100 ). From an administrative point of view, it may be easier to manage an ACI that explicitly restricts time-based access of this type than to search through the directory for all the allow-for-write ACIs and restrict their scopes in this time frame. You restrict privileges when delegating directory administration authority to multiple people. To allow a person or group of people to manage some part of the directory tree, without allowing them to modify some aspect of the tree, use an explicit deny privilege. For example, to make sure that Mail Administrators do not allow write access to the common name ( cn ) attribute, set an ACI that explicitly denies write access to the common name attribute. 7.7.2.4. Where to place access control rules You can add access control rules to any entry in the directory. Often, administrators add access control rules to entries with the object classes domainComponent , country , organization , organizationalUnit , inetOrgPerson , or group . Organize rules into groups as much as possible in order to simplify ACL management. Rules apply to their target entry and to all of that entry children. Consequently, it is best to place access control rules on root points in the directory or on directory branch points, rather than scatter them across individual leaf entries, such as person. 7.7.2.5. Using filtered access control rules You can use LDAP search filters to set access to any directory entry that matches a defined set of criteria. For example, allow read access for any entry that contains an organizationalUnit attribute that is set to Marketing . Filtered access control rules allow predefined levels of access. For example, the directory contains home address and telephone number information. Some people want to publish this information, while others want to be unlisted. You can use the following way to configure access: Add an attribute to every user directory entry called publishHomeContactInfo . Set an access control rule that grants read access to the homePhone and homePostalAddress attributes only for entries whose publishHomeContactInfo attribute is set to true (enabled). Use an LDAP search filter to express the target for this rule. Allow the directory users to change the value of their own publishHomeContactInfo attribute to true or false. In this way, the directory user can decide whether this information is publicly available. Additional resources LDAP search filters 7.7.3. Viewing ACIs: Get effective rights Get effective rights (GER) is an extended ldapsearch command which returns the access control permissions set on each attribute within an entry. With this search, an LDAP client can determine what operations the server access control configuration allows a user to perform. The access control information is divided into two groups of access: entry rights and attribute rights. Entry rights are the rights, such as modify or delete, that are limited to that specific entry. Attribute rights are the access rights to every instance of that attribute throughout the directory. Such a detailed access control may be necessary in the following situations: You can use the GER commands to better organize access control instructions for the directory. It is often necessary to restrict what one group of users can view or edit compared to another group. For example, members of the QA Managers group may have the right to search and read attributes like manager and salary but only HR Group members have the right to modify or delete them. Checking effective rights for a user or group is one way to verify that an administrator sets the appropriate access controls. You can use the GER commands to see what attributes you can view or modify on your personal entry. For example, a user should have access to attributes such as homePostalAddress and cn , but may only have read access to manager and salary attributes. Additional resources Checking access rights on entries using Get Effective Rights search Common scenarios for a Get Effective Rights search 7.7.4. Using ACIs: Some hints and tricks The following tips can help to lower the administrative burden of managing the directory security model and improve the directory performance characteristics: Minimize the number of ACIs in the directory. Although the Directory Server can evaluate over 50,000 ACIs, it is difficult to manage a large number of ACI statements. A large number of ACIs makes it hard for human administrators to immediately determine the directory object available to particular clients. Directory Server minimizes the number of ACIs in the directory by using macros. Use the macro to represent a DN, or its part, in the ACI target or in the bind rule, or both. Balance allow and deny permissions. Although the default rule is to deny access to any user who does not have specifically granted access, it may be better to reduce the number of ACIs by using one ACI to allow access close to the root of the tree, and a small number of deny ACIs close to the leaf entries. This scenario avoids the use of multiple allow ACIs close to the leaf entries. Identify the smallest set of attributes in an ACI. When allowing or denying access to a subset of attributes, choose if the smallest list is the set of attributes that are allowed or the set of attributes that are denied. Then set the ACI so that it only requires managing the smallest list. For example, the person object class contains a large number of attributes. To allow a user to update only a few attributes, write the ACI that allows write access for only those attributes. However, to allow a user to update all attributes, except the few attributes, create the ACI that allows write access for everything except these few named attributes. Use LDAP search filters carefully. Search filters do not directly name the object for which you manage access. Consequently, their use can produce unexpected results. Especially, when the directory becomes more complex. Before using search filters in ACIs, run an ldapsearch operation using the same filter to make the result clear. Do not duplicate ACIs in differing parts of the directory tree. Guard against overlapping ACIs. For example, if there is an ACI at the directory root point that allows a group write access to the commonName and givenName attributes, and another ACI that allows the same group write access for only the commonName attribute, then consider updating the ACIs so that only one control grants the write access to the group. When the directory grows more complex, the risk of accidentally overlapping ACIs quickly increases. By avoiding ACI overlap, security management becomes easier by reducing the total number of ACIs contained in the directory. Name ACIs. While naming ACIs is optional, giving each ACI a short, meaningful name helps with managing the security model. Group ACIs as closely together as possible within the directory. Try to limit ACI location to the directory root point and to major directory branch points. Grouping ACIs helps to manage the total list of ACIs, as well as helping keep the total number of ACIs in the directory to a minimum. Avoid using double negatives, such as deny write if the bind DN is not equal to cn=Joe . Although this syntax is perfectly acceptable for the server, it is not human-readable. Additional resources Using macro access control instructions 7.7.5. Applying ACIs to the root DN (Directory Manager) Normally, access control rules do not apply to the Directory Manager user. The Directory Manager is defined in the dse.ldif file, not in the regular user database, and ACI targets do not include that user. The Directory Manager requires a high level of access in order to perform maintenance tasks and to respond to incidents. However, you can grant a certain level of access control to the Directory Manager to prevent unauthorized access or attacks from being performed as the root user. Use the RootDN Access Control plug-in to sets certain access control rules specific to the Directory Manager user: Time-based access controls, to allow or deny access on certain days and specific time ranges. IP address rules, to allow or deny access from defined IP addresses, subnets, and domains. Host access rules, to allow or deny access from specific hosts, domains, and subdomains. You can set only one access control rule for the Directory Manager. It is in the plug-in entry, and it applies to the entire directory. Important Ensure that the Directory Manager account has an appropriate level of access. This administrative user might need to perform maintenance operations in off-hours or to respond to failures. In this case, setting a too restrictive time or day rule can prevent the Directory Manager user from managing the directory effectively. Additional resources Setting access control on the Directory Manager account . 7.8. Encrypting the database Database stores information in plain text. Consequently, access control measures may not sufficiently protect some extremely sensitive information, such as government identification numbers or passwords. It may be possible to gain access to a server persistent storage files, either directly through the file system or by accessing discarded disk drives or archive media. With database encryption, individual attributes can be encrypted as they are stored in the database. When configured, every instance of a particular attribute, even index data, is encrypted and can only be accessed using a secure channel, such as TLS. Additional resources For information on using database encryption, see the Managing attribute encryption chapter. 7.9. Securing server connections After designing the authentication scheme for identified users and the access control scheme for protecting information in the directory, the step is to design a way to protect the integrity of the information as it passes between servers and client applications. For both server-to-client connections and server-to-server connections, the Directory Server supports a variety of secure connection types: Transport Layer Security (TLS) Directory Server can use LDAP over the TLS to provide secure communications over the network. The encryption method selected for a particular connection is the result of a negotiation between the client application and Directory Server. Start TLS Directory Server also supports Start TLS, a method of initiating a Transport Layer Security (TLS) connection over a regular, unencrypted LDAP port. Simple Authentication and Security Layer (SASL) SASL is a security framework that you can use to configure different mechanisms to authenticate a user to the server, depending on what mechanism you enable in both client and server applications. In addition, SASL can establish an encrypted session between the client and a server. Directory Server uses SASL with GSS-API, to enable Kerberos logins, and for almost all server-to-server connections, including replication, chaining, and pass-through authentication. Directory Server cannot use SASL with Windows synchronization. Secure connections are recommended for any operations which handle sensitive information, such as replication, and are mandatory for some operations, such as Windows password synchronization. Directory Server can support TLS connections, SASL, and non-secure connections simultaneously. Directory Server can support both SASL authentication and TLS connections at the same time. For example, you configured a Directory Server instance to require TLS connections to the server and also support SASL authentication for replication connections. This means it is not necessary to choose whether to use TLS or SASL in a network environment. In addition, you can set a minimum level of security for connections to the server. The security strength factor measures, in key strength, how strong a secure connection is. You can set an ACI that requires certain operations, such as password changes, occur only if the connection is of a certain strength or higher. You can also set a minimum SSF that can essentially disable standard connections and requires TLS, Start TLS, or SASL for every connection. The Directory Server supports TLS and SASL simultaneously, and the server calculates the SSF of all available connection types and selects the strongest one. Additional resources For more information about using TLS, Start TLS, and SASL, see Securing Red Hat Directory Server 7.10. Using SELinux policies SELinux is a collection of security policies that define access controls for the applications, processes, and files on a system. Security policies are a set of rules that tell SELinux what can or cannot be accessed to prevent unauthorized access and tampering. SELinux categorizes files, directories, ports, processes, users, and other objects on the server. SELinux places each object in an appropriate security context to define how the object is allowed to behave on the server through its role, user, and security level. SELinux groups these roles for objects into domains, and SELinux rules define how the objects in one domain are allowed to interact with objects in another domain. Directory Server has the following domains: dirsrv_t for the Directory Server dirsrv_snmp_t for the SNMP ldap_port_t for LDAP ports These domains provide security contexts for all of the processes, files, directories, ports, sockets, and users for the Directory Server: SELinux labels files and directories for each instance with a specific security context. Most of the main directories that Directory Server uses have subdirectories for all local instances, no matter how many, therefore SELinux easily applies a single policy to new instances. SELinux labels ports for each instance with a specific security context. SELinux constrains all Directory Server processes within an appropriate domain. Each domain has specific rules that define what actions are authorized for the domain. SELinux denies any access to the instance if SELinux policy does not specify it. SELinux has three different levels of enforcement: disabled No SELinux permissive SELinux processes rules are processed, however does not enforce them. enforcing SELinux strictly enforces all rules. Red Hat Directory Server has defined SELinux policies that allow it to run as normal under strict SELinux enforcing mode. Directory Server can run in different modes, one for normal operations and one for database operations, such as import ( ldif2db mode). The SELinux policies for Directory Server apply only to normal mode. By default, Directory Server runs in normal mode with SELinux policies. Additional resources How does SELinux work

Commands:
ldapsearch -x -D "cn=jsmith,ou=people,dc=example,dc=com" -b "dc=example,dc=com" "(cn=joe)"
ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -X "dn:cn=joe,dc=example,dc=com" -f mods.ldif
target permission bind_rule
target (permission bind_rule)(permission bind_rule)