Securing directory access

Directory Server, Version 6.1

Securing directory access

Access to directory data can be fully controlled by the directory administrator. LDAP directories require clients to perform a bind operation that identifies who is trying to use the directory. The Tivoli® Directory Server supports several bind mechanisms:

Simple
DIGEST-MD5
Kerberos (also known as GSSAPI)
EXTERNAL

The directory server supports pass-through authentication, which allows the administrator to configure the directory server to use other directory servers such as OpenLDAP or Active Directory to provide authentication for the binds. See Pass-through authentication.
Simple binds require a DN and a password. If no DN is supplied, the binds are said to be anonymous. The administrator can configure the directory so that anonymous binds are not allowed. (See "Managing connection properties" in Chapter 9Managing connection properties. Generally, the DN corresponds to an entry in the directory. The password used for binding to the directory server is the value of the userpassword attribute associated with the entry with the given DN. The directory server can be configured to enforce password policies that determine what kinds of values passwords can have and how often they must be changed. (See Setting password policy.) The password data stored in the directory is encrypted. (See Password encryption.) The directory administrator can delegate some administrative responsibilities by configuring an administrative group. The members of this group can be assigned specific authorities in the directory. The DN and passwords for these are stored as part of the server configuration. The passwords are encrypted and an administrative password policy can be configured. See Setting the administration password and lockout policy.
DIGEST-MD5 and Kerberos (GSSAPI) are described in this chapter. The EXTERNAL mechanism, also referred to as PKI or certificate based authentication, relies on the authentication performed by a directory server using SSL or TLS when the server is configured for server and client authentication. The client connection is established only after the client provides a certificate issued by a Certifying Authority (CA) trusted by the server. The client's certificate has a DN and it is this DN that is used to identify the user of this client connection. See Configuring security settings for information about how to configure a directory server to support EXTERNAL binds.

Password encryption

IBM® Directory enables you to prevent unauthorized access to user passwords. Using one-way encryption formats, user passwords may be encrypted and stored in the directory, which prevents clear passwords from being accessed by any users including the system administrators.
The administrator may configure the server to encrypt userPassword attribute values in either a one-way encrypting format or a two-way encrypting format.
One-way encrypting formats:

crypt
MD5
SHA-1
Salted SHA-1

After the server is configured, any new passwords (for new users) or modified passwords (for existing users) are encrypted before they are stored in the directory database. The encrypted passwords are tagged with the encrypting algorithm name so that passwords encrypted in different formats can coexist in the directory. When the encrypting configuration is changed, existing encrypted passwords remain unchanged and continue to work.
For applications that require retrieval of clear passwords, such as middle-tier authentication agents, the directory administrator needs to configure the server to perform either a two-way encrypting or no encryption on user passwords. In this instance, the clear passwords stored in the directory are protected by the directory ACL mechanism.
Two-way encrypting format:

AES

A two-way encryption option, AES, is provided to allow values of the userPassword attribute to be encrypted in the directory and retrieved as part of an entry in the original clear format. It can be configured to use 128-, 192-, and 256-bit key lengths. Some applications such as middle-tier authentication servers require passwords to be retrieved in clear text format, however, corporate security policies might prohibit storing clear passwords in a secondary permanent storage. This option satisfies both requirements.
A simple bind will succeed if the password provided in the bind request matches any of the multiple values of the userPassword attribute.
When you configure the server using Web Administration, we can select one of the following encryption options:

None

No encryption. Passwords are stored in the clear text format.

crypt

Passwords are encrypted by the UNIX® crypt encrypting algorithm before they are stored in the directory.

MD5

Passwords are encrypted by the MD5 Message Digest algorithm before they are stored in the directory.

SHA-1

Passwords are encrypted by the SHA-1 encrypting algorithm before they are stored in the directory.

Salted SHA-1

Passwords are encrypted by the Salted SHA-1 encrypting algorithm before they are stored in the directory.

AES128

Passwords are encrypted by the AES128 algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format.

AES192

Passwords are encrypted by the AES192 algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format.

AES256

Passwords are encrypted by the AES256 algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format.

The imask format that was available in previous releases is no longer an encryption option. However, any existing imask encrypted values still work.
The default option is AES256. A change is registered in a password encryption directive of the server configuration file:
ibm-SlapdPwEncryption: AES256
The server configuration file is located in:
<instance_directory>\etc\ibmslapd.conf 
In addition to userPassword, values of the secretKey attribute are always "AES256" encrypted in the directory. Unlike userPassword, this encrypting is enforced for values of secretKey. No other option is provided. The secretKey attribute is an IBM defined schema. Applications may use this attribute to store sensitive data that need to be always encrypted in the directory and to retrieve the data in clear text format using the directory access control.
Consult the IBM Tivoli Directory Server Version 6.1 Installation and Configuration Guide for additional information about the configuration file.
To specify the type of password encryption, use one of the following methods:

Using Web Administration:

If you have not done so already, click Server administration in the Web Administration navigation area and then click Manage security properties in the expanded list. Click the Password encryption tab.
To set password encryption:

Select a password encryption type from the Set the password encryption mechanism combo box.
When you are finished, do one of the following:

Click OK to apply your changes and exit this panel.
Click Apply to apply your changes and stay on this panel.
Click Cancel to exit this panel without making any changes.

Using the command line:

To change the type of encryption using the command line, for example to crypt, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename>contains:
dn: cn=configuration
changetype: modify
replace: ibm-slapdPWEncryption
ibm-slapdPWEncryption: crypt
To cause the updated settings to take effect dynamically, issue the following idsldapexop command:
idsldapexop -D <adminDN> -w <adminPW> -op readconfig -scope single 
        "cn=configuration" ibm-slapdPWEncryption
Notes:

If the UNIX crypt method is used, only the first 8 characters are effective.
A one-way encrypted password can be used for password matching but it cannot be decrypted. During user login, the login password is encrypted and compared with the stored version for matching verification.

Setting password policy

Password policy is a set of rules that controls how passwords are used and administered in the IBM Directory. These rules are made to ensure that users change their passwords periodically, and that the passwords meet the organization's syntactic password requirements. These rules can also restrict the reuse of old passwords and ensure that users are locked out after a defined number of failed bind attempts.
When an administrator sends a request to turn on password policy, the ibm-pwdPolicyStartTime attribute is generated by the server. This attribute is an optional attribute which cannot be deleted or modified by a client request. Only administrators with administrative control can modify the ibm-pwdPolicyStartTime attribute. The value of this attribute is changed when the Password Policy is turned on and off by an administrator. When the ibm-pwdPolicyStartTime attribute is turned on and off, the value of the attribute gets reset and the user entry's last changed time which is evaluated based on the entry's modifyTimestamp and the ibn-pwdPolicyStartTime may get changed. As a result, some old passwords which would have expired may not expire when the password policy is turned off and on.

It is essential to note that a password policy entry has to be created before it can be associated with a user or a group entry as an individual or a group password policy. If the referenced password policy entry does not exist, a message "unwilling to perform" is returned. Once a password policy entry has been referenced by a user or group entry, it cannot be renamed or deleted unless the association between the entry and the user or group entry has been removed.
For additional information about passwords see Password Guidelines.
TDS provides three types of password policies: individual, group, and global password policies.

Global Password Policy

When a global password policy entry (cn=pwdpolicy,cn=ibmpolicies) is created by the server, the attribute ibm-pwdPolicy is set to FALSE, which is the default value. This means that all password policy entries will be ignored by the server. Only when the ibm-pwdPolicy attribute is set to TRUE the password rules are enforced by the server. When a global password policy is enforced and the ibm-pwdGroupAndIndividualEnabled attribute in cn=pwdpolicy,cn=ibmpolicies is set to TRUE, the group and individual password policies are also considered when evaluating the password policy.

Group Password Policy

The group password policy enables members of a group to be controlled by a set of special password rules. For group password policy, ibm-pwdGroupPolicyDN attribute pointing to a password policy entry can be used in any user group objects such as accessGroup, accessRole, and groupOfNames.
Since a user entry may belong to more than one group, multiple group password policy entries will be evaluated before the user's group policy can be determined. In order to evaluate a composite group policy, group password policy entries are combined to form a union of attributes with the most restrictive attribute values taking precedence.

Individual Password Policy

Individual password policy enables every user entry to have its own password policy. For individual password policy, attribute ibm-pwdIndividualPolicyDN pointing to a password policy entry can be used to extend a user to have its own password policy entry. By changing the attributes of the password policy entry, an administrator can effectively manage password policy for a set of users without modifying any of the user entries.

By assigning a value of cn=noPwdPolicy to attribute ibm-pwdIndividualPolicyDN for a password policy extended user entry, an administrator may exempt a user from any password policy controls.

Password Evaluation

To evaluate a user's effective password policy, all password policies associated with a user are taken into consideration starting with the individual password policy. Next, the group password policy is considered and finally the global password policy is taken into consideration. If an attribute is not defined in the individual password policy entry, it will be searched in the composite group password policy entry. If it is not found in the composite group policy entry, the attribute in the global password policy entry will be used. In case the attribute is not defined in the global password policy entry, then the default value will be assumed.

The effective password policy extended operation (effectpwdpolicy) is used to display the effective password policy of a given user. Information about the password policy entries which are used to calculate the effective password policy is also displayed using this extended operation. For more information about this extended operation, see the IBM Tivoli Directory Server version 6.1 Command Reference.

Evaluation of a user's Group Password Policy

Since a user entry may belong to more than one group, multiple group password policy entries may be evaluated to determine a user's composite group policy. Following are the rules for determining a user's composite group password policy:

If ibm-pwdPolicy is set to False in a Password policy entry, no attributes defined in the entry will be used to determine the composite group password policy. If the attribute is not set, then the default value of False is assumed for the attribute.
If ibm-pwdGroupPolicyDN has a value of cn=noPwdPolicy in all the groups that a user belongs to, no composite group password will be evaluated for the user. In this case, unless the user has an individual password policy defined, no policy (not even the global) will be applied.
An attribute defined with a non-default value is more restrictive than if defined with a default value which, in turn, is more restrictive than if it is not defined at all.
The password policy attributes passwordMinAlphaChars, pwdMinLength, and passwordMinOtherChars are interdependent. For instance, the value of passwordMinAlphaChars must be set to less than or equal to the value in pwdMinLength minus the value in passwordMinOtherChars. Due to this inter-dependency among attribute values, if one attribute is selected from a policy, then the other two attributes are also selected from the same policy.
The order of selection will be pwdMinLength, passwordMinOtherChars, and passwordAlphaChars. This means that the selection will be based on picking the largest value for pwdMinLength. In case of a situation where two group policies have the same value for the pwdMinLength attribute, then the one with the largest value for passwordMinOtherChars will be selected. Once an attribute is selected, the other two attributes will be selected automatically.
Attributes in all the group password policy entries are combined to form a union of attributes with the most restrictive attribute values taking precedence. Given below is a table that describes how the most restrictive attribute values are determined:
Table 15. Determining the most restrictive attribute values

Pwd Policy Attribute More restrictive value Valid values Default values

pwdAttribute N/A userPassword userPassword
pwdMinAge Greater Greater than or equal (GE) to 0 0 - no age limit
pwdMaxAge Less GE 0 0 - password does not expire
pwdInHistory Greater 0 to 10 0 - no password history
pwdCheckSyntax Greater
0, 1, 2
1 - if server not able to check the syntax, then accept password 2 - if server is not able to check the syntax, then reject the password
0
pwdMinLength Greater GE 0 0 - no minimum length
pwdExpireWarning Greater GE 0 0 - no warnings will be sent
pwdGraceLoginLimit Less GE 0 0 - no grace login
pwdLockout True True/False False
pwdLockoutDuration Greater GE 0 0 - locked out until reset
pwdMaxFailure Less GE 0 0 - no failure count, no lockout
pwdFailureCountInterval Greater GE 0 0 - no count, reset by successfully authentication
pwdMustChange True True/False True/False if cn=noPwdPolicy
pwdAllowUserChange True True/False True
pwdSafeMode True True/False False
Ibm-pwdPolicy True True/False False
passwordMinAlphaChars Greater GE 0 0 - no min alpha will be enforced
passwordMinOtherChars Greater GE 0 0 - no min other char
passwordMaxRepeatedChars Less GE 0 0 - no max repeated char

Based on the rules defined above, a user's composite group policy is determined. To gain a better understanding of how a composite group policy is determined, consider some examples given in the table below:
Table 16. Determining the composite group policy

Group X password policy Group Y password policy Group Z password policy Composite group password policy

pwdMaxAge = 86400
pwdSafeMode = True
pwdMaxFailure = 5
ibm-pwdPolicy = True
ibm-pwdPolicyStarttime = 20060406200000

pwdMaxAge = 43200
pwdSafeMode = False
ibm-pwdPolicy = True
ibm-pwdPolicyStarttime = 20060306200000

pwdCheckSytax = 1
ibm-pwdPolicy = True
ibm-pwdPolicyStarttime = 20060506200000

pwdMaxAge = 43200
pwdSafeMod = True
pwdCheckSytax = 1
pwdMaxFailure = 5
ibm-pwdPolicy = True
ibm-pwdPolicyStarttime = 20060306200000

pwdMaxAge = 86400
ibm-pwdPolicy = True

pwdMaxAge = 43200
pwdSafeMode = True

pwdMaxAge = 0
ibm-pwdPolicy = True

pwdMaxAge = 86400
pwdSafeMode = False
ibm-pwdPolicy = True

Group Y's passwd policy is not used in calculating composite group policy, since its ibm-pwdPolicy is not defined and therefore it defaults to FALSE.

pwdMinLength = 10
passwordMinOtherChars = 4
passwordMinAlphaChars= 6
ibm-pwdPolicy = True

pwdMinLength = 12
ibm-pwdPolicy = True

pwdMinLength = 12
ibm-pwdPolicy = True

pwdMinLength = 10
passwordMinOtherChars = 4
passowrdMinAlphaChars = 6
ibm-pwdPolicy = True

pwdMinLength = 10
passwordMinOtherChars = 5
passwordMinAlphaChars = 3
ibm-pwdPolicy = True

pwdMinLength =10
passwordMinOtherChars = 5
passwordMinAlphaChars = 3
ibm-pwdPolicy = True

Evaluation of a user's Effective Password Policy

A user's effective password policy is evaluated only if the ibm-pwdPolicy attribute is set to TRUE in the global password policy entry. Other password policies, such as individual and group policy, can still be enabled when the global policy is disabled, but these policy rules will have no effect on the user.
The attribute ibm-pwdPolicyStartTime is set to the current system time when ibm-pwdPolicy is set to TRUE. This can be done even if the global password policy entry is set to FALSE. However, the ibm-pwdPolicyStartTime value will not be used for effective policy evaluation unless the global policy is enabled. Once the global policy is enabled, the value of this attribute will be selected from a user's individual, then group and then the global policy. Since ibm-pwdPolicyStartTime exists in every active password policy, the start time of an individual policy, if it exists, will always override any other policy start time as the start time of the user's effective password policy.
Given below is a set of examples that explain how a user's effective password policy is determined.
Table 17. Determining the effective password policy

Individual password policy Group password policy Global password policy Effective password policy

pwdMaxAge = 86400
ibm-pwdPolicy = True
pwdMinAge = 21600
pwdLockout = True
ibm-pwdPolicyStarttime = 20060406200000

pwdMaxAge =43200
ibm-pwdPolicy = True
pwdInHistory = 5
ibm-pwdPolicyStarttime = 20060306200000

ibm-pwdPolicy = True
pwdMinAge = 43200
pwdInHistory = 3
pwdCheckSyntax = 0
pwdMinLength = 0
pwdExpireWarning = 0
pwdGraceLoginLimit = 0
pwdLockoutDuration = 0
pwdMaxFailure =0
pwdFailureCountInterval=0
passwordMinAlphaChars=0
passwordMinOtherChars=0
passwordMaxRepeatedChars=0
passwordMinDiffChars=0
pwdLockout=False
pwdAllowUserChange=True
pwdMustChange=True
pwdSafeModify=False
ibm-pwdPolicyStarttime = 20060506200000

pwdMaxAge = 86400
ibm-pwdPolicy = True
pwdMinAge = 21600
pwdInHistory = 5
pwdCheckSyntax = 0
pwdMinLength = 0
pwdExpireWarning = 0
pwdGraceLoginLimit = 0
pwdLockoutDuration = 0
pwdMaxFailure =0
pwdFailureCountInterval=0
passwordMinAlphaChars=0
passwordMinOtherChars=0
passwordMaxRepeatedChars=0
passwordMinDiffChars=0
pwdLockout=True
pwdAllowUserChange=True
pwdMustChange=True
pwdSafeModify=False
ibm-pwdPolicyStarttime = 20060406200000

pwdMaxAge = 86400
ibm-pwdPolicy = True
pwdMinAge = 21600
pwdMinLength = 8
pwdLockout = True
ibm-pwdPolicyStarttime = 20060406200000

pwdMaxAge =43200
ibm-pwdPolicy = True
pwdInHistory = 5
ibm-pwdPolicyStarttime = 20060306200000

ibm-pwdPolicy = True
pwdMinAge = 0
pwdInHistory = 3
pwdCheckSyntax = 0
pwdMinLength = 10
pwdExpireWarning = 0
pwdGraceLonginLimit = 0
pwdLockoutDuration = 0
pwdMaxFailure =0
pwdFailureCountInterval=0
passwordMinAlphaChars=4
passwordMinOtherChars=4
passwordMaxRepeatedChars=0
passwordMinDiffChars=0
pwdLockout=False
pwdAllowUserChange=True
pwdMustChange=True
pwdSafeModify=False
ibm-pwdPolicyStarttime = 20060506200000

pwdMaxAge = 86400
ibm-pwdPolicy = True
pwdMinAge = 21600
pwdInHistory = 5
pwdCheckSyntax = 0
pwdMinLength = 8
pwdExpireWarning = 0
pwdGraceLoginLimit = 0
pwdLockoutDuration = 0
pwdMaxFailure =0
pwdFailureCountInterval=0
passwordMinAlphaChars=0
passwordMinOtherChars=0
passwordMaxRepeatedChars=0
passwordMinDiffChars=0
pwdLockout=True
pwdAllowUserChange=True
pwdMustChange=True
pwdSafeModify=False
ibm-pwdPolicyStarttime = 20060406200000

Password policy attributes

The password policy feature provides several operational attributes containing the password policy state information for a given directory entry. These attributes can be used to query for entries in a particular state (password has expired) and by an administrator to override certain policy conditions (unlock a locked account). See Appendix H. Password policy operational attributes

Summary of default settings

The following table shows default password policy settings for user passwords.
Table 18. User password policy settings

Web Administration Tool parameter Default setting

Password policy enabled: ibm-pwdPolicy false
Password encryption: ibm-slapdPwEncryption: AES256
Users must specify old password when changing the password: pwdSafeModify false
User must change password after reset: pwdMustChange true
Password expiration: pwdMaxAge 0
Number of grace logins after expiration: pwdGraceLoginLimit 0
Account is locked out after a specified number of consecutive failed bind attempts: pwdLockout false
Number of consecutive failed bind attempts before locking out the account: pwdMaxFailure 0
Minimum time between password changes: pwdMinAge 0
Amount of time before an account lockout expires or lockouts never expire: pwdLockoutDuration 0
Amount of time before an incorrect login expires or incorrect login is cleared only with correct password: pwdFailureCountInterval 0
Minimum number of passwords before reuse: pwdInHistory 0
Check password syntax: pwdCheckSyntax 0
Minimum length: pwdMinLength 0
Minimum number of alphabetic characters: passwordMinAlphaChars 0
Minimum number of numeric and special characters: passwordMinOtherChars 0
Maximum number of repeated characters: passwordMaxRepeatedChars 0
Minimum number of characters that must be different from the old password: passwordMinDiffChars 0

All users except the directory administrator, members of the administrative group and the master server DN are forced to comply with the configured user password policy. The passwords for the administrator, members of the administrative group and the master server DN never expire. The directory administrator, members of the administrative group and the master server DN have sufficient access control privileges to modify users' passwords and the user password policy. Global administration group members are subject to user password policy and have the authority to modify the user password policy settings.
The password policy for administrators, members of the administrative group and the master server DN is set in the configuration file.
Table 19. Administration Password Policy Settings

Administration password requirements Default setting

Password policy enabled: ibm-slapdConfigPwdPolicyOn false
Account is locked out after a specified number of consecutive failed bind attempts: pwdLockout true
Maximum number of incorrect logins until password lockout: pwdMaxFailure 10
Amount of time before an account lockout expires or lockouts never expire: pwdLockoutDuration 300
Amount of time before an incorrect login expires or incorrect login is cleared only with correct password: pwdFailureCountInterval 0
Minimum length: pwdMinLength 8
Minimum number of alphabetic characters: passwordMinAlphaChars 2
Minimum number of numeric and special characters: passwordMinOtherChars 2
Maximum number of repeated characters: passwordMaxRepeatedChars 2
Minimum number of characters that must be different from the old password: passwordMinDiffChars 2

Administration password policy is set to false by default. Turning on the administration password policy, enables the other attributes with the default settings.

Setting the administration password and lockout policy

The administration password policy is set using the command line only. The Web administration tool does not support administration password policy.
To turn on the administration password policy, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -p <port> -i <filename>
where <filename> contains:
dn: cn=pwdPolicy Admin,cn=Configuration
changetype: modify
replace: ibm-slapdConfigPwdPolicyOn
ibm-slapdConfigPwdPolicyOn: true
To enable the administration password policy and modify the default settings, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -p <port> -i <filename>
where <filename> contains:
dn: cn=pwdPolicy Admin,cn=Configuration
changetype: modify
replace: ibm-slapdConfigPwdPolicyOn
ibm-slapdConfigPwdPolicyOn: TRUE
-
replace: pwdlockout
pwdlockout: TRUE
#select TRUE to enable, FALSE to disable
-
replace:pwdmaxfailure
pwdmaxfailure: 10
-
replace:pwdlockoutduration
pwdlockoutduration: 300
-
replace:pwdfailurecountinterval
pwdfailurecountinterval: 0
-
replace:pwdminlength
pwdminlength: 8
-
replace:passwordminalphachars
passwordminalphachars: 2
-
replace:passwordminotherchars
passwordminotherchars: 2
-
replace:passwordmaxrepeatedchars
passwordmaxrepeatedchars: 2
-
replace:passwordmindiffchars
passwordmindiffchars: 2
Setting the password policy

To set the password policy, use one of the following procedures.

Using Web Administration:

If you have not done so already, click Server administration in the Web Administration navigation area and then click Manage password policies in the expanded list. On this panel, we can do the following:

Add a new password policy in the DIT.
Edit an existing password policy.
Create a copy of an existing password policy by providing a new name and location of the policy.
Delete an exiting password policy.

The global password policy cannot be deleted.
View the details of a selected password policy.

To add a password policy

To add a new password policy in the DIT, click the Add button or select Add from the Select Action list and then click Go on the Password policies table. This launches the Policy definition wizard in which the user can define a new password policy by providing a unique password policy name and the required attributes and their values.
Attribute selection

Attribute selection, Password policy settings 1, Password policy settings 2, and Password policy settings 3 panels make up the Policy definition wizard. Users can use these panels of the Policy definition wizard to add a new password policy, edit an existing password policy, and create a copy of an existing password policy.
While adding a new password policy or copying an existing password policy, user must provide a unique name for the password policy on the Attribute selection panel. Users can also provide values for the required attributes by selecting the attributes from the Attribute selection table. While editing an existing password policy, users are not allowed to modify the password policy name but can modify the values of the attributes of the selected password policy.

Based on the selection of the attributes from the Attribute selection table on the Attribute selection panel, user may not be required to traverse though all the panels of the Policy definition wizard while adding a new password policy or editing or copying an existing password policy.
On this panel, we can do the following:

Enter a unique password policy name in the Policy name field. For Add and Copy operations, users must provide a unique password policy name. In case of the Edit operation, the Policy name field is read-only.
Select the attributes from the table that you want to include in the password policy overriding the values of these attributes that is in the global password policy.

Password policy settings 1

The controls on the Password policy settings 1 panel are displayed based on the selection of the attributes on the Attribute selection panel. On this panel, we can do the following:

To enable the password policy, select the Enabled (ibm-pwdPolicy) check box. To disable the password policy, clear the Enabled (ibm-pwdPolicy) check box. The attribute ibm-pwdPolicy is associated with this control.
To allow user to change their password, select the User can change password (pwdAllowUserChange) check box.
To ensure that the user change the password after it is reset by the administrator, select the User must change password after reset (pwdMustChange) check box.
To ensure that the user specify the current password while setting a new password, select the User must specify current password while changing (pwdSafeModify) check box.
To set the start date and time of password policy, enter date and time in the fields under Password policy start time (ibm-pwdPolicyStartTime). To set date, users can use the calendar by clicking the calendar icon.

Only administrators and the members of local administrative group can set the start date and time of the password policy.
In this group, we can set the number of days after which the password expires. If you select Days, enter the number of days in the field. Otherwise, to ensure that password never expires, select Password never expires.
In this group, we can set the minimum age of the password. If you select Days, enter the number of days in the field after which the password can be changed after the last password change. Otherwise, select Password can be changed anytime.
In this group, we can set the number of days before the password expires at which to display password expiry warning status. If you select Days before expiration, enter a value in the field for the number of days before the password expires, in order to warn the user about password expiration. Otherwise, select Never warn.
In the Logins field, enter the number of grace login attempts allowed after the password has expired.

After you have finished, do one of the following:

Click Back to navigate to the Attribute selection panel.
Click Next to navigate to continue with configuring of password policy.
Click Cancel to discard all changes and navigate to the Manage password policies panel.
Click Finish to save all the changes and navigate to the Manage password policies panel.

Password policy settings 2

The Password policy settings 2 panel and the controls on the Password policy settings 2 panel are displayed based on the selection of the attributes on the Attribute selection panel. On this panel, we can do the following:

Set the maximum number of failed bind attempts allowed by a user before password locks out. If you select Attempts, enter a value for maximum number of failed bind attempts allowed before password lockout. To specify the maximum number of failed bind attempts allowed before password lockout as unlimited, select Unlimited.
Set the duration for which the password authentication will remain locked. To specify the duration, select and then enter a value for the duration in the field and select the unit from the combo box. Otherwise, select Infinite.
Set the duration after which failed bind attempts should be flushed. To specify the duration, select and then enter a value for the duration in the field and select the unit from the combo box. Otherwise, select Infinite.

Password policy settings 3

The Password policy settings 3 panel and the controls on the Password policy settings 3 panel are displayed based on the selection of the attributes on the Attribute selection panel. On this panel, we can do the following:

In the Minimum number of passwords before reuse (pwdInHistory) field, enter a value for the minimum number of password to be stored before reusing the old password.
Select a check password syntax item from the Check password syntax (pwdCheckSyntax) list to specify whether the syntax of password should be checked or not. The items available in the Check password syntax (pwdCheckSyntax) list are Do not check syntax, Check syntax (two-way encrypted only), and Check syntax.
In the Minimum length (pwdMinLength) field, enter a value for the minimum length of the password to be used.
In the Minimum number of alphabetic characters (passwordMinAlphaChars) field, enter a value for the minimum numbers of alphabetic characters that a password should contain.
In the Minimum number of numeric and special characters (passwordMinOtherChars) field, enter a value for the minimum numbers of numeric and special characters that a password should contain.
In the Maximum number of times a character can be used in password (passwordMaxRepeatedChars) field, enter a value for the maximum numbers of repeated characters that is allowed in a password.
In the Minimum number of characters different from previous password (passwordMinDiffChars) field, enter a value for the minimum numbers of characters in a new password that should be different from the previous password.

To edit a password policy

To edit an existing password policy, select the required row and click the Edit button or select Edit from the Select Action list and then click Go on the Password policies table. This launches the Policy definition wizard with the selected password policy. User can edit the selected password policy by modifying the required attributes and their values.
To create a copy of an existing password policy

To create a copy of an existing password policy, select the required row and click the Copy button or select Copy from the Select Action list and then click Go on the Password policies table. This launches the Policy definition wizard with the selected password policy. To copy, user must provide a new password policy name and the location of the policy and is allowed to make changes to the attribute values.
To delete a password policy

To delete an existing password policy, select the required row and click the Delete button or select Delete from the Select Action list and then click Go on the Password policies table.

The global password policy cannot be deleted.

Using the command line:

To enable the password policy, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -p <port> -k
dn: cn=pwdpolicy,cn=ibmpolicies
ibm-pwdpolicy:true
ibm-pwdGroupAndIndividualEnabled:true
To define group and individual password policies issue the following commands:
idsldapadd -D <adminDN> -w <adminPW>
dn:cn=grp1_pwd_policy,cn=ibmpolicies
objectclass: container
objectclass: pwdPolicy
objectclass: ibm-pwdPolicyExt
objectclass: top
cn:grp_pwd_policy
pwdAttribute: userPassword
pwdGraceLoginLimit: 1
pwdLockoutDuration: 30
pwdMaxFailure: 2
pwdFailureCountInterval: 5
pwdMaxAge: 999
pwdExpireWarning: 0
pwdMinLength: 8
pwdLockout: true
pwdAllowUserChange: true
pwdMustChange: false
ibm-pwdpolicy:true
idsldapadd -D <adminDN> -w <adminPW>
dn:cn=individual1_pwd_policy,cn=ibmpolicies
objectclass: container
objectclass: pwdPolicy
objectclass: ibm-pwdPolicyExt
objectclass: top
cn:grp_pwd_policy
pwdAttribute: userPassword
pwdGraceLoginLimit: 3
pwdLockoutDuration: 50
pwdMaxFailure: 3
pwdFailureCountInterval: 7
pwdMaxAge: 500
pwdExpireWarning: 0
pwdMinLength: 5
pwdLockout: true
pwdAllowUserChange: true
pwdMustChange: false
ibm-pwdpolicy:true
To associate the group and individual password policies with a group or a user, issue the following commands. For instance, to associate a group password policy with a group:
idsldapmodify -D <adminDN> -w <adminPW> -k
dn:cn=group1,o=sample
changetype:modify
add:ibm-pwdGroupPolicyDN
ibm-pwdGroupPolicyDN:cn=grp1_pwd_policy,cn=ibmpolicies
To associate an individual password policy with a user:
idsldapmodify -D <adminDN> -w <adminPW> -k
dn:cn=user1 ,o=sample
changetype:modify
add:ibm-pwdIndividualPolicyDN
ibm-pwdIndividualPolicyDN:cn= Individual1 _pwd_policy,cn=ibmpolicies
Unlocking administrative accounts

When an administrator unlocks an account by modifying a local admin group member or master server DN password, the account is unlocked immediately. However, the password modification for a local admin group member does not take effect until a dynamic configuration update request is made. The password modification for a master server DN password does not happen until the server is stopped and restarted. When an administrator changes a configuration file, the administrator must issue a dynamic update request immediately.
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename> contains:
dn: cn=admin1,cn=admingroup,cn=configuration
changetype: modify
replace:  ibm-slapdadminpw
ibm-slapdadminpw: newpassword123
When the administrator's account is locked, the only way to unlock the account is by logging on to the local console.

Password Guidelines

The following section provides details of the supported values of the IBM Tivoli Directory Server password attribute for user entries in the IBM Tivoli Directory Server, as well as the accounts used to administer the LDAP environment. It also provides guidelines of what characters to avoid to reduce confusion when attempting to run the Directory Server command line tools and C-API interfaces.
The IBM Tivoli Directory Server has two types of user accounts:

Administration accounts (LDAP Administrator (cn=root), members of the Administrator Group, or the master server DN) that are stored in the <instance_directory>/etc/ibmslapd.conf file.
User entries (iNetOrgPerson) that have a password attribute used with Directory Server C and Java™ (JNDI) APIs. These are the interfaces that applications, such as Tivoli Access Manager and WebSphere® use. While the Directory Server supports a wide variety of values for password entries, we need to review the application documentation to confirm what guidelines or restrictions apply.

Global administration group members are stored in the directory.

Details of the supported password values using the IBM Tivoli Directory Server are explained in the following sections.

The LDAP DB2® user is stored in the configuration file, but is not subject to password policy.

Passwords for user entries (InetOrgPerson)

In 6.0 and later releases, the following characters are supported for the userPassword attribute field to be stored in the Directory Server using the C and java APIs. Applications, such as Policy Director, WebSphere, and so on, that are using the Directory Server might have additional restrictions on password values. For details, review the product documentation for these specific products.

All upper and lower case English alpha and numeric characters.
All other ASCII single-byte characters are supported.
Double-byte characters are supported for languages specified in the IBM Tivoli Directory Server Version 6.1 Installation and Configuration Guide.
Passwords are case sensitive. (For example, if the password = TeSt, using a password of TEST or test fails. Only the exact case, TeSt, works.)

LDAP ibmslapd.conf users:

In 6.0 and later releases, the following characters are supported for passwords of users that are in the <instance_directory>/etc/ibmslapd.conf file.

All uppercase and lowercase English alpha and numeric characters are supported.
All other ASCII single-byte characters are supported.
Passwords are case sensitive. (For example, if the password = TeSt, using a password of TEST or test fails. Only the exact case, TeSt, works.)

Notes:

The defined users in the ibmslapd.conf file can include the following:

LDAP Administrator (cn=root)
Members of the Administrator Group
Master ID for Replication (cn=MASTER)
LDAP DB2 users for LDAP DB entry and change log databases (LDAPDB2)

The user LDAP password guidelines do not apply to these users.

Double-byte characters in the administrator passwords are not supported.

Using the Web Administration Tool to modify password attributes:

Using the Web Administration Tool, the following characters are supported for adding or modifying the password attribute field:

All uppercase and lowercase English alpha and numeric characters are supported.
All other ASCII single-byte characters are supported.
Passwords are case sensitive. (For example, if the password = TeSt, using a password of TEST or test fails. Only the exact case, TeSt, works.)

Notes:

Double-byte characters are not supported for the administrator password.
Double-byte characters are supported for user passwords.

Special characters

Avoid using the following characters because the operating shell might interpret these "special" characters:
	`
	'
	\
	" 	|
For example, using the 6.0 Web Administration Tool to assign a user password attribute to the value:
	"\"test\'
requires the following password from the command line to be used:
-w\"\\\"test\' 
Here is an example search:
idsldapsearch -b" " -sbase  -Dcn=newEntry,o=sample   -w\"\\\"test\' objectclass=*
This password works in the Web Administration Tool's Java application using the original password without the escape character. In the previous example, the Web Administration Tool bind password is the same as the one that was entered when assigning the password in the Web Administration Tool:
	"\"test\'
Setting Kerberos

The IBM Tivoli Directory server supports Kerberos Version 1.4 servers, such as the IBM Network Authentication Service, for AIX® servers and AIX 64-bit clients.

You must have the IBM Network Authentication Service client installed to use Kerberos authentication.
Under Network Authentication Service, a client (generally either a user or a service) sends a request for a ticket to the Key Distribution Center (KDC). The KDC creates a ticket-granting ticket (TGT) for the client, encrypts it using the client's password as the key, and sends the encrypted TGT back to the client. The client then attempts to decrypt the TGT, using its password. If the decryption is successful, the client retains the decrypted TGT, indicating proof of the client's identity.
The TGT, which expires at a specified time, permits the client to obtain additional tickets that give permission for specific services. The requesting and granting of these additional tickets does not require user intervention.
Network Authentication Service negotiates authenticated, optionally encrypted communications between two points on the network. It can enable applications to provide a layer of security that is not dependent on which side of a firewall either client is on. Because of this, Network Authentication Service can play a vital role in the security of your network.
You need to create an LDAP server servicename in the key distribution center (KDC) using the principal name ldap/<hostname>.<mylocation>.<mycompany>.com.

An environment variable "LDAP_KRB_SERVICE_NAME" is used to determine the case of the LDAP Kerberos service name. If the variable is set to 'LDAP' then the uppercase LDAP Kerberos service name is used. If the variable is not set, then the lowercase ldap is used. This environment variable is used by both the LDAP client and the server. By default this variable is not set. See the IBM Tivoli Directory Server version 6.1 Problem Determination Guide for more detailed information about the Kerberos service name change.
Network Authentication Service provides the following components:

Key distribution center

The KDC is a trusted server that has access to the private keys of all the principals in a realm. The KDC is composed of two parts: the Authentication Server (AS) and the Ticket Granting Server (TGS). The AS handles initial client authentication by issuing a TGT. The TGS issues service tickets that can be used by the client to authenticate to a service.

Administration server

The administration server provides administrative access to the Network Authentication Service database. This database contains the principals, keys, policies, and other administrative information for the realm. The administration server allows adding, modifying, deleting, and viewing principals and policies.

Password change service

The password change service allows users to change their passwords. The password change service is provided by the administration server.

Client programs

Client programs are provided to manipulate credentials (tickets), manipulate keytab files, change passwords, and perform other basic Network Authentication Service operations.

Application programming interfaces (APIs)

Libraries and header files are provided to allow the development of secure distributed applications. The APIs provided are described in the Application Development Reference.

Using Web Administration:

Under Server administration expand the Manage security properties category in the navigation area of the Web Administration Tool. If your server supports Kerberos, that is, it has the kerberos supported capabilities OID 1.3.18.0.2.32.30, select the Kerberos tab. If your server does not support Kerberos, this tab is not displayed.

Select the Enable Kerberos authentication check box to enable Kerberos authentication.

You must have a Kerberos client installed to use Kerberos authentication.
Select the Map Kerberos IDs to LDAP DNs check box to enable the directory administrator to use the existing set of ACL data with the Kerberos authentication method. See Identity mapping for Kerberos for more information.
Enter the Kerberos realm using the format hostName.domainName, for example, TEST.AUSTIN.IBM.COM. This format is case insensitive.
Enter the path and file name of the Kerberos keytab file. This file contains the private key of the LDAP server, as associated with its kerberos account. This file, and the SSL key database file, should be protected.
If you are logged in as the directory administrator, enter the Alternate administrator ID using the format ibm-kn=value@realm or ibm-KerberosName=value@realm for example, ibm-kn=root@TEST.AUSTIN.IBM.COM. This field cannot be edited by members of the administrative group.

This ID must be a valid ID in your Kerberos realm. This ID value is case insensitive.
When you are finished, click Apply to save your changes without exiting, or click OK to apply your changes and exit, or click Cancel to exit this panel without making any changes.

Using the command line:

To create a Kerberos entry, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename>contains:
dn: cn=Kerberos, cn=Configuration
cn: Kerberos
ibm-slapdKrbAdminDN: ibm-kn=admin@MYREALM.AUSTIN.IBM.COM
ibm-slapdKrbEnable: true
ibm-slapdKrbIdentityMap: true
ibm-slapdKrbKeyTab: /keytabs/mykeytab.keytab
ibm-slapdKrbRealm: MYREALM.AUSTIN.IBM.COM
objectclass: ibm-slapdKerberos
objectclass: ibm-slapdconfigEntry
objectclass: top
To modify a Kerberos entry, for example to change the keytab file, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename> contains:
dn: cn=Kerberos, cn=Configuration
changetype: modify
replace: ibm-slapdKrbKeyTab
ibm-slapdKrbKeyTab: /keytabs/mynewkeytab.keytab
Using Kerberos

Before we can use the command line for Kerberos authentication, we need to do a Kerberos initialization. Issue the following command:
kinit <kerberos_principlename>@<realm_name>
To use Kerberos authentication specify the -m option with the GSSAPI parameter on the idsldapadd and idsldapsearch commands. For example:
idsldapsearch  -V 3 -m GSSAPI -b <"cn=us"> objectclass=*
Identity mapping for Kerberos

Identity mapping enables the directory administrator to use the existing set of ACL data with the Kerberos authentication method. The ACL for the IBM Directory is based on the distinguished name (DN) assigned to the client connected to the directory server. The access rights are based on the permissions granted for that DN and the permissions for any groups containing that DN as a member. If the bind method for GSSAPI is used (that is, Kerberos is used for authenticating to the server), the DN is something like IBM-KN=your_principal@YOUR_REALM_NAME. This type of DN can be used as members of access groups or access IDs. You can also use the Kerberos Identity Mapping feature to grant access rights for this DN to an entry already in the directory.
For example, if there is an entry in the directory for Reginald Bender:
dn: cn=Reginald Bender, ou=internal users, o=ibm.com, c=US
objectclass: top
objectclass: person
objectclass: organizationalperson
cn: Reginald Bender
sn: Bender
aclentry: access-id:CN=THIS:critical:rwsc
aclentry: group:CN=ANYBODY:normal:rsc
userpassword: cL1eNt
The access rights for this entry allow anyone binding with the DN "cn=Reginald Bender, ou=internal users, o=ibm.com, c=US" to view critical data such as the password, but no one else.
If Reginald Bender used Kerberos to bind to the server, his DN could be something like IBM-KN=rbender@SW.REALM_1. If identity mapping is not enabled on the server, he is not allowed to view his own entry's password.
If identity mapping is enabled, he can view the password if this entry were changed to include:
dn: cn=Reginald Bender, ou=internal users, o=ibm.com, c=US...
objectclass: ibm-securityidentities
altsecurityidentities: Kerberos:rbender@SW.REALM_1
When Reginald Bender binds to the directory server, the server first searches the whole directory to determine if the directory is a KDC (Key Distribution Center) account registry. If it is not, the server searches the directory for any entry containing an altsecurityidentities attribute with a value matching the Kerberos user principal and realm. In this example, rbender is the user principal and SW.REALM_1 is the realm. This is the default for the Kerberos identity mapping. The bind fails if more than one entry has an attribute with this value. The mapping must be one-to-one. If the mapping is successful, Reginald Bender has all of the access rights for "cn=Reginald Bender, ou=internal users, o=ibm.com, c=US", including any access groups that has this as a member.
The IBM Tivoli Directory Server can be used to contain Kerberos account information (krbRealmName-V2 = <realm_name> and krbPrincipalName = <princ_name>@<realm_name>) to serve as the backing store for a KDC.
The server with Kerberos identity mapping enabled first searches the directory for entries with objectclass krbRealm-V2 and krbRealmName-V2 =<realm_name>, such as:
dn: krbRealmName-V2=SW.REALM_1, o=ibm.com, c=US
objectclass:  krbRealm-V2
krbReamlName-V2: SW.REALM_1
If no entries are found, the server uses the default Kerberos identity mapping described previously. If more than one entry is found, the bind fails.
However, if the directory contains the single entry:
dn: krbRealmName-V2=SW.REALM_1, ou=Group, o=ibm.com, c=US
objectclass:  krbRealm-V2
krbRealmName-V2: SW.REALM_1
krbPrincSubtree: ou=internal users,o=ibm.com, c=US
krbPrincSubtree: ou=external users,o=ibm.com, c=US
The server searches each subtree listed as a value of krbPrincSubtree for an entry with an attribute krbPrincipalName.
In this release, for identity mapping to work for Reginald Bender, you need to add two attributes to the "cn=Reginal Bender, ou=internal users, o=ibm.com, c=US" entry:
objectclass: extensibleObject
krbPrincipalName: rbender@SW.REALM_1
Depending on whether the directory is a KDC account registry, the final entry is:
dn: cn=Reginald Bender, ou=internal users, o=ibm.com, c=US...
objectclass: ibm-securityidentities
altsecurityidentities: Kerberos:rbender@SW.REALM_1...
or for a KDC account registry:
dn: cn=Reginald Bender, ou=internal users, o=ibm.com, c=US ...
objectclass: extensibleObject
krbPrincipalName: rbender@SW.REALM_1
In either case, the client is mapped to "cn=Reginald Bender, ou=internal users, o=ibm.com, c=US".
If a DN is not mapped because no entry is found, the mapping fails but the bind is still successful. However, if more than one DN is mapped, the bind fails.
Identity mapping enables the existing ACLs to work with Kerberos authentication. A client using Kerberos with a mapped identity has two distinct identities, both of which are evaluated in granting access.
Identity mapping has some costs. The internal searches at bind time impact performance and identity mapping requires additional setup to add the appropriate attributes to the entries to be mapped.
In this release, if default identity mapping is used, the administrator (either Kerberos or LDAP) must make sure that the data in the KDC and the data in the LDAP server are synchronized. If the data is not synchronized, incorrect results might be returned because of incorrect ACL evaluation.

The object class, such as KrbPrincipal and the attributes such as KrbPrincSubtree, KRbAliasedObjectName, and KrbHintAliases are used to define a IBM Directory as a Kerberos KDC. See the Kerberos documentation for more information.

Configuring the DIGEST-MD5 mechanism

DIGEST-MD5 is a SASL authentication mechanism. When a client uses Digest-MD5, the password is not transmitted in clear text and the protocol prevents replay attacks.
To configure the DIGEST-MD5 mechanism use one of the following methods.

Using Web Administration:

Under Server administration, expand the Manage security properties category in the navigation area of the Web Administration Tool, and then select the DIGEST-MD5 tab. The Digest-MD5 tab is displayed only if any one of the two conditions is satisfied:

The root DSE search returns the ibm-supportedCapabilities OID 1.3.18.0.2.32.79 for Digest-MD5.
The root DSE search returns DIGEST-MD5 as value of the supportedsaslmechanisms attribute.

The values of the controls in the Digest-MD5 tab are updated with the Digest-MD5 parameters from the entry "cn=Digest, cn=Configuration" in the configuration file when the tab is loaded.

Select the Enable Digest-MD5 check box to enable the Digest-MD5 mechanism.

When the Enable Digest-MD5 check box is selected, other controls related to Digest-MD5 parameters on this tab are enabled and modifications to these controls are allowed.
Under Server realm, we can use the preselected Default setting, which is the fully qualified host name of the server, or we can click Realm and type the name of the realm that you want to configure the server as.

If the ibm-slapdDigestRealm attribute in the configuration entry is set, the server uses that value instead of the default for the realm. In this case, the Realm button is preselected and the realm value is displayed in the field.This realm name is used by the client to determine which user name and password to use.
When using replication, you want to have all the servers configured with the same realm.
Under Username attribute, we can use the preselected Default setting, which is uid, or we can click Attribute and type the name of the attribute that you want the server to use to uniquely identify tthe user entry during DIGEST-MD5 SASL binds.

If the ibm-slapdDigestAttr attribute in the configuration entry is set, the server uses that value instead of the default for the Username attribute. In this case, the Attribute button is preselected and the attribute value is displayed in the field.
If you are logged in as the directory administrator, under Administrator username, type the administrator user name. This field cannot be edited by members of the administrative group. If the user name specified on a DIGEST-MD5 SASL bind matches this string, the user is the administrator.

The administrator user name is case sensitive.
When you are finished, click Apply to save your changes without exiting, or click OK to apply your changes and exit, or click Cancel to exit this panel without making any changes.

Using the command line:

To create the cn=Digest,cn=configuration entry, enter the command:
idsldapadd -D <adminDN> -w <adminpw> -i <filename>
where <filename> contains:
dn: cn=Digest,cn=configuration
cn: Digest
ibm-slapdDigestRealm: <realm name>
ibm-slapdDigestAttr: <uuid>
ibm-slapdDigestAdminUser: <Adminuser>
ibm-slapdDigestEnabled: true                   
objectclass:top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdDigest
To change the settings for DIGEST-MD5, issue the following command:
idsldapmodify -D <adminDN> -w <adminpw> -i <filename>
where <filename> contains:
dn: cn=Digest,cn=configuration
changetype: modify
replace: ibm-slapdDigestRealm
ibm-slapdDigestRealm: <newrealmname>
-
replace: ibm-slapdDigestAttr
ibm-slapdDigestAttr: <newattribute>
-
replace: ibm-slapdDigestAdminUser
ibm-slapdDigestAdminUser: <newAdminuser>
Pass-through authentication

Pass-through authentication (PTA) is a mechanism using which if a client attempts to bind to a directory server and if the user credential is not available locally, then the server attempts to verify the credential from another external directory server or a pass-through server on behalf of the client. The credential here refers to the userpassword attribute in TDS. To gain a better understanding of the pass-through authentication mechanism, consider an example given below:
Figure 1. Pass-through authentication

The pass-through server that holds the user credentials can be Active Directory or an LDAP directory other than TDS.
Let us consider two servers, say server X and server Y and a user entry cn=Tom Brown,o=sample stored on server Y. Now, if the user Tom Brown attempts to access server X to perform any operation it has to first bind to server X with its credential for authentication. Since the credential is not present on server X the user will be unable to bind to the server. However, using the pass-through authentication mechanism, server X can verify the credential by contacting server Y. After the credential is validated using server Y, server X presumes that the user is authenticated and hence returns success for the bind operation.
Alternatively, if a user is present on server X while its credential is available on server Y, again server X will contact server Y to verify the credential.
In the above cases it is assumed that the DN's on server Y and server X are identical. However, this may not be true always as the directory structure layout may differ on both the servers. This means that DN "cn=Tom Brown,o=sample" on server X may map to some other DN on server Y. In such situations it is possible that the entries on server X and server Y have some attribute whose value is unique for every entry, say for instance uid. Therefore, an attribute from the TDS server can be mapped to another attribute in the pass-through server. This information can then be used to query the pass-through server to fetch the required DN. A bind operation will then be performed for this DN to identify if the userpassword is correct.

Any configuration changes done for pass through authentication are not dynamic in nature and hence require a restart.
It is important to note that all the entries mentioned in the scenarios below must be within a configured subtree.

Let us consider a few scenarios pertaining to pass-through authentication:

Scenario 1: Attribute mapping is configured and entry is present locally

This is a scenario where an attribute in TDS will match some other attribute in pass-through server. It is not necessary that the name of an attribute is identical in both directories. For instance, uid=Tom456 in TDS may map to userPrincipalName=Tom456 in the pass-through server.
In this scenario, all the entries in TDS can be directly mapped to the entries in the pass-through server. Now, a search can be performed on the pass-through server to get the actual DN which will then be used to perform a bind operation to verify the user credential.
A sample entry in the configuration would look like:
ibm-slapdPtaAttrMapping : uid $ userPrincipalName 
uid in TDS is mapped to userPrincipalName in pass-through server.
Let us assume that the following entry exists on TDS:
dn: cn=Tom Brown,o=sample
sn: tests
uid: Tom456
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
Now, in case of a bind request with a DN "cn=Tom Brown,o=sample" , the pass-through server will be searched using "userPrincipalName=Tom456" search filter. If only one entry is returned then the DN of that entry is used and a bind operation is performed to verify the password. However, if uid is multi-valued in the "cn=Tom Brown,o=sample" entry, the bind operation will fail.
Let us suppose another situation where there is no unique attribute that can be mapped between directories. In such a situation introduce an auxiliary class and attach it to the entry where the mapping is required. For instance:
dn: cn=Tom Brown,o=sample
sn: test
uid: Tom456
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
objectclass: my-aux-class
uniqueValue: my_value
We can create a new auxiliary objectclass (my-aux-class) and associated attribute (uniqueValue) or use any existing objectclass and attribute. Finally, you set ibm-slapdPtaAttrMapping as:
ibm-slapdPtaAttrMapping : uniqueValue $ userPrincipalName
If the mapping attribute ibm-slapdPtaAttrMapping is not set to a unique attribute then it is possible that the pass-through server will return more than one entry or a false entry and the PTA interface will return a bind failure and log a message.

Scenario 2: Attribute mapping is configured, entry is present locally, and password migration is enabled

This is similar to scenario 1 except that after the result is sent to the client, the PTA interface will store the userpassword provided by the user during the bind operation in its local entry. Here, password will be stored in the TDS local directory after the first successful bind and will be present in the directory even after the server is down. Subsequent bind requests from this user will be served completely by local TDS directory and will not reach the pass-through server. The userpassword will be stored using the encryption scheme configured locally and adhere to the local password policy settings.

The password will also be replicated as per the replication configuration in TDS.
In this kind of scenario it is important to maintain consistency between the passwords of the pass-through server and the local TDS directory. Inconsistencies between the passwords available at the pass-through server and the local TDS directory can pose a potential security threat. A system administrator needs to ensure that the integrity of passwords at both the directories is maintained.

Scenario 3: The attribute mapping is not configured and the entry is not present locally.

In this kind of scenario after the bind request fails to locate the entry locally, the PTA interface will check if any pass-through server is configured to service the bind DN. If any pass-through server is configured, then using the bind DN and password supplied by the user, the bind request is send to the pass-through server. If the bind succeeds, the server returns success, otherwise it returns LDAP_INVALID_CREDENTIALS. In this scenario since the entry is not present locally, enabling password migration will not have any effect.

Scenario 4: Auxiliary object class is set for attribute-linking

In this scenario presume that there are two entries in TDS and one entry in the pass-through server for the user Tom as shown below.
Figure 2. Attribute linking

Now, uid=Tom456 can be easily mapped to userPrincipal=Tom456. However, there is no mapping between the second entry uid=Tom396 and userPrincipal=Tom456 since both the values differ even though they actually pertain to the same person. Therefore, if there is a bind request for uid=Tom396 which has its credentials on the pass-through server, the bind will fail. To solve this problem, add an auxiliary class ibm-ptaReferral. This will hold two MUST attributes ibm-PtaLinkAttribute and ibm-PtaLinkValue. This needs to be added to the entry that has no mapping in the pass-through server. Now, whenever there is a bind request for uid=Tom396, the PTA interface will first look if the ibm-ptaReferral objectclass is present. If it is present then it will fetch the details for the MUST attribute and frame the required search query. The entry will look like:
dn:  cn=Tom396,o=sample
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
uid:Tom396
sn: test
objectclass: ibm-ptaReferral
ibm-ptaLinkAttribute:  userPrincipalName
ibm-ptaLinkValue:  Tom456
Another case to be considered is when there is no mapping between TDS and the pass-through server but the administrator is aware of the DN that directly maps between both the directories. In such cases, ibm-PtaLinkAttribute must be set to "_DN_" and ibm-PtaLinkValue must be set to the actual DN of mapped entry. The entry will look like:
dn:  cn=Tom396,o=sample
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
uid:Tom396
sn: test
objectclass: ibm-ptaReferral
ibm-ptaLinkAttribute:  _DN_
ibm-ptaLinkValue:  cn=Tom1000,o=sample
By setting these values in the entry, the PTA interface takes the specified DN value and binds using the user supplied credentials. The result will be returned accordingly.
It is important to note that when computing the DN to be passed to the pass-through server, if it is found that an entry is set with ibm-ptaReferral auxiliary class, then the attribute mapping configured for the entry will be ignored.

In case you do not want pass-through authentication to be performed for a specific entry, set the ibm-ptaLinkAttribute to _DISABLE_.
To configure pass-through authentication, use one of the following methods:

Using Web Administration Tool

If you have not done so already, expand the Manage security properties category under Server administration in the navigation area of the Web Administration Tool and click the Pass-through authentication tab.
On this panel, we can:

Enable or disable pass-through authentication by selecting or clearing the Enable pass-through authentication check box.
Configure a pass-through entry for a subtree for pass-through authentication. Clicking Add displays the Configure subtree for pass-through authentication wizard that can be used for configuring a pass-through entry for a subtree for pass-through authentication.
Edit an existing pass-through entry of a subtree for pass-through authentication. Clicking Edit displays the Configure subtree for pass-through authentication wizard that can be used for modifying an existing pass-through entry of a subtree for pass-through authentication.
Delete an existing pass-through entry of a subtree configured for pass-through authentication. For this, select a subtree from the Subtrees configured for pass-through authentication table and click the Delete button.
View pass-through entry details of a configured subtree for pass-through authentication. For this, select a subtree from the Subtrees configured for pass-through authentication table, select View from the Select Action list, and click Go.
After you are finished, do one of the following:

Click OK to save changes and navigate to the "Introduction" panel.
Click Apply to save changes and to remain on this panel.
Click Cancel to discard changes made and navigate to the "Introduction" panel.

To configure a pass-through entry for a subtree for pass-through authentication follow the steps given below:

In the Pass-through authentication panel, click Add.
Next, on the Subtree settings panel we can do the following:

Enter a subtree DN in the field and click the Add button to add it to the list for storing subtree DN.
Enter multiple subtree DNs by clicking the Browse button and then selecting the required rows from the Browse entries panel.
Remove a subtree DN from the list for storing subtree DN by selecting the subtree DN and clicking the Remove button.
Specify the host name of the pass-through server in the Host name field. This is a required field.
Specify the port number of the pass-through server in the Port field. This is a required field.
Enable SSL encryption on the pass-through server by selecting the Enable SSL encryption check box.
Specify whether to save the user password on the local directory for all successful bind request processed through the pass-through server by selecting a value from the Migrate userpassword to this directory server combo box. The default value of this control is "False".
Specify the number of connections that is required for each pass-through server entry in the Number of connections to the pass-through server to maintain for Pass-through authentication field.
Specify a timeout value in the Pass-through authentication timeout field. The pass-through authentication interface will wait for result from socket till the timeout period before it returns the client request.

The attribute "ibm-slapdPtaResultTimeout" in the "cn=< pass-through server >, cn=Passthrough Authentication, cn=Configuration" entry is associated with this control.
Click Next.

To configure attribute mapping, do the following:

Select the Enable attribute mapping check box to enable attribute mapping. Selecting the Enable attribute mapping check box also enables other controls on the Attribute mapping panel.
In the Bind DN for pass-through server field, enter a bind DN for binding to the pass-through server.
In the Bind password for pass-through server field, enter a bind password for binding to the pass-through server.
In the Search base DN field, enter the search base DN of pass-through server where the entry will be searched, or click the Browse button to display Browse entries panel from which the user can select the existing DN from the pass-through server.
From the Attribute for this directory server combo box, select an attribute that should be mapped to an attribute in pass-through server.
From the Attribute for pass-through directory server combo box, select an attribute that should be mapped to the TDS attribute.
When you are finished, do one of the following:

Click Back to navigate to the Subtree settings panel.
Click Finish to save the changes and to navigate to the Pass-through authentication.
Click Cancel to discard the changes and to navigate to the Pass-through authentication.

Using command line

To enable PTA using the command line modify the configuration file of the directory server. Issue the following command to enable PTA:
ldapmodify -h <hosname> -p <port> -D <adminDN> -w <adminpwd> -f <ldif file> 

where the ldif file contains

dn: cn=Configuration 
ibm-slapdPtaEnabled: true 

dn: cn=Passthrough Server1, cn=Passthrough Authentication, cn=Configuration 
changetype: add 
cn: passthrough Server1 
ibm-slapdPtaURL: ldap://<hostname>:<port> 
ibm-slapdPtaSubtree: o=sample 
ibm-slapdPtaMigratePwd: false 
ibm-slapdPtaConnectionPoolSize: 6 
objectclass: top 
objectclass: ibm-slapdConfigEntry 
objectclass: ibm-slapdPta
The above command enables PTA, configures a subtree for pass-through authentication, specifies the hostname and port number for a pass through server, and specifies the number of connections that is required for each pass-through server entry. Also, the above command specifies that the user password must not be saved to the local directory for all successful bind requests.
To enable PTA and configure attribute mapping, issue the following command:
ldapmodify -h <hostname> -p <port> -D <adminDN> -w <adminpwd> -f <ldif file> 

where the ldif file contains

dn: cn=Configuration 
ibm-slapdPtaEnabled: true 

dn: cn=Passthrough Server1, cn=Passthrough Authentication, cn=Configuration 
changetype: add 
cn: passthrough Server1 
ibm-slapdPtaURL: ldap://<hostname>:<port> 
ibm-slapdPtaSubtree: o=sample 
ibm-slapdPtaMigratePwd: true 
ibm-slapdPtaAttrMapping: sn $ uid 
ibm-slapdPtaSearchBase: ou=austin,o=sample 
ibm-slapdPtaBindDN: <bind DN> 
ibm-slapdPtabindPW: <bind password> 
objectclass: top 
objectclass: ibm-slapdConfigEntry 
objectclass: ibm-slapdPta 
objectclass: ibm-slapdPtaExt
In the above example attribute mapping is configured and password migration is also enabled. Here, the attribute 'sn' in the directory server is mapped to the attribute 'uid' in the pass-through server.

Creating the administrative group

An administrative group provides the ability to provide 24 hour administrative capabilities without having to share a single ID and password among the administrators. Members of the administrative group have their own unique IDs and passwords. The administrative group member DNs must not match each other and they must also not match the IBM Tivoli Directory Server administrator's DN. Conversely, the IBM Tivoli Directory Server administrator DN must not match the DN of any administrative group member. This rule also applies to the Kerberos or Digest-MD5 IDs of the IBM Tivoli Directory Server administrator and the administrative group members. These DNs must not match any of the IBM Tivoli Directory Server's replication supplier DNs. This also means that IBM Tivoli Directory Server's replication supplier DNs must not match any of the administrative group member DNs or the IBM Tivoli Directory Server administrator DN.

The IBM Tivoli Directory Server's replication supplier DNs can match each other.
A root administrator must ensure that the archive log attributes are set in both cn=Audit,cn=Log Management,cn=Configuration and cn=Admin Audit,cn=Log Management ,cn=Configuration entries. By setting the archive attributes in the specific entries the root administrator eliminates the risk of a local administrator changing the default archive log settings that will in turn impact the archiving of audit logs. Without setting the archive log attributes in the audit entries, a local administrative group member may update the default log settings and impact the audit logs. Following are the archive log attributes:

ibm-slapdLogMaxArchives
ibm-slapdLogSizeThreshold
ibm-slapdLogArchivePath

Administrative Roles

While configuring an administrative group member, the root administrator has to explicitly assign an administrative role to the member. The roles that can be assigned to an administrative member are given below:

Audit administrator (AuditAdmin) - Members of the administrative group who are assigned the Audit Administrator role have unrestricted access to

Audit log
Admin Audit log
All other server logs
Audit log settings (cn=Audit, cn=Log Management, cn=Configuration)
Admin Audit log settings (cn=Admin Audit, cn=Log Management, cn=Configuration)
Default log management settings (cn=Default, cn=Log Management, cn=Configuration)

Directory Data Administrator (DirDataAdmin) - Members of the administrative group who are assigned this role will gain unrestricted access to all the entries in the RDBM back-end. However, for setting the password attribute of RDBM entries, members will still have to follow the usual password policy rules that are in effect.
No administrator (NoAdmin) - If the root administrator assigns No Administrator role to the configuration file users, then the users will cease to have any administrative privileges. By defining this role the root administrator can revoke all the administrative privileges of an administrative group member
Password administrator (PasswordAdmin) - Members of the administrative group who are assigned the Password Administrator role are authorized to unlock other user's accounts or change passwords of users in RDBM back-end. However they are not authorized to change passwords of Global Administrative Group Member accounts although they can unlock their accounts. Also, they are not restrained by password policy constraints that are set on the server. They can also add and delete the userpassword field of entries in RDBM back-end but are not allowed to make changes to users defined in the configuration file. The changes made by users who are assigned this role are not affected by ACLs. However, when users change their own password, the usual administration password policy rules will apply to the new password.
Replication administrator (ReplicationAdmin) - Members of the administrative group who are assigned the Replication Administrator role are authorized to update replication topology objects. The changes made by members with this role are not affected by ACLs or any other configuration file settings.
Schema administrator (SchemaAdmin) - Members of the administrative group who are assigned the Schema Administrator role have unrestricted access to schema back-end only.
Server configuration group member (ServerConfigGroupMember) - Members of the administrator group who are assigned the Server Configuration Group Member role have restricted update access to the configuration back-end. Users with this role will be unable to perform certain tasks. For instance, they will be unable to change root administrator and Admin Group credentials and add or remove members from the administrative group. Also, they will be unable to modify the DN, password, Kerberos ID, or Digest-MD5 ID of any administrative group member entry under cn=AdminGroup, cn=Configuration. They are also not authorized to modify their own DN,Kerberos ID, or Digest-MD5 ID. They are not authorized to add, delete or modify the administrative roles assigned to any of the administrative group members. However, users will be able to modify their own password. In addition, users with this role will be unable to view the password of any other administrative group member or the root administrator and they are not authorized to add, delete, or modify the audit log setting and admin audit log settings (the entire cn=Audit, cn=Log Management, cn=Configuration and cn=Admin Audit, cn=Log Management, cn=Configuration entries) or clear the audit log and admin audit log. However, they are allowed to modify default log settings (the cn=Default, cn=Log Management, cn=Configuration entry) and clear all other server logs. Also, users with this role will be unable to add or delete the cn=Kerberos, cn=Configuration or cn=Digest, cn=Configuration entries. However, they are allowed to search all attributes under these entries. The users will be able to modify all attributes under these entries except the Kerberos and Digest-MD5 root administrator bind attributes. They will be unable to search or modify the ibm-slapdAdminDN, ibm-slapdAdminGroupEnabled, or ibm-slapdAdminPW attributes under the cn=Configuration entry. The user can issue dynamic configuration updates.
Server start/stop administrator (ServerStartStopAdmin) - Members of the administrative group who are assigned the Server Start/Stop Administrator role are authorized to start or stop the server and the administrator daemon.

See Global administration group for information on how administrative rights are delegated for the database backend in a distributed directory environment.
The following table gives cross references of various extended operations that administrative group members are allowed to issue.
Table 20. Administrative roles authorized to issue various extended operations

Extended Operations Audit Admin Directory Data Admin Replication Admin Schema Admin Server Configuration Group Member Server Start/Stop Admin Password Admin No Admin

Start TLS - Request to start Transport Layer Security. OID = 1.3.6.1.4.1.1466.20037 Yes Yes Yes Yes Yes Yes Yes Yes
Event Registration - Request registration for events in SecureWay® V3.2 Event support. OID = 1.3.18.0.2.12.1 Yes Yes Yes Yes Yes Yes Yes Yes
Event Unregister - Request Unregister for events that were registered for using an Event Registration Request. OID = 1.3.18.0.2.12.3 Yes Yes Yes Yes Yes Yes Yes Yes
Begin Transaction - Begin a Transactional context for SecureWay V3.2. OID = 1.3.18.0.2.12.5 Yes Yes Yes Yes Yes Yes Yes Yes
End Transaction - End Transactional context (commit/rollback) for SecureWay V3.2. OID = 1.3.18.0.2.12.6 Yes Yes Yes Yes Yes Yes Yes Yes
Enable and Disable Tracing Dynamically. OID = = 1.3.18.0.2.32.14 No Yes No No No No No No
Cascading Control Replication - This operation performs the requested action on the server it is issued to and cascades the call to all consumers beneath it in the replication topology. OID = 1.3.18.0.2.12.15 No Yes Yes No No No No No
Control Replication - This operation is used to force immediate replication, suspend replication, or resume replication by a supplier. This operation is allowed only when the client has update authority to the replication agreement. OID = 1.3.18.0.2.12.16 No Yes Yes No No No No No
Control Replication Queue - This operation marks items as "already replicated" for a specified agreement. This operation is allowed only when the client has update authority to the replication agreement. OID = 1.3.18.0.2.12.17 No Yes Yes No No No No No
Quiesce or Unquiesce Server - This operation puts the subtree into a state where it does not accept client updates (or terminates this state), except for updates from clients authenticated as directory administrators where the Server Administration control is present. OID = 1.3.18.0.2.12.19 No Yes Yes No No No No No
Clear Log Request - Request to Clear log file. OID = 1.3.18.0.2.12.20 Yes No No No Yes No No No
Get Lines Request - Request to get lines from a log file. OID = 1.3.18.0.2.12.22 Yes Yes Yes Yes Yes Yes Yes No
Number of Lines Request - Request number of lines in a log file. OID = 1.3.18.0.2.12.24 Yes Yes Yes Yes Yes Yes Yes No
Start, Stop Server Request - Request to start, stop or restart an LDAP server. OID = 1.3.18.0.2.12.26 No No No No No Yes No No
Update Configuration Request - Request to update server configuration for IBM Directory Server. OID = 1.3.18.0.2.12.28 Yes No Yes No Yes No No No
DN Normalization Request - Request to normalize a DN or a sequence of DNs. OID = 1.3.18.0.2.12.30 Yes Yes Yes Yes Yes Yes Yes Yes
Kill Connection Request - Request to kill connections on the server. The request can be to kill all connections or kill connections by bound DN, IP, or a bound DN from a particular IP. OID = 1.3.18.0.2.12.35 No Yes No No No No No No
User Type Request - Request to get the User Type of the bound user. OID = 1.3.18.0.2.12.37 Yes Yes Yes Yes Yes Yes Yes Yes
Control Server Tracing - Activate or deactivate tracing in the IBM Directory Server. OID = 1.3.18.0.2.12.40 No Yes No No No No No No
Group Evaluation - This operation is used in a distributed directory environment to determine all groups that a particular DN is a member of. OID = 1.3.18.0.2.12.50 No Yes No No No No No No
Topology Replication - This operation is used to replicate the objects that define the topology of a particular replication context, such as the replication agreements for that context. Any user with update rights to the Replication Group Entry of the context is allowed to issue this extended operation. OID = 1.3.18.0.2.12.54 No Yes Yes No No No No No
Event Update - Request to reinitialize the event notification configuration (this operation can only be initiated by the server, not any user). OID = 1.3.18.0.2.12.31 No No No No No No No No
Log Access Update - Request to reinitialize the log access plugin configuration (this operation can only be initiated by the server, not any user). OID = 1.3.18.0.2.12.32 No No No No No No No No
Unique Attributes - Request to get the duplicate values for an attribute. OID = 1.3.18.0.2.12.44 No Yes No No No No No No
Account Status - This operation is used to determine if an account is locked by password policy. OID = 1.3.18.0.2.12.58 No Yes No No No No No No
Locate Entry - This operation is used locate details of a given set of DN(s). OID = 1.3.18.0.2.12.71 No Yes No No No No No No
Proxy Resume Role - Request that a backend server's role is resumed. OID = 1.3.18.0.2.12.65 No Yes No No No No No No
Get Attributes Type - Request attributes types. OID = 1.3.18.0.2.12.46 No Yes No Yes No No No No

The following table gives cross references of various objects that different administrative group members are allowed to access.
Table 21. Permissions assigned to Administrative roles for accessing various objects

Audit Settings / Audit logs RDBM Backend Replication Objects Schema Backend Configuration Backend Proxy Backend Server Start/Stop
Read Write Read Write Read Write Read Write Read Write

Audit Administrator Yes Yes No** No No** No Yes No Yes No Note1 No
Directory Data Administrator No No Yes Yes Yes Yes Yes No Yes No Note1 No
Replication Administrator No No No** No** Yes Yes Yes No Yes No Note1 No
Schema Administrator No No No** No No** No Yes Yes Yes No Note1 No
Server Configuration Group Member Yes No No** No No** No Yes No Yes Yes* Note1 No
Server Start/Stop Administrator No No No** No No** No Yes No Yes No Note1 Yes
Password Administrator No No No** Yes** No** No Yes No Yes No Note1 No
No Administrator No No No** No No** No Yes No Yes No Note1 No

* - Server Configuration Group Member will have restricted update access to configuration backend.
** - For access to these objects the administrative roles give no special authority, but the user may still have access through normal ACL evaluation.
Note1 - Proxy will treat the admin group members having any administrative role as anonymous and will accordingly apply access rules.

Enabling and disabling the administrative group

You must be the IBM Tivoli Directory Server administrator to perform this operation.

In this task and the Manage administrative group tasks that follow, the operation buttons are disabled for members of the administrative group. Members of the administrative group can only view the Administrative group members table on the Manage administrative group panel.
Using Web Administration:

Expand the Server administration category in the navigation area. Click Manage administrative group.

To enable or disable the administrative group, click the check box next to Enable administrative group. If the box is checked, the administrative group is enabled.
Click OK.

If you disable the administrative group, any member who is logged in can continue administrative operations until that member is required to rebind. To stop any additional operations by already bound administrative group members, perform an unbind operation. See Managing server connections for more information.
Using the command line:

To perform the same operations using the command line, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename> contains:
dn: cn=Configuration
changetype: modify
replace: ibm-slapdAdminGroupEnabled
#specify TRUE to enable or FALSE to disable the administrative group
#TRUE has been preselected for you.
ibm-slapdAdminGroupEnabled: TRUE
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdTop
To update the settings dynamically, issue the following idsldapexop command:
idsldapexop -D <adminDN> -w <adminPW> -op readconfig -scope single 
cn=Configuration ibm-slapdAdminGroupEnabled 
         
Adding members to the administrative group

You must be the IBM Tivoli Directory Server administrator to perform this operation.
Using Web Administration:

To add a member to the administrative group, expand the Server administration category in the navigation area and click Manage administrative group. Next, on the Manage administrative group panel, click Add.
On the Add administrative group member panel:

Enter the member's administrator DN (this must be a valid DN syntax).
Enter the member's password. See Setting the administration password and lockout policy for information about administration password security restrictions.
Enter the member's password again to confirm it.
Optionally, enter the member's Digest-MD5 user name .
Optionally, enter the member's Kerberos ID. The Kerberos ID must be in either ibm-kn or ibm-KerberosName format. The values are case insensitive, for example, ibm-kn=root@TEST.AUSTIN.IBM.COM is equivalent to ibm-kn=ROOT@TEST.AUSTIN.IBM.COM.

This field is only available for the AIX and Windows® platforms. It is displayed only, if the kerberos supported capabilities OID (1.3.18.0.2.32.30) is found on the server.
Under the Administrative role section, select the Define roles for admin group member check box.
Select the available administrative roles from the Available administrative role box and click Add.
Click OK.

The Digest-MD5 user name is case sensitive.
Repeat this procedure for each member you want to add to the administrative group.
The member administrator DN, Digest-MD5 username, if specified, and Kerberos ID, if specified, are displayed in the Administrative group members list box.

Kerberos support is only available for the AIX and Windows platforms. The Kerberos ID column in the is displayed in the Administrative group members list box only, if the kerberos supported capabilities OID (1.3.18.0.2.32.30) is found on the server.
Using the command line:

To perform the same operations using the command line, issue the following command:
idsldapadd -D <adminDN> -w<adminPW> -i<filename>
where <filename> contains:
dn: cn=AdminGroup, cn=Configuration
cn: AdminGroup
objectclass: top
objectclass: container

dn: cn=admin1, cn=AdminGroup, cn=Configuration
cn: admin1
ibm-slapdAdminDN: <memberDN>
ibm-slapdAdminPW: <password>
ibm-slapdAdminRole: <role value>
ibm-slapdAdminRole: <role value2>
#ibm-slapdKrbAdminDN and ibm-slapdDigestAdminUser are optional attributes.
ibm-slapdKrbAdminDN: <KerberosID>
ibm-slapdDigestAdminUser: <DigestID>
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdAdminGroupMember
If you already have a member created in the administrative group, omit the first entry.
If multiple instances of ibm-slapdAdminRole attribute are specified with different role values, and one of these role values is NoAdmin, then all other role values will be ignored and an administrative group member having NoAdmin role will be added.

To update the settings dynamically, issue the following idsldapexop command:
idsldapexop -D <adminDN> -w <adminPW> -op readconfig -scope subtree 
         cn=AdminGroup,cn=Configuration
Modifying an administrative group member

You must be the IBM Tivoli Directory Server administrator to perform this operation.
Using Web Administration:

To modify an administrative group member's information, expand the Server administration category in the navigation area and click Manage administrative group. On the Manage administrative group panel:

Select the member whose information you want to modify.
Click Edit.
Change the member's administrator DN (this must be a valid DN syntax).
Change the member's password.
Enter the member's password again to confirm it.
Enter or change the member's Kerberos ID. The Kerberos ID must be in either ibm-kn or ibm-KerberosName format. The values are case insensitive, for example, ibm-kn=root@TEST.AUSTIN.IBM.COM is equivalent to ibm-kn=ROOT@TEST.AUSTIN.IBM.COM.

This field is only available for the AIX and Windows platforms. It is displayed only, if the kerberos supported capabilities OID(1.3.18.0.2.32.30) is found on the server.
Enter or change the member's Digest-MD5 user name . The Digest-MD5 user name is case sensitive.
Click OK.

Repeat this procedure for each member you want to modify in the administrative group.

If you are member of the administrative group, we can change your password using the User properties->Change password panel.
Using the command line:

To perform the same operations using the command line, issue the following command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename> contains:
dn: cn=admin1, cn=AdminGroup, cn=Configuration
cn: admin1
changetype: modify
replace: ibm-slapdAdminDN
ibm-slapdAdminDN: cn=<memberDN>
-
replace: ibm-slapdAdminPW
ibm-slapdAdminPW: <password>
-
replace: ibm-slapdKrbAdminDN
ibm-slapdKrbAdminDN: <KerberosID>
-
replace: ibm-slapdDigestAdminUser
ibm-slapdDigestAdminUser: <DigestID>

replace: ibm-slapdAdminRole
ibm-slapdAdminRole: <role value>
To update the settings dynamically, issue the following idsldapexop command:
idsldapexop -D <adminDN> -w <adminPW> -op readconfig -scope subtree 
         cn=AdminGroup,cn=Configuration
Removing a member from the administrative group

You must be the IBM Tivoli Directory Server administrator to perform this operation.
Using Server Administration:

To remove a member of the administrative group, on the Manage administrative group panel:

Select the member you want to remove.
Click Delete.
You are prompted to confirm the removal.
Click OK to delete the member or Cancel to return to the Manage administrative group panel without making any changes.

Repeat this procedure for each member you want to remove from the administrative group.
Using the command line:

To perform the same operations using the command line, issue the following command:
idsldapdelete -D <adminDN> -w<adminPW> -i<filename>
where <filename> contains:
#list additional DNs here, one per line:
cn=admin1, cn=AdminGroup, cn=Configuration
To remove multiple members, list the DNs. Each DN must be on a separate line.
To update the settings dynamically, issue the following idsldapexop command:
idsldapexop -D <adminDN> -w <adminPW> -op readconfig -scope subtree 
         cn=AdminGroup,cn=Configuration
[ Top of Page | Previous Page | Next Page | Contents | Index ]

Group X password policy	Group Y password policy	Group Z password policy	Composite group password policy
pwdMaxAge = 86400 pwdSafeMode = True pwdMaxFailure = 5 ibm-pwdPolicy = True ibm-pwdPolicyStarttime = 20060406200000	pwdMaxAge = 43200 pwdSafeMode = False ibm-pwdPolicy = True ibm-pwdPolicyStarttime = 20060306200000	pwdCheckSytax = 1 ibm-pwdPolicy = True ibm-pwdPolicyStarttime = 20060506200000	pwdMaxAge = 43200 pwdSafeMod = True pwdCheckSytax = 1 pwdMaxFailure = 5 ibm-pwdPolicy = True ibm-pwdPolicyStarttime = 20060306200000
pwdMaxAge = 86400 ibm-pwdPolicy = True	pwdMaxAge = 43200 pwdSafeMode = True	pwdMaxAge = 0 ibm-pwdPolicy = True	pwdMaxAge = 86400 pwdSafeMode = False ibm-pwdPolicy = True Group Y's passwd policy is not used in calculating composite group policy, since its ibm-pwdPolicy is not defined and therefore it defaults to FALSE.
pwdMinLength = 10 passwordMinOtherChars = 4 passwordMinAlphaChars= 6 ibm-pwdPolicy = True	pwdMinLength = 12 ibm-pwdPolicy = True		pwdMinLength = 12 ibm-pwdPolicy = True
pwdMinLength = 10 passwordMinOtherChars = 4 passowrdMinAlphaChars = 6 ibm-pwdPolicy = True		pwdMinLength = 10 passwordMinOtherChars = 5 passwordMinAlphaChars = 3 ibm-pwdPolicy = True	pwdMinLength =10 passwordMinOtherChars = 5 passwordMinAlphaChars = 3 ibm-pwdPolicy = True

Individual password policy	Group password policy	Global password policy	Effective password policy
pwdMaxAge = 86400 ibm-pwdPolicy = True pwdMinAge = 21600 pwdLockout = True ibm-pwdPolicyStarttime = 20060406200000	pwdMaxAge =43200 ibm-pwdPolicy = True pwdInHistory = 5 ibm-pwdPolicyStarttime = 20060306200000	ibm-pwdPolicy = True pwdMinAge = 43200 pwdInHistory = 3 pwdCheckSyntax = 0 pwdMinLength = 0 pwdExpireWarning = 0 pwdGraceLoginLimit = 0 pwdLockoutDuration = 0 pwdMaxFailure =0 pwdFailureCountInterval=0 passwordMinAlphaChars=0 passwordMinOtherChars=0 passwordMaxRepeatedChars=0 passwordMinDiffChars=0 pwdLockout=False pwdAllowUserChange=True pwdMustChange=True pwdSafeModify=False ibm-pwdPolicyStarttime = 20060506200000	pwdMaxAge = 86400 ibm-pwdPolicy = True pwdMinAge = 21600 pwdInHistory = 5 pwdCheckSyntax = 0 pwdMinLength = 0 pwdExpireWarning = 0 pwdGraceLoginLimit = 0 pwdLockoutDuration = 0 pwdMaxFailure =0 pwdFailureCountInterval=0 passwordMinAlphaChars=0 passwordMinOtherChars=0 passwordMaxRepeatedChars=0 passwordMinDiffChars=0 pwdLockout=True pwdAllowUserChange=True pwdMustChange=True pwdSafeModify=False ibm-pwdPolicyStarttime = 20060406200000
pwdMaxAge = 86400 ibm-pwdPolicy = True pwdMinAge = 21600 pwdMinLength = 8 pwdLockout = True ibm-pwdPolicyStarttime = 20060406200000	pwdMaxAge =43200 ibm-pwdPolicy = True pwdInHistory = 5 ibm-pwdPolicyStarttime = 20060306200000	ibm-pwdPolicy = True pwdMinAge = 0 pwdInHistory = 3 pwdCheckSyntax = 0 pwdMinLength = 10 pwdExpireWarning = 0 pwdGraceLonginLimit = 0 pwdLockoutDuration = 0 pwdMaxFailure =0 pwdFailureCountInterval=0 passwordMinAlphaChars=4 passwordMinOtherChars=4 passwordMaxRepeatedChars=0 passwordMinDiffChars=0 pwdLockout=False pwdAllowUserChange=True pwdMustChange=True pwdSafeModify=False ibm-pwdPolicyStarttime = 20060506200000	pwdMaxAge = 86400 ibm-pwdPolicy = True pwdMinAge = 21600 pwdInHistory = 5 pwdCheckSyntax = 0 pwdMinLength = 8 pwdExpireWarning = 0 pwdGraceLoginLimit = 0 pwdLockoutDuration = 0 pwdMaxFailure =0 pwdFailureCountInterval=0 passwordMinAlphaChars=0 passwordMinOtherChars=0 passwordMaxRepeatedChars=0 passwordMinDiffChars=0 pwdLockout=True pwdAllowUserChange=True pwdMustChange=True pwdSafeModify=False ibm-pwdPolicyStarttime = 20060406200000

Pwd Policy Attribute	More restrictive value	Valid values	Default values
pwdAttribute	N/A	userPassword	userPassword
pwdMinAge	Greater	Greater than or equal (GE) to 0	0 - no age limit
pwdMaxAge	Less	GE 0	0 - password does not expire
pwdInHistory	Greater	0 to 10	0 - no password history
pwdCheckSyntax	Greater	0, 1, 2 1 - if server not able to check the syntax, then accept password 2 - if server is not able to check the syntax, then reject the password	0
pwdMinLength	Greater	GE 0	0 - no minimum length
pwdExpireWarning	Greater	GE 0	0 - no warnings will be sent
pwdGraceLoginLimit	Less	GE 0	0 - no grace login
pwdLockout	True	True/False	False
pwdLockoutDuration	Greater	GE 0	0 - locked out until reset
pwdMaxFailure	Less	GE 0	0 - no failure count, no lockout
pwdFailureCountInterval	Greater	GE 0	0 - no count, reset by successfully authentication
pwdMustChange	True	True/False	True/False if cn=noPwdPolicy
pwdAllowUserChange	True	True/False	True
pwdSafeMode	True	True/False	False
Ibm-pwdPolicy	True	True/False	False
passwordMinAlphaChars	Greater	GE 0	0 - no min alpha will be enforced
passwordMinOtherChars	Greater	GE 0	0 - no min other char
passwordMaxRepeatedChars	Less	GE 0	0 - no max repeated char

Web Administration Tool parameter	Default setting
Password policy enabled: ibm-pwdPolicy	false
Password encryption: ibm-slapdPwEncryption:	AES256
Users must specify old password when changing the password: pwdSafeModify	false
User must change password after reset: pwdMustChange	true
Password expiration: pwdMaxAge	0
Number of grace logins after expiration: pwdGraceLoginLimit	0
Account is locked out after a specified number of consecutive failed bind attempts: pwdLockout	false
Number of consecutive failed bind attempts before locking out the account: pwdMaxFailure	0
Minimum time between password changes: pwdMinAge	0
Amount of time before an account lockout expires or lockouts never expire: pwdLockoutDuration	0
Amount of time before an incorrect login expires or incorrect login is cleared only with correct password: pwdFailureCountInterval	0
Minimum number of passwords before reuse: pwdInHistory	0
Check password syntax: pwdCheckSyntax	0
Minimum length: pwdMinLength	0
Minimum number of alphabetic characters: passwordMinAlphaChars	0
Minimum number of numeric and special characters: passwordMinOtherChars	0
Maximum number of repeated characters: passwordMaxRepeatedChars	0
Minimum number of characters that must be different from the old password: passwordMinDiffChars	0

Administration password requirements	Default setting
Password policy enabled: ibm-slapdConfigPwdPolicyOn	false
Account is locked out after a specified number of consecutive failed bind attempts: pwdLockout	true
Maximum number of incorrect logins until password lockout: pwdMaxFailure	10
Amount of time before an account lockout expires or lockouts never expire: pwdLockoutDuration	300
Amount of time before an incorrect login expires or incorrect login is cleared only with correct password: pwdFailureCountInterval	0
Minimum length: pwdMinLength	8
Minimum number of alphabetic characters: passwordMinAlphaChars	2
Minimum number of numeric and special characters: passwordMinOtherChars	2
Maximum number of repeated characters: passwordMaxRepeatedChars	2
Minimum number of characters that must be different from the old password: passwordMinDiffChars	2

Extended Operations	Audit Admin	Directory Data Admin	Replication Admin	Schema Admin	Server Configuration Group Member	Server Start/Stop Admin	Password Admin	No Admin
Start TLS - Request to start Transport Layer Security. OID = 1.3.6.1.4.1.1466.20037	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Event Registration - Request registration for events in SecureWay® V3.2 Event support. OID = 1.3.18.0.2.12.1	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Event Unregister - Request Unregister for events that were registered for using an Event Registration Request. OID = 1.3.18.0.2.12.3	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Begin Transaction - Begin a Transactional context for SecureWay V3.2. OID = 1.3.18.0.2.12.5	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
End Transaction - End Transactional context (commit/rollback) for SecureWay V3.2. OID = 1.3.18.0.2.12.6	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Enable and Disable Tracing Dynamically. OID = = 1.3.18.0.2.32.14	No	Yes	No	No	No	No	No	No
Cascading Control Replication - This operation performs the requested action on the server it is issued to and cascades the call to all consumers beneath it in the replication topology. OID = 1.3.18.0.2.12.15	No	Yes	Yes	No	No	No	No	No
Control Replication - This operation is used to force immediate replication, suspend replication, or resume replication by a supplier. This operation is allowed only when the client has update authority to the replication agreement. OID = 1.3.18.0.2.12.16	No	Yes	Yes	No	No	No	No	No
Control Replication Queue - This operation marks items as "already replicated" for a specified agreement. This operation is allowed only when the client has update authority to the replication agreement. OID = 1.3.18.0.2.12.17	No	Yes	Yes	No	No	No	No	No
Quiesce or Unquiesce Server - This operation puts the subtree into a state where it does not accept client updates (or terminates this state), except for updates from clients authenticated as directory administrators where the Server Administration control is present. OID = 1.3.18.0.2.12.19	No	Yes	Yes	No	No	No	No	No
Clear Log Request - Request to Clear log file. OID = 1.3.18.0.2.12.20	Yes	No	No	No	Yes	No	No	No
Get Lines Request - Request to get lines from a log file. OID = 1.3.18.0.2.12.22	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No
Number of Lines Request - Request number of lines in a log file. OID = 1.3.18.0.2.12.24	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No
Start, Stop Server Request - Request to start, stop or restart an LDAP server. OID = 1.3.18.0.2.12.26	No	No	No	No	No	Yes	No	No
Update Configuration Request - Request to update server configuration for IBM Directory Server. OID = 1.3.18.0.2.12.28	Yes	No	Yes	No	Yes	No	No	No
DN Normalization Request - Request to normalize a DN or a sequence of DNs. OID = 1.3.18.0.2.12.30	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Kill Connection Request - Request to kill connections on the server. The request can be to kill all connections or kill connections by bound DN, IP, or a bound DN from a particular IP. OID = 1.3.18.0.2.12.35	No	Yes	No	No	No	No	No	No
User Type Request - Request to get the User Type of the bound user. OID = 1.3.18.0.2.12.37	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Control Server Tracing - Activate or deactivate tracing in the IBM Directory Server. OID = 1.3.18.0.2.12.40	No	Yes	No	No	No	No	No	No
Group Evaluation - This operation is used in a distributed directory environment to determine all groups that a particular DN is a member of. OID = 1.3.18.0.2.12.50	No	Yes	No	No	No	No	No	No
Topology Replication - This operation is used to replicate the objects that define the topology of a particular replication context, such as the replication agreements for that context. Any user with update rights to the Replication Group Entry of the context is allowed to issue this extended operation. OID = 1.3.18.0.2.12.54	No	Yes	Yes	No	No	No	No	No
Event Update - Request to reinitialize the event notification configuration (this operation can only be initiated by the server, not any user). OID = 1.3.18.0.2.12.31	No	No	No	No	No	No	No	No
Log Access Update - Request to reinitialize the log access plugin configuration (this operation can only be initiated by the server, not any user). OID = 1.3.18.0.2.12.32	No	No	No	No	No	No	No	No
Unique Attributes - Request to get the duplicate values for an attribute. OID = 1.3.18.0.2.12.44	No	Yes	No	No	No	No	No	No
Account Status - This operation is used to determine if an account is locked by password policy. OID = 1.3.18.0.2.12.58	No	Yes	No	No	No	No	No	No
Locate Entry - This operation is used locate details of a given set of DN(s). OID = 1.3.18.0.2.12.71	No	Yes	No	No	No	No	No	No
Proxy Resume Role - Request that a backend server's role is resumed. OID = 1.3.18.0.2.12.65	No	Yes	No	No	No	No	No	No
Get Attributes Type - Request attributes types. OID = 1.3.18.0.2.12.46	No	Yes	No	Yes	No	No	No	No

	Audit Settings / Audit logs		RDBM Backend		Replication Objects		Schema Backend		Configuration Backend		Proxy Backend	Server Start/Stop
	Read	Write	Read	Write	Read	Write	Read	Write	Read	Write
Audit Administrator	Yes	Yes	No**	No	No**	No	Yes	No	Yes	No	Note1	No
Directory Data Administrator	No	No	Yes	Yes	Yes	Yes	Yes	No	Yes	No	Note1	No
Replication Administrator	No	No	No**	No**	Yes	Yes	Yes	No	Yes	No	Note1	No
Schema Administrator	No	No	No**	No	No**	No	Yes	Yes	Yes	No	Note1	No
Server Configuration Group Member	Yes	No	No**	No	No**	No	Yes	No	Yes	Yes*	Note1	No
Server Start/Stop Administrator	No	No	No**	No	No**	No	Yes	No	Yes	No	Note1	Yes
Password Administrator	No	No	No**	Yes**	No**	No	Yes	No	Yes	No	Note1	No
No Administrator	No	No	No**	No	No**	No	Yes	No	Yes	No	Note1	No