Chapter 7

User Account Management

---

When a user connects to your Red Hat Directory Server (Directory Server), first the user is authenticated. Then, the directory can grant access rights and resource limits to the user depending upon the identity established during authentication.

This chapter describes tasks for user account management, including configuring the password and account lockout policy for your directory, denying groups of users access to the directory, and limiting system resources available to users depending upon their bind DNs.

This chapter contains the following sections:

• Managing the Password Policy (page 283)
• Inactivating Users and Roles (page 300)
• Setting Resource Limits Based on the Bind DN (page 303)

Note	For an overview on password policy, see section "Designing a Password Policy" in chapter 7, "Designing a Secure Directory," in the Red Hat Directory Server Deployment Guide.

Managing the Password Policy

A password policy minimizes the risks of using passwords by enforcing the following:

• Users must change their passwords according to a schedule.
• Users must provide non-trivial passwords.

Once you have established a password policy, which can be for the entire directory or for specific subtrees or users, you can protect your user passwords from potential threats by configuring an account lockout policy. Account lockout protects against hackers who try to break into the directory by repeatedly guessing a user's password.

This section provides information about configuring your password and account lockout policies:

• Configuring the Password Policy
• Setting User Passwords
• Password Change Extended Operation
• Configuring the Account Lockout Policy
• Managing the Password Policy in a Replicated Environment
• Sycnhronizing Passwords

For an overview on password policy, check Red Hat Directory Server Deployment Guide.

Configuring the Password Policy

Directory Server supports fine-grained password policy, enabling you to define a policy that can be applied to the entire directory (global password policy), a particular subtree (subtree level or local password policy), or a particular user (user level or local password policy).

Essentially, your password policy is comprised of the following information:

• The type or level of password policy checks. This information indicates whether the server should check for and enforce a global password policy or local (subtree/user level) password policies.
• Password add and modify information. The password information includes password syntax and password history details.
• Bind information. The bind information includes the number of grace logins permitted, password aging attributes, and tracking bind failures.

The sections that follow describe the procedures for configuring your password policy:

• Configuring a Global Password Policy Using the Console
• Configuring a Subtree/User Password Policy Using the Console
• Configuring a Global Password Policy Using the Command-Line
• Configuring Subtree/User Password Policy Using the Command-Line

Note	After configuring your password policy, we recommend that you configure an account lockout policy. For details, see "Configuring the Account Lockout Policy," on page 296.

Configuring a Global Password Policy Using the Console

To set up or modify the password policy for an entire directory:

1. In the Directory Server Console, select the Configuration tab and then the Data node.
2. In the right pane, select the Passwords tab.

This tab contains the password policy for the entire Directory Server.

3. If you want users to change their password the first time they log on, select the "User must change password after reset" checkbox.

If you select this checkbox, only the Directory Manager is authorized to reset the users's password. A regular administrative user cannot force the users to update their password.

4. If you want to allow users to change their own passwords, select the "User may change password" checkbox.
5. If you want to prevent users from changing their password for a specific duration, enter the number of days in the "Allow changes in X day(s)" text box.
6. If you want the server to maintain a history list of passwords used by each user, select the "Keep password history" checkbox. Enter the number of passwords you want the server to keep for each user in the "Remember X passwords" text box.
7. If you do not want user passwords to expire, select the "Password never expires" radio button.
8. If you want users to change their passwords periodically, select the "Password expires after X days" radio button, and then enter the number of days that a user password is valid.

The maximum value for the password age is derived by subtracting January 18, 2038, from today's date. The value you enter must not be set to the maximum value or too close to the maximum value. If you set the value to the maximum value, Directory Server may fail to start because the number of seconds will go past the epoch date. In such an event, the error log will indicate that the password maximum age is invalid. To resolve this problem, you must correct the passwordMaxAge attribute value in the dse.ldif file.

A common policy is to have passwords expire every 30 to 90 days. By default, the password maximum age is set to 8640000 seconds (100 days).

9. If you have selected the "Password expire after X days" radio button, you need to specify how long before the password expires to send a warning to the user. In the "Send Warning X Days Before Password Expires" text enter the number of days before password expiration to send a warning.
10. If you want the server to check the syntax of a user password to make sure it meets the minimum requirements set by the password policy, select the "Check Password Syntax" checkbox. Then, specify the minimum acceptable password length in the "Password Minimum Length" text box.
11. From the "Password Encryption" pull-down menu, select the encryption method you want the server to use when storing passwords.

For detailed information about the encryption methods, refer to the passwordStorageScheme attribute in Table 7-1, on page 287,.

The Password Encryption menu might contain other encryption methods, as the directory dynamically creates the menu depending upon the existing encryption methods it finds in your directory.

12. When you have finished making changes to the password policy, click Save.

Configuring a Subtree/User Password Policy Using the Console

To set up the password policy for a subtree or user, you need to add the required entries and attributes at the subtree or user level, set the appropriate values to the password policy attributes, and enable fine-grained password policy checking.

1. Enable fine-grained password policy.
   1. In the Directory Server Console, select the Configuration tab.
   2. In the navigation tree, select the Data node.
   3. In the right pane, select the Passwords tab.
   4. Check the "Enable fine-grained password policy" checkbox.
   5. Click Save to save your changes.
2. Create the local password policy for the subtree or user.
   1. In the Directory Server Console, select the Directory tab.
   2. In the navigation pane, select the subtree or user entry for which you want to set up the password policy.
   3. From the Object menu, select the Manage Password Policy option, and then select the "For user" or "For subtree."

Depending on your selection, the User Password Policy or Subtree Password Policy window appears.

1. In the Passwords tab, select the "Create subtree/user level password policy" checkbox to add the required attributes, fill in the appropriate values, and click Save.
2. In the Account Lockout tab, specify the appropriate information, and click Save.

Configuring a Global Password Policy Using the Command-Line

This section describes the attributes you set to create a password policy for your entire server. Use ldapmodify to change these attributes in the cn=config entry.

Table 7-1 describes the attributes you can use to configure your password policy.

Table 7-1 Password Policy Attributes  

Attribute Name	Definition
passwordGraceLimit	This attribute indicates the number of grace logins permitted when a user's password is expired. When set to a positive number, the user will be allowed to bind with the expired password for that many times. For the global password policy, the attribute is defined under cn=config. By default, this attribute is set to 0, which means grace logins are not permitted.
passwordMustChange	When on, this attribute requires users to change their passwords when they first login to the directory or after the password is reset by the Directory Manager. When on, the user is required to change their password even if user-defined passwords are disabled. If you choose to set this attribute to off, passwords assigned by the Directory Manager should not follow any obvious convention and should be difficult to discover. This attribute is off by default.
passwordChange	When on, this attribute indicates that users may change their own password. Allowing for users to set their own passwords runs the risk of users choosing passwords that are easy to remember. However, setting good passwords for the user requires a significant administrative effort. In addition, providing passwords to users that are not meaningful to them runs the risk that users will write the password down somewhere that can be discovered. This attribute is on by default.
passwordExp	When on, this attribute indicates that the user's password will expire after an interval given by the passwordMaxAge attribute. Making passwords expire helps protect your directory data because the longer a password is in use, the more likely it is to be discovered. This attribute is off by default.
passwordMaxAge	This attribute indicates the number of seconds after which user passwords expire. To use this attribute, you must enable password expiration using the passwordExp attribute. This attribute is a dynamic parameter in that its maximum value is derived by subtracting January 18, 2038, from today's date. The attribute value must not be set to the maximum value or too close to the maximum value. If you set the value to the maximum value, Directory Server may fail to start because the number of seconds will go past the epoch date. In such an event, the error log will indicate that the password maximum age is invalid. To resolve this problem, you must correct the passwordMaxAge attribute value in the dse.ldif file. A common policy is to have passwords expire every 30 to 90 days. By default, the password maximum age is set to 8640000 seconds (100 days).
passwordWarning	This attribute indicates the number of seconds before a warning message is sent to users whose password is about to expire. Depending on the LDAP client application, users may be prompted to change their password when the warning is sent. Both Red Hat Directory Express and the Directory Server Gateway provide this functionality. By default, the directory sends the warning 86400 seconds (1 day) before the password is about to expire. However, a password never expires until the warning message has been set. Therefore, if users don't bind to the Directory Server for longer than the passwordMaxAge, they will still get the warning message in time to change their password.
passwordCheckSyntax	When on, this attribute indicates that the password syntax will be checked by the server before the password is saved. Password syntax checking ensures that the password string meets or exceeds the minimum password length requirements and that the string does not contain any "trivial" words. A trivial word is any value stored in the uid, cn, sn, givenName, ou, or mail attributes of the user's entry. This attribute is off by default.
passwordMinLength	This attribute specifies the minimum number of characters that must be used in passwords. Shorter passwords are easier to crack. You can require passwords that are 2 to 512 characters long. Generally, a length of 6 to 8 characters is long enough to be difficult to crack but short enough for users to remember without writing it down. This attribute is set to 6 by default.
passwordMinAge	This attribute indicates the number of seconds that must pass before a user can change their password. Use this attribute in conjunction with the passwordInHistory attribute to discourage users from reusing old passwords. For example, setting the minimum password age to 2 days prevents users from repeatedly changing their passwords during a single session to cycle through the password history and reuse an old password once it has been removed from the history list. You can specify from 0 to 2147472000 seconds (24,855 days). A value of zero indicates that the user can change the password immediately. The default value of this attribute is 0.
passwordHistory	This attribute indicates whether the directory stores a password history. When set to on, the directory stores the number of passwords you specify in the passwordInHistory attribute in a history. If a user attempts to reuse one of the passwords, the password will be rejected. When you set this attribute to off, any passwords stored in the history remain there. When you set this attribute back to on, users will not be able to reuse the passwords recorded in the history before you disabled the attribute. This attribute is off by default, meaning users can reuse old passwords.
passwordInHistory	This attribute indicates the number of passwords the directory stores in the history. You can store from 2 to 24 passwords in the history. This feature is not enabled unless the passwordHistory attribute is set to on. This attribute is set to 6 by default.
passwordStorageScheme	This attribute specifies the type of encryption used to store Directory Server passwords. The following encryption types are supported by Directory Server: SSHA (Salted Secure Hash Algorithm). This method is recommended as it is the most secure. This is the default method. SHA ( Secure Hash Algorithm). A one-way hash algorithm; it is supported only forbackwards compatibility with Directory Server 4.x and should not be used otherwise. crypt. The UNIX crypt algorithm, provided for compatibility with UNIX passwords. clear. This encryption type indicates that the password will appear in plain text. Passwords stored using crypt, SHA, or SSHA formats cannot be used for secure login through SASL Digest MD5. If you want to provide your own customized storage scheme, consult Red Hat Professional Services.

Configuring Subtree/User Password Policy Using the Command-Line

To configure a subtree or user level password policy:

1. Add the required attributes to the subtree or user entries by running the ns-newpwpolicy.pl script.

The command syntax for the script is as follows:

ns-newpwpolicy.pl [-D rootDN] { -w password | -w - | -j filename } 
[-p port] [-h host] -U userDN -S suffixDN
 

For updating a subtree entry, use the -S option. For updating a user entry, use the -U option. The ns-newpwpolicy.pl script accepts only one user or subtree entry at a time. It can, however, accept both user and suffix entries at the same time. For details about the script, see the Red Hat Directory Server Configuration, Command, and File Reference.

The script adds the required attributes depending on whether the target entry is a subtree or user entry.

For a subtree (for example, ou=people, dc=example, dc=com), the following entries are added:

• A container entry (nsPwPolicyContainer) at the subtree level for holding various password policy-related entries for the subtree and all its children. For example:

dn: cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
objectClass: top
objectClass: nsContainer
cn: nsPwPolicyContainer

• The actual password policy specification entry (nsPwPolicyEntry) for holding all the password policy attributes that are specific to the subtree. For example:

dn: cn="cn=nsPwPolicyEntry, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
objectclass: top
objectclass: extensibleObject
objectclass: ldapsubentry
objectclass: passwordpolicy

• The CoS template entry (nsPwTemplateEntry) that has the pwdpolicysubentry value pointing to the above (nsPwPolicyEntry) entry. For example:

dn: cn="cn=nsPwTemplateEntry, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
objectclass: top
objectclass: extensibleObject
objectclass: costemplate
objectclass: ldapsubentry
cosPriority: 1
pwdpolicysubentry: cn="cn=nsPwPolicyEntry, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com

• The CoS specification entry at the subtree level. For example:

dn: cn=nsPwPolicy_cos, ou=people, dc=example, dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn="cn=nsPwTemplateEntry, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
cosAttribute: pwdpolicysubentry default operational

For a user (for example, uid=jdoe, ou=people, dc=example, dc=com), the following entries are added:

• A container entry (nsPwPolicyContainer) at the parent level for holding various password policy related entries for the user and all its children. For example:

dn: cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
objectClass: top
objectClass: nsContainer
cn: nsPwPolicyContainer

• The actual password policy specification entry (nsPwPolicyEntry) for holding the password policy attributes that are specific to the user. For example:

dn: cn="cn=nsPwPolicyEntry, uid=jdoe, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
objectclass: top
objectclass: extensibleObject
objectclass: ldapsubentry
objectclass: passwordpolicy

• Assign the value of the above entry DN to the pwdpolicysubentry attribute of the target entry. For example:

dn: uid=jdoe, ou=people, dc=example, dc=com
changetype: modify
replace: pwdpolicysubentry
pwdpolicysubentry: "cn=nsPwPolicyEntry, uid=jdoe, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com

2. Set the password policy attributes of subtree or user entry with the appropriate values.

Table 7-1 describes the attributes you can use to configure your password policy. You may use the ldapmodify utility to change these attributes in the cn=config entry.

Note

The nsslapd-pwpolicy-local attribute of the cn=config entry controls the type of password policy the server enforces. By default, this attribute is disabled (off). When the attribute is disabled, the server only checks for and enforces the global password policy; the subtree and user level password policies are ignored. When you run the ns-newpwpolicy.pl script, it first checks for the specified subtree and user entries and, if they exist, modifies them. After updating the entries successfully, the script sets the nsslapd-pwpolicy-local configuration parameter to on. If you don't want to enable the subtree and user level password policy, be sure to set nsslapd-pwpolicy-local to off after you run the script.

To turn off user and subtree level password policy checks, set the nsslapd-pwpolicy-local attribute to off by modifying the cn=config entry. For example, you can use the ldapmodify command to make these changes:

dn: cn=config

changetype: modify

replace: nsslapd-pwpolicy-local: on

nsslapd-pwpolicy-local: off
 

You can also disable the attribute by modifying it directly in the configuration file (dse.ldif). To do this:

1. Stop the server.
2. Open the dse.ldif file in a text editor.
3. Set the value of nsslapd-pwpolicy-local to off, and save your changes.
4. Start the server.

Setting User Passwords

An entry can be used to bind to the directory only if it has a userpassword attribute and if it has not been inactivated. Because user passwords are stored in the directory, you can use whatever LDAP operation you normally use to update the directory to set or reset the user passwords.

For information on creating and modifying directory entries, see Chapter 2, "Creating Directory Entries." For information on inactivating user accounts, refer to "Inactivating Users and Roles," on page 300.

You can also use the Users and Groups area of the Red Hat Administration Server or the Directory Server Gateway to set or reset user passwords. For information on how to use the Users and Groups area, see the online help that is available in the Red Hat Administration Server. For information on how to use the Gateway to create or modify directory entries, see the online help that is available in the Gateway.

Password Change Extended Operation

While most passwords can be changed through the Console and other Directory Server features or through the ldapmodify operation, there are some passwords that cannot be changed through regular LDAP operations. These passwords may be stored outside the Directory Server, such as passwords stored in a SASL application. These passwords can be modified through the password change extended operation.

Directory Server supports the password change extended operation as defined in RFC 3062. This allows users to change their passwords, using a suitable client, in a standards-compliant way. Directory Server does not include a client application for the password change extended operation. However, the ldappasswd utility from OpenLDAP can be used as follows:

./ldappasswd -H ldaps://hostname:port -ZZ[Z] -D bindDN -w bindPassword 
-a oldPassword -s newPassword user
 

For more information on how to use ldappasswd utility, see the OpenLDAP documentation at http://www.openldap.org, or type man ldappasswd in the command-line for the ldappasswd manpage.

Note	This operation supports Start TLS encryption (-ZZ[Z]), and you must use a secure connection for the password change operation.

Note

If your certificates are either self-signed or are issued by a certificate authority not trusted by the client application, then you may need to create a configuration file which contains the option TLS_REQCERT never, which suppresses certificate verification, or TLS_CACERT /path/to/cacert.pem, which specifes the path to you CA certificate. Set the LDAPConf environment variable to this file.

To modify an entry's password, run ldappasswd like any other LDAP operation. It is not necessary to specify a user if the account is the same as that given in the bindDN. For example:

./ldappasswd -H ldaps://server.example.com:24256 -ZZ -D 
"uid=jsmith,ou=People,dc=example,dc=com" -w oldpassword -a 
oldpassword -s newpassword 
 

To change the password on an entry other than the one specified in the bind credentials, run ldappasswd as shown below, adding the user DN to the operation and providing separate credentials, as follows:

ldappasswd -H ldaps://server.example.com:24256 -ZZ -D 
"cn=Directory Manager" -w rootpassword -a oldpassword -s 
newpassword "uid=jsmith,ou=People,dc=example,dc=com"
 

Access control is enforced for the password change operation. If the bindDN does not have rights to change the specified password, the operation will fail with the "Insufficient rights" error.

Configuring the Account Lockout Policy

The lockout policy works in conjunction with the password policy to provide further security. The account lockout feature protects against hackers who try to break into the directory by repeatedly trying to guess a user's password. You can set up your password policy so that a specific user is locked out of the directory after a given number of failed attempts to bind.

Configuring the account lockout policy is described in the following sections:

• Configuring the Account Lockout Policy Using the Console
• Configuring the Account Lockout Policy Using the Command-Line

Configuring the Account Lockout Policy Using the Console

To set up or modify the account lockout policy for your Directory Server:

1. In the Directory Server Console, select the Configuration tab and then the Data node.
2. In the right pane, select the Account Lockout tab.
3. To enable account lockout, select the "Accounts may be locked out" checkbox.
4. Enter the maximum number of allowed bind failures in the "Lockout account after X login failures" text box. The server locks out users who exceed the limit you specify here.
5. Enter the number of minutes you want the server to wait before resetting the bind failure counter to 0 in the "Reset failure counter after X minutes" text box.
6. Set the interval you want users to be locked out of the directory.

Select the Lockout Forever radio button to lock users out until their passwords have been reset by the administrator.

Set a specific lockout period by selecting the Lockout Duration radio button and entering the time (in minutes) in the text box.

7. When you have finished making changes to the account lockout policy, click Save.

Configuring the Account Lockout Policy Using the Command-Line

This section describes the attributes you set to create an account lockout policy to protect the passwords stored in your server. Use ldapmodify to change these attributes in the cn=config entry.

Table 7-2 describes the attributes you can use to configure your account lockout policy.

Table 7-2 Account Lockout Policy Attributes  

Attribute Name	Definition
passwordLockout	This attribute indicates whether users are locked out of the directory after a given number of failed bind attempts. You set the number of failed bind attempts after which the user will be locked out using the passwordMaxFailure attribute. You can lock users out for a specific time or until an administrator resets the password. This attribute is set to off by default, meaning that users will not be locked out of the directory.
passwordMaxFailure	This attribute indicates the number of failed bind attempts after which a user will be locked out of the directory. This attribute takes affect only if the passwordLockout attribute is set to on. This attribute is set to 3 bind failures by default.
passwordLockoutDuration	This attribute indicates the time, in seconds, that users will be locked out of the directory. You can also specify that a user is locked out until the password is reset by an administrator using the passwordUnlock attribute. By default, the user is locked out for 3600 seconds.
passwordResetFailureCount	This attribute specifies the time, in seconds, after which the password failure counter will be reset. Each time an invalid password is sent from the user's account, the password failure counter is incremented. If the passwordLockout attribute is set to on, users will be locked out of the directory when the counter reaches the number of failures specified by the passwordMaxFailure attribute. The account is locked out for the interval specified in the passwordLockoutDuration attribute, after which time the failure counter is reset to zero (0). Because the counter's purpose is to gauge when a hacker is trying to gain access to the system, the counter must continue for a period long enough to detect a hacker. However, if the counter were to increment indefinitely over days and weeks, valid users might be locked out inadvertently. The reset password failure count attribute is set 600 seconds by default.

Managing the Password Policy in a Replicated Environment

Password and account lockout policies are enforced in a replicated environment as follows:

• Password policies are enforced on the data master.
• Account lockout is enforced on all servers participating in replication.

Some of the password policy information in your directory is replicated. The replicated attributes are:

• passwordMinAge and passwordMaxAge
• passwordExp
• passwordWarning

However, the configuration information is kept locally and is not replicated. This information includes the password syntax and the history of password modifications. Account lockout counters and tiers are not replicated, either.

When configuring a password policy in a replicated environment, consider the following points:

• Warnings from the server of an impending password expiration will be issued by all replicas. This information is kept locally on each server, so if a user binds to several replicas in turn, they will be issued the same warning several times. In addition, if the user changes the password, it may take time for this information to filter to the replicas. If a user changes a password and then immediately rebinds, he may find that the bind fails until the replica registers the changes.
• You want the same bind behavior to occur on all servers, including suppliers and replicas. Make sure to create the same password policy configuration information on each server.
• Account lockout counters many not work as expected in a multi-mastered environment.
• Entries that are created for replication (for example, the server identities) need to have passwords that never expire. To make sure that these special users have passwords that do not expire, add the passwordExpirationTime attribute to the entry, and give it a value of 20380119031407Z (the top of the valid range).

Sycnhronizing Passwords

Password changes in a Directory Server entry can be synchronized to password attributes in Windows NT4 server or Active Directory entries by using the Password Sync utility.

When passwords are synchronized, password policies are enforced on each sync peer locally; i.e., the syntax or minimum length requirements on the Directory Server apply when the password is changed in the Directory Server; when the changed password is synched over to the Windows server, the Winodws password policy is enforced. The password policies themselves are not synchronized.

Configuration information is kept locally and cannot be synchronized. This information includes the history of password modifications. Account lockout counters are not synchronized, either.

When configuring a password policy for synchornization, consider the following points:

• The Password Sync utility must be installed locally on the Windows machine that will be synchronized with a Directory Server.
• Password Sync can only link the Windows machine to a single Directory Server; to sync changes with multiple Directory Server, configure the Directory Server for multi-master replication.
• Password expiration warnings and times, failed bind attempts, and other password-related information is enforced locally per server adn is not synchronized between sync peer servers.
• You want the same bind behavior to occur on all servers. Make sure to create the same or similar password policies on both Directory Server, Windows NT4 Server, and Active Directory servers.
• Entries that are created for synchronization (for example, the server identities) need to have passwords that never expire. To make sure that these special users have passwords that do not expire, add the passwordExpirationTime attribute to the Directory Server entry, and give it a value of 20380119031407Z (the top of the valid range).

See Chapter 18, "Windows Sync," for more information on synchronizing Directory Server and Windows users and passwords.

Inactivating Users and Roles

You can temporarily inactivate a single user account or a set of accounts. Once inactivated, a user cannot bind to the directory. The authentication operation will fail.

Users and roles are inactivated using the operational attribute nsAccountLock. When an entry contains the nsAccountLock attribute with a value of true, the server rejects the bind.

You use the same procedures for inactivating users and roles. However, when you inactivate a role, you are inactivating the members of the role and not the role entry itself. For more information about roles in general and how roles interact with access control in particular, refer to Chapter 5, "Advanced Entry Management."

The rest of this section describes the following procedures:

• Inactivating User and Roles Using the Console
• Inactivating User and Roles Using the Command-Line
• Activating User and Roles Using the Console
• Activating User and Roles Using the Command-Line

Caution

You cannot inactivate the root entry (the entry corresponding to the root or sub suffix) on a database. For more information on creating the entry for a root or sub suffix, refer to Chapter 2, "Creating Directory Entries," for more information. For more information on creating root and sub suffixes, refer to Chapter 3, "Configuring Directory Databases."

Inactivating User and Roles Using the Console

The following procedure describes inactivating a user or a role using the Console:

1. In the Directory Server Console, select the Directory tab.
2. Browse the navigation tree in the left navigation pane, and double-click the user or role you want to inactivate.

The Edit Entry dialog box appears.

You can also select Inactivate from the Object menu as a short cut.

3. Click Account in the left pane. The right pane states that the role or user is inactivated. Click Activate to activate the user or role.
4. Click OK to close the dialog box and save your changes.

Once inactivated, you can view the state of the object by selecting Inactivation State from the View menu. The icon of the object then appears in the right pane of the Console with a red slash through it.

Inactivating User and Roles Using the Command-Line

To inactivate a user account, use the ns-inactivate.pl script. The following example describes using the ns-inactivate.pl script to inactivate Joe Frasier's user account:

ns-inactivate.pl -D "Directory Manager" -w secretpwd -p 389 

-h example.com -I "uid=jfrasier,ou=people,dc=example,dc=com"
 

The following table describes the ns-inactivate.pl options used in the example:

Option Name	Description
-D	The DN of the directory administrator.
-w	The password of the directory administrator.
-p	Port used by the server.
-h	Name of the server on which the directory resides.
-I	DN of the user account or role you want to inactivate.

For more information about running the ns-inactivate.pl script, refer to Red Hat Directory Server Configuration, Command, and File Reference.

Activating User and Roles Using the Console

The following procedure describes activating a user or a role using the Console:

1. In the Directory Server Console, select the Directory tab.
2. Browse the navigation tree in the left navigation pane, and double-click the user or role you want to activate.

The Edit Entry dialog box appears.

You can also select Activate from the Object menu as a short cut.

3. Click Account in the left pane. The right pane states that the role or user is activated. Click Activate to activate the user or role.
4. If the user or role is a member of another inactivated role, the Console displays an option for viewing the inactivated roles. Click Show Inactivated Roles to view the list of roles to which the user or role belongs.
5. Click OK when you are finished.

Once reactivated, you can view the state of the object by selecting Inactivation State from the View menu. The icon of the role or user in the right pane of the Console appears as normal. The red slash through the icon indicating it was inactive disappears.

Activating User and Roles Using the Command-Line

To activate a user account, use the ns-activate.pl script. The following example describes using the ns-activate.pl script to activate Joe Frasier's user account:

ns-activate.pl -D "Directory Manager" -w secretpwd -p 389 

-h example.com -I "uid=jfrasier,ou=people,dc=example,dc=com"
 

The following table describes the ns-inactivate.pl options used in the example:

Option Name	Description
-D	The DN of the directory administrator.
-w	The password of the directory administrator.
-p	Port used by the server.
-h	Name of the server on which the directory resides.
-I	DN of the user account or role you want to activate.

For more information about running the ns-activate.pl script, refer to Red Hat Directory Server Configuration, Command, and File Reference.

Setting Resource Limits Based on the Bind DN

You can control server limits for search operations using special operational attribute values on the client application binding to the directory. You can set the following search operation limits:

• Look through limit. Specifies how many entries can be examined for a search operation.
• Size limit. Specifies the maximum number of entries the server returns to a client application in response to a search operation.
• Time limit. Specifies the maximum time the server spends processing a search operation.
• Idle timeout. Specifies the time a connection to the server can be idle before the connection is dropped.

Note	The Directory Manager receives unlimited resources by default.

The resource limits you set for the client application take precedence over the default resource limits you set for in the global server configuration.

This section gives procedures for the following:

• Setting Resource Limits Using the Console
• Setting Resource Limits Using the Command-Line

Setting Resource Limits Using the Console

The following procedure describes setting resource limits for a user or a role using the Console:

1. In the Directory Server Console, select the Directory tab.
2. Browse the navigation tree in the left navigation pane, and double-click the user or role for which you want to set resource limits.

The Edit Entry dialog box appears.

3. Click Account in the left pane. The right pane contains the four limits you can set in the Resource Limits section.

Entering a value of -1 indicates no limit.

4. Click OK when you are finished.

Setting Resource Limits Using the Command-Line

The following operational attributes can be set for each entry using the command-line. Use ldapmodify to add the following attributes to the entry:

Attribute	Description
nsLookThroughLimit	Specifies how many entries examined for a search operation. Specified as a number of entries. Giving this attribute a value of -1 indicates that there is no limit.
nsSizeLimit	Specifies the maximum number of entries the server returns to a client application in response to a search operation. Giving this attribute a value of -1 indicates that there is no limit.
nsTimeLimit	Specifies the maximum time the server spends processing a search operation. Giving this attribute a value of -1 indicates that there is no time limit.
nsIdleTimeout	Specifies the time a connection to the server can be idle before the connection is dropped. The value is given in seconds. Giving this attribute a value of -1 indicates that there is no limit.

For example, you might set the size limit for an entry by performing an ldapmodify as follows:

ldapmodify -h myserver -p 389 -D "cn=directory manager" -w 
secretpwd

dn: uid=bjensen,ou=people,dc=example,dc=com

changetype: modify

add:nsSizeLimit

nsSizeLimit: 500
 

The ldapmodify statement adds the nsSizeLimit attribute to Babs Jensen's entry and gives it a search return size limit of 500 entries.