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)

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

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.

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

1. If you want to allow users to change their own passwords, select the "User may change password" checkbox.
2. 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.
3. 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.
4. If you do not want user passwords to expire, select the "Password never expires" radio button.
5. 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.

1. 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.
2. 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.
3. From the "Password Encryption" pull-down menu, select the encryption method you want the server to use when storing passwords.

1. 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."

1.  
   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.

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.

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

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

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

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

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

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:

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

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

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

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.

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.

1. 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.

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

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.

1. 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.
2. Click OK to close the dialog box and save your changes.

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:

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.

1. 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.
2. 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.
3. Click OK when you are finished.

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:

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.

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.

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

1. 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:

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.

最后

以上就是沉默老师为你收集整理的User Account Management User Account Management 的全部内容，希望文章能够帮你解决User Account Management User Account Management 所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。