Securing the directory
This chapter mainly deals with making your directory server secure at different levels from low to high, depending upon the requirements. It describes various security features provided by the IBM Tivoli Directory Server. It describes configuring the directory for using those security features. A brief description of certificate management using the gsk7ikm key management utility is also provided.
15.1 Directory security
Security is very important in the networked world of computers, and that is equally true for directories as well. Directories are likely to contain sensitive information that needs to be protected from unauthorized access and modification. When sending data over the wire, internally or externally, sensitive information may also need to be protected against eavesdropping and modification during transportation. There is a need to know who is requesting the information and who is sending it.
The IBM Tivoli Directory Server has the following built-in features for enhanced security:
•Authentication: Ensures that the user is who he/she claims to be. It is implemented using SASL/CRAM-MD5 mechanism and certificates using SASL/SSL.
•Password Policy Enforcement: Set of rules that controls how passwords are used and administered.
•Password Encryption: Protects passwords stored in the directory from unauthorized access by encrypting it using different encryption mechanisms.
•SSL/TLS Support: Ensures tamper proof data transfer over the network.
•Protection against DOS attacks: Ensures the Directory Server remains functional under deliberate or unintended massive client requests, such as Denial of Service Attacks.
•Access Control: Ensures that the users have proper access to directory objects, before returning the required information and hence provides confidentiality.
Now let us see the above points in greater detail.
15.2 Authentication
In an LDAPv3 implementation, the client must authenticate itself to the directory service before accessing any data in the directory, otherwise access is denied. The access denial is mainly achieved by either not providing the client what it requires or by throwing an appropriate error to the client.IBM Tivoli Directory Server supports the following types of authentications that are presented next.
15.2.1 Anonymous authentication
Anonymous authentication is useful for read-only access of directory data where that data is not sensitive, such as peoples’ e-mail addresses or office numbers. Essentially, that data can be made accessible to anyone. To request anonymous authentication, simple authentication is performed, against the directory server, with a distinguished name (DN) that is empty.
For example, to do an ldapsearch with anonymous binding, that is, do not include the -D (bind DN) and -w (password) options.
ldapsearch -b <basedn> -s <scope> <filter>
 
Note: There is no way to log into the Web Administration Tool anonymously. You have to provide a user name and a password that exists in the directory or you can log in as the directory administrator.
Here is an instance of the root DSE search with an anonymous authentication:
C:>ldapsearch -s base objectclass=* | grep -i config
ibm-slapdisconfigurationmode=FALSE
Now let us try fetching some data from the LDAP server which requires access:
C:>ldapsearch -s base -D <adminDN> -w <adminPW> -b o=ibm,c=us objectclass=* aclentry
o=IBM,c=US
aclentry=access-id:CN=USER1,O=IBM,C=US:object:ad:normal:r
C:>ldapsearch -s base -b o=ibm,c=us objectclass=* aclentry
C:>
You must have noticed the difference; if you do not have the proper access, the data will not be shown to you.
15.2.2 Basic authentication
Basic authentication provides authentication facilities with the DN and password transmitted over the network in clear text. Use of clear text passwords is not recommended over open networks when there is no authentication or encryption being performed by a lower layer, such as SSL (described in one of the forthcoming sections). Access (read or write) to directory data is granted based on DNs contained in the access control list of the object and/or attributes in the access request. The following is an example of searching the directory using basic authentication:
ldapsearch -D cn=root -w root -b <basedn> -s <scope> <filter>
In the above query we are assuming that the directory admin DN would be “cn=root” and the admin Password would be “root”.
The above search was with regards the admin DN as the bind DN to the directory server. It is equally correct to have a bind DN which is not the admin DN but which has the necessary ACLs to access the desired data. Here is an example of authenticated access, using a user “cn=user1,o=ibm,c=us”:
ldapsearch -D “cn=user1,o=ibm,c=us” -w user1 -b <basedn> -s <scope> <filter>
For more information on ACLs, refer to Chapter 14, “Access control” on page 395.
15.2.3 Authentication using SASL
The Simple Authentication and Security Layer (SASL) is a framework for multiple authentication and encryption mechanisms for connection-oriented protocols. It has been added to LDAP Version 3 to overcome the authentication shortcomings of LDAP Version 2. For more information on SASL, please refer to:
Overview of SASL
SASL is a method for adding authentication support to connection based protocols. In SASL, connection protocols such as LDAP, IMAP, and so on are represented by profiles; each profile is considered a protocol extension that allows the protocol and SASL to work together. Among these are IMAP4, SMTP, POP3, and LDAP. Each protocol that intends to use SASL needs to be extended with a command to identify an authentication mechanism and to carry out an authentication exchange. LDAP Version 3 includes such a command: ldap_sasl_bind() (and ldap_sasl_bind_s()). Optionally, a security layer can be negotiated to encrypt the data after authentication and thus ensure confidentiality. The IBM Tivoli Directory Server supports SASL authentication using the CRAM-MD5 (Challenge Response Authentication Mechanism with Message Digest 5), DIGEST-MD5 mechanisms, which transmits message digests rather than the passwords themselves over the network.
 
Note: The SASL mechanisms supported by the IBM Tivoli Directory Server can be obtained by the following search command:
ldapsearch -s base -b ““ objectclass=* supportedsaslmechanisms
The key parameters that influence the security method used are:
•DN: This is the distinguished name of the entry a requester wants to bind as. This can be thought of as the user ID in a normal user ID and password authentication.
•Mechanism: This is the name of the security method that should be used. The IBM Tivoli Directory Server supports CRAM-MD5, DIGEST-MD5 and external mechanisms. There is also an anonymous mechanism available which enables authentication as the generic user anonymous. In LDAP, the most common mechanism used is SSL (or its successor TLS), which is provided as a so-called external mechanism.
•Credentials: This contains the arbitrary data that identifies the DN. The format and content of the parameter depend on the mechanism chosen. If it is, for example, the ANONYMOUS mechanism, it can be an arbitrary string or an e-mail address that identifies the user.
Through the SASL bind API function call (sometimes also referred to as certificate bind), LDAP client applications call the SASL protocol driver on the server, which, in turn, connects the authentication system named in the SASL mechanism to retrieve the required authentication information for the user. SASL can be seen as an intermediator between the authentication system and a protocol like LDAP.
There is no special configuration necessary on either side (client or server) to use SASL/CRAM-MD5 authentication. Applications simply request it by making the appropriate API call. Some minimum set up is required for the SASL/DIGEST-MD5 authentication mechanisms, which can be found in the IBM Tivoli Directory Server Version 5.2 Administration Guide, which can be found at:
 
Attention: If CRAM-MD5/DIGEST-MD5 authentication mechanisms are being used, then the userpassword cannot be stored encrypted using one-way hash algorithms like CRYPT or SHA. It is because these authentication mechanisms require the userpassword in clear text and passwords encrypted using one way hash algorithms cannot be retrieved in clear text. But two way hash algorithms like IMASK can be used for encrypting and storing the passwords.
In case of EXTERNAL mechanism, the client sends an initial response with an authorization identity. The server uses information, external to SASL, to determine whether the client is authorized to authenticate as the authorization identity. If the client is so authorized, the server indicates successful completion of the authentication exchange; otherwise the server indicates failure.
The system providing this external information may be SSL or TLS (or IPSec, but not used in IBM Tivoli Directory Server). SSL and TLS are mentioned later in this chapter.
15.2.4 Kerberos
The IBM Tivoli Directory server supports Kerberos Version 1.3 servers, such as the IBM Network Authentication Service, for AIX servers and AIX 64-bit clients. Use the version of Kerberos included with your operating system for AIX 32-bit clients, Windows NT and Windows 2000 clients.
 
Note: You must have a Kerberos 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.
 
Note: 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.
Network Authentication Service provides the following components:
Key distribution center
The Key Distribution Center (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:
•Authentication Server (AS)
•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.
For further information on setting of Kerberos for use with the Directory Server and other information, you may refer the IBM Tivoli Directory Server Version 5.2 Administration Guide, which can be found at:
15.3 Password policy enforcement
Password policy, if enforced judiciously, enhances directory server security by forcing the directory users to have newer and complex passwords which are difficult to guess and hence less prone to dictionary attacks, without causing much pain to the user.
15.3.1 Overview
Password Policy is a set of rules that controls how passwords are used and administered in IBM Tivoli Directory Server. The IBM Directory Server Password Policy is based on the IETF Password Policy Internet Draft. 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 attempts.
All users except the directory administrator and the members of the administrative group are forced to comply with this password policy. The passwords for the administrator and members of the administrative group never expire and the accounts are never locked. The directory administrator and members of the administrative group have sufficient access control privileges to modify users' passwords and the password policy.
Starting with V5.1 of the IBM Directory Server, there is a new Directory Entry created for Password Policy with the DN cn=pwdpolicy. This entry resides at the root of all servers and this same Password Policy entry is replicated to all servers in the replication topology (If at all the topology exists). Password Policy has two separate types of attributes, the Password Policy Entry Attributes and Password Policy operational attributes that are associated with entries which contain a user password.
The Password Policy Entry Attributes with their default values are as follows:
•pwdAttribute: This is the attribute, identifying all the attributes in the directory server, on which the password policy rules would apply. Till the latest release that is, ITDS 52, userPassword is the only attribute to whom the password policy rules apply. In the future releases it is planned to make this field editable and also multivalued, so that the Customers may select the attributes to whom the password policy rules may apply.
•ibm-pwdPolicy: This attribute identifies whether password policy is turned on for this system. By default, password policy is turned off. Hence this attribute has a value of “FALSE”. This attribute will hold a value “TRUE” when enabled.
•pwdMinAge: This attribute specifies the minimum period for which the userPassword for a specific user should be used. In other words, if you set the userPassword of entry “cn=user1,o=ibm,c=us” to user1 and you set pwdMinAge to 300 seconds, then cn=user1,o=ibm,c=us has to use this password for a minimum period of 300 seconds. cn=user1,o=ibm,c=us cannot change the password before 5 minutes from the time of setting/resetting the password. The default value for this attribute is 0, which means there is no minimum age imposed.
•pwdMaxAge: This attribute specifies the maximum period for which the userPassword for a specific user can be used, where after the password would expire. In other words, if you set the userPassword of entry “cn=user1,o=ibm,c=us” to user1 and you set pwdMaxAge to 6 days, then cn=user1,o=ibm,c=us can use this password for a maximum period of 6 days. If the password happens to expire the administrator can reset the password to a new value and give it to the affected user. The default value for this attribute is 0 days, which means the password does not expire. The expected setting from the GUI is for the number of days, whereas it is stored internally in terms of the number of seconds and is also displayed in terms of seconds when queried from the command line.
That clearly indicates that the password for a user has be used in the period between pwdMinAge and pwdMaxAge.
•pwdInHistory: This attribute gives the total number of passwords to be stored in the password history. The default for this attribute is 0, indicating no passwords are to be stored in the pwdHistory.
•pwdCheckSyntax: This attribute holds three values:
 – The default value 0, indicating the syntax checking will not be enforced.
 – A value of 1, indicating the syntax checking will be done only in case the passwords are not encrypted.
 – A value of 2, indicating the syntax checking would be done, irrespective of whether the passwords are encrypted or not.
•pwdMinLength: This attribute specifies the minimum length the password should have. That is, if this attribute has a value of 5, and if you set the password of “cn=user1,o=ibm,c=us” to user then the access using this password should not be allowed. The default for this attribute is 0, indicating no minimum length is imposed.
•pwdExpireWarning: This attribute specifies the period before the password expiry that a warning be sent to a user, that his password is about to expire in the pwdExpireWarning time. that is, if you set this attribute to 1 day, then if the password is about to expire in the next 24 hours, a warning would be sent to the user in that regard. The default value for this attribute is 0 days, meaning no warnings will be sent. The GUI expects the value for this attribute in terms of the number of days, whereas the value is stored in seconds and displayed in seconds when queried from the command line.
•pwdGraceLoginLimit: This attribute specifies the maximum number of times a user is allowed to login after the password has expired. that is, if you set this value to 3 then after the password has expired, the user would be allowed to login for maximum three times where after his account would be locked. The default value for this attribute is 0, indicating that authentication will fail if the password has expired.
•pwdLockout: This attribute specifies whether the password is to be locked in circumstances, where the password can be locked. For example, if a user attempts to login with a wrong password for more than the maximum allowed times then the password may be locked. However, if this attribute is set to “FALSE”, which happens to be the default setting, then the password may still be used for a successful authentication. In other words, no intervention would be required by the Administrator to reset the password. The user can login to his account irrespective of the number of failed attempts.
•pwdLockoutDuration: This attribute specifies the total duration for which a password may be locked. This is also an attribute running on the parallel lines of pwdLockout. In the sense that, suppose you set this attribute to 300 seconds. If an account gets locked, the same will get unlocked after 300 seconds, without the intervention by the Administrator. The default for this attribute is 0, indicating the password cannot be used to authenticate until reset by an administrator.
•pwdMaxFailure: This attribute specifies the total number of failed login attempts to be granted to a user. That is, if you set this attribute to 3, then after three unsuccessful attempts to login, the password would be locked out. The default value for this attribute is 0, indicating that the accounts will not be locked on any number of failed attempts to login, and the value of pwdLockout will be ignored.
•pwdFailureCountInterval: This attribute specifies the period to clear the number of failed login attempts. that is, If you set this attribute to a value of 300 seconds, the current number of failed login attempts would be set to 0 only after 5 minutes. However if this attribute has a value 0, which being the default setting, the failure counter is only reset by a successful authentication.
•pwdMustChange: This attribute specifies if a user is supposed to change his password when he logs in. A value of "TRUE", which is the default one, specifies that the users must change their passwords after administrator reset. If this is set to FALSE then the users might continue using the same password as was given by the Administrator.
•pwdAllowUserChange: This attribute specifies if a user is allowed to change his password. A default value of "TRUE" is set to this attribute, which specifies that the users are allowed to change their passwords. A value of “FALSE” to this attribute specifies not to allow the users to change their passwords.
•pwdSafeModify: This attribute specifies if the user is required to provide his/her old password when requesting for a password change. A default value of “FALSE” specifies that the user does not need to send their existing password when doing a modify. If set to “TRUE” the old password is required to change the password to a new value.
•passwordMinAlphaChars: This attribute specifies the total number of alphabets that are to appear in the password. A default value of 0, indicates that the minimum number of alphabetic characters required in the password is 0. that is, even passwords like “1234” should be acceptable.
•passwordMinOtherChars: This attribute specifies the total number of non-alphabets that are to appear in the password. A default value of 0, indicates that the minimum number of numeric and special characters required in the password is 0. That is even passwords like “abcd” should be acceptable.
•passwordMaxRepeatedChars: This attribute specifies the total number of repetitions of the characters allowed in a password. The default value of 0, indicates that repetition of characters is allowed to any extent. For example, aabb should be acceptable. Here there are 2 repetitions. If you were to set this attribute to >= 2 then also this password would have worked. However setting this attributes to 1 wouldn’t have worked.
•passwordMinDiffChars: This attribute specifies the total number of characters in a password that should differ from all the passwords existing in the password history. The default value of 0, indicates no limitation. For example, if you have the passwords abcd and efgh in the history, and you set the passwordMinDiffChars to 2. Now if you attempt to set a new password as abcf then this will not be allowed as the number of characters differing between abcf and abcd is 1 character. A minimum difference of 2 characters is expected.
In order to set/unset the password policy attributes, there are two ways. You can do these tasks using the webadmin or you may go through the command line. We will see both the options. In order to view the password policy attributes throughout the Webadmin:
•Connect to the LDAP server using the WebAdmin.
•Click Server Administration.
•Click the Manage security properties category.
•There are three links in the Main Area, which help you set/unset different attributes pertaining to password policy.
•Select the Password policy tab. Refer to Figure 15-1 on page 442 for the screen that is shown.
Figure 15-1 Set of attributes pertaining to Password policy
 – As seen in Figure 15-1, the attribute affected by the password policy rules is userPassword.
 – The current password encryption is set to imask. We will see more of this encryption settings in one of our subsequent sections.
 – Check box corresponding to the Password policy enabled is checked, which indicates that password policy is enabled for this server.This attribute corresponds to the ibm-pwdPolicy attribute.
 – Check box corresponding to the User can change password is checked, which indicates that the user is given access to change his password. This corresponds to the pwdAllowUserChange attribute.
 – Check box corresponding to the User must change password after reset is checked, which indicates the user is forced to change the password once reset by the administrator. This corresponds to the attribute pwdmustchange.
 – Check box corresponding to the User must send password when changing is unchecked, which indicates the user need not send his passwords while changing his password. This corresponds to the pwdSafeModify attributes.
 – Against Password expiration we have got a radio button to choose between Password never expires and Days. The setting here indicates a password expiration of 2 days. This setting corresponds to the pwdMaxAge attribute.
 – Against Expiration warning we have got a radio button to choose between Never warn and Days before expiration. The setting here specifies that a warning be sent to the user 1 day prior to the expiration. This corresponds to the pwdexpirewarning attribute.
 – The next field is Number of grace logins after expiration. The value against this field here signifies 2 grace logins after expiration. This corresponds to the attribute pwdgraceloginlimit.
•Select the Password lockout tab, and the screen in Figure 15-2 on page 444 is shown.
Figure 15-2 Set of attributes pertaining to Password lockout
 – On the top the Time between password changes is to be specified. This is currently set to 0. This corresponds to the attribute pwdMinAge.
 – The next field is a radio button for specifying the Maximum number of incorrect logins until password lockout. Here the setting is for a lockout after 2 failures. This corresponds to the pwdlockout attribute.
 – The next radio button is where we specify Duration of password lockouts. Here the setting is for 2 days. of lockout after a password expiry. This corresponds to the attribute pwdlockoutduration.
 – The next radio button is where we specify the Incorrect login expiration time. The settings here show that the incorrect logins are to be cleared only upon a successful authentication. This corresponds to the pwdfailurecountinterval.
•Select the Password validation tab, and the screen in Figure 15-3 on page 445 is shown.
Figure 15-3 Set of attributes pertaining to Password validation
 – On the top you specify the Minimum number of passwords before reuse. This is currently set to 3, indicating that we can’t use the same password again till we have used 3 other passwords. This corresponds to the pwdinhistory attribute.
 – Next we specify the value against Check password syntax. Here we have set the value to “Do not check syntax”, which indicates that syntax checking is not to be done while evaluation password policy rules. This corresponds to the pwdCheckSyntax attribute.
 – Next you specify the Minimum length of the password. This corresponds to the pwdMinLength attribute.
 – Next you specify the Minimum number of alphabetic characters. This corresponds to the passwordMinAlphaChars attribute.
 – Next you specify the Minimum number of numeric and special characters. This corresponds to the passwordMinOtherChars attribute.
 – Next you specify the Minimum number of repeated characters.This corresponds to the passwordMaxRepeatedChars attribute.
 – Next you specify the Minimum number of characters different from previous password. This corresponds to the passwordMinDiffChars attribute.
You can see the same attributes on the command line as follows:
D:>ldapsearch -D cn=root -w secret -b cn=pwdpolicy objectclass=*
cn=pwdpolicy
objectclass=container
objectclass=pwdPolicy
objectclass=ibm-pwdPolicyExt
objectclass=top
cn=pwdPolicy
pwdAttribute=userPassword
pwdCheckSyntax=0
pwdMinLength=0
passwordMinAlphaChars=0
passwordMinOtherChars=0
passwordMaxRepeatedChars=0
passwordMinDiffChars=0
pwdSafeModify=false
ibm-pwdpolicy=true
pwdlockout=true
pwdinhistory=3
pwdgraceloginlimit=2
pwdlockoutduration=172800
pwdmaxfailure=2
pwdallowuserchange=true
pwdmustchange=true
pwdexpirewarning=86400
pwdmaxage=172800
pwdminage=43
pwdfailurecountinterval=23
If you want to change any of the attributes through command line, just create an LDIF and use the ldapmodify command. Here is an example. Suppose you want to change the password min age to 86 from the 43 shown above. Create an LDIF with the following contents:
dn: cn=pwdpolicy
changetype: modify
replace: pwdminage
pwdminage: 86
Suppose you name the above LDIF as pwdPolicy.ldif. Execute the ldapmodify command as:
ldapmodify -D <admin dn> -w <admin pw> -f pwdPolicy.ldif
That will do the necessary changes for you.
The above attributes were generic attributes pertaining to Password policy, applicable to the directory server as a whole. There are a set of operational attributes as well, which are set individually for each entry. These cannot be modified through direct client utilities. The server is supposed to modify them as and when needed.
The Password Policy Operational Attributes, which apply to any entry which contains a userPassword attribute are as follows:
•pwdChangedTime: This attribute specifies the last time the entry's password was changed. Here is an example of how this attribute is returned for an entry “cn=user1,o=ibm,c=us”:
D:>ldapsearch -D cn=root -w secret -b cn=user1,o=ibm,c=us objectclass=* pwdChangedTime
cn=user1,o=ibm,c=us
pwdChangedTime=20040229231910.000000Z
This example shows that the password of cn=user1,o=ibm,c=us was modified on 29-02-2004 at 23:19:10 hours.
•pwdAccountLockedTime: This attribute holds the time that the user's account was locked. Here is an example of the same via the command line:
D:>ldapsearch -D cn=root -w secret -b cn=user1,o=ibm,c=us objectclass=* pwdAccountLockedTime
cn=user1,o=ibm,c=us
pwdAccountLockedTime=20040229232942.000000Z
This example shows that the account of cn=user1,o=ibm,c=us was locked on 29-02-04 at 23:29:04 hours.
Figure 15-4 on page 448 shows the screen you will see when you attempt to login when the relevant account is locked.
Figure 15-4 Account is locked
•pwdExpirationWarned: This attribute contains the time when the password expiration warning was first sent to the client. It will not show up any time in case the expiration warning was never sent. Here is an example of the expiration Warning message:
C:>ldapchangepwd -D cn=user1,o=ibm,c=us -w user1 -n user
ldap_simple_bind: Warning, time before expiration is 58034
changing password for entry cn=user1,o=ibm,c=us
The timestamp of the expiration warning sent, is stored in the same format as the timestamp for the other attributes, for example, as like pwdFailureTime.
•pwdFailureTime: This attribute holds the times of the consecutive authentication failures.
D:>ldapsearch -D cn=root -w secret -b cn=user2,o=ibm,c=us objectclass=* pwdFailureTime
cn=user2,o=ibm,c=us
pwdFailureTime=20040229235714.000000Z
This example shows that there has been only 1 login failure with regards user “cn=user2,o=ibm,c=us” and that was on 29-02-2004 at 23:57:14 hours.
•pwdHistory: This attribute holds a history of previously used passwords, the password portion of this attribute will be stored in the same encryption method as the userPassword is stored in. The passwords stored in this attribute will be compared to the new userPassword that the user has entered. Here is an example of looking up for pwdHistory:
D:>ldapsearch -D cn=root -w secret -b cn=user2,o=ibm,c=us objectclass=* userPassword pwdHistory
cn=user2,o=ibm,c=us
userPassword=user
pwdHistory=20040301032149Z#2.5.4.35#171#{iMASK}>198o13ooQvIR95sxNtCDkCRitZFPLyk8euKmCBz80pJNEN8SZQVNtbGOqUMoQm3S9p3xVv+VQJGV0ww2lx+lWPgDgAEIF1/SX98lvSFxiOj0XVNInK40DOyTO5FGJ2unPP1+bM5CPanKf6VEdOlg7W0NUzksFb4YwA<
pwdHistory=20040301032308Z#2.5.4.35#33#{SHA}oYgcBu7JbbmQHHu/5BxCo/COnLQ=t
The above example shows that there are two encrypted passwords for the user cn=user2,o=ibm,c=us in the password history. Out of these one has an encryption of imask and the other has an encryption of sha. To learn more on the encryption level, please refer the section on the Server Encryption.
•pwdGraceUseTime: This attribute holds the timestamps of grace login once a password has expired, and is used to enforce the number of times an expired password may be used. If the grace logins are used then the timestamps will be stored in the same format as shown in the earlier password policy attributes above. Here is an example of the same:
C:>ldapsearch -D cn=root -w secret -b cn=user2,o=ibm,c=us objectclass=* pwdGraceUseTime
cn=user2,o=ibm,c=us
pwdGraceUseTime=20040303033651.000000Z
pwdGraceUseTime=20040303033711.000000Z
The above example shows that the user cn=user2,o=ibm,c=us had used two grace logins.
•pwdReset: This attribute holds a flag to indicates if the password has been reset.
Here is an example of the same:
D:>ldapsearch -D cn=root -w secret -b cn=user1,o=ibm,c=us objectclass=* pwdReset
cn=user1,o=ibm,c=us
pwdReset=true
The above example shows that the password for the user cn=user1,o=ibm,c=us was reset by administrator. Here is what is shown, when the password of the user is not reset:
D:>ldapsearch -D cn=root -w secret -b cn=user3,o=ibm,c=us objectclass=* pwdReset
cn=user3,o=ibm,c=us
By means of enabling a setting in the directory server, it is possible to restrict the users from authenticating to the directory server when their password has been reset, unless they change their password. Figure 15-5 on page 450 shows the screenshot for password reset policy.
Figure 15-5 Policy pertaining to password reset
If the check box against “User must change password after reset” is checked and applied the users must change their password after the administrator has reset them or else clients are thrown back messages as shown in the following example:
D:>ldapsearch -D cn=user3,o=ibm,c=us -w user -b cn=user3,o=ibm,c=us objectclass=*
ldap_simple_bind: Error, Password must be changed after reset
ldap_search: DSA is unwilling to perform ---
Error, Password must be changed after reset
Implementation
The Password Policy entry cn=pwdpolicy is created at the first server startup, if the entry is currently not present and the suffix for this entry resides in the IBM Directory Server config file.
In order to use Password Policy the Administrator must set the ibm-pwdpolicy in the cn=pwdpolicy entry to TRUE either by using the Web Administration Tools or doing an ldapmodify to modify the attribute. A set of details for configuring Password Policy using Web administration tool and command line has already been discussed above. However, if any further details are needed, please feel free to check out the IBM Tivoli Directory Server version 5.2 Administration Guide at:
All users may view the Password Policy entry but only the Administrator can modify it, by default. ACL’s may be set to let other users modify the entry.The Password Policy operational attributes may be used in the filter when performing a search but these attributes will not be displayed unless distinctly specified in the search and the binding user has permission to search on them. Some examples of the same are already shown in the above explanations.
For most of the cn=pwdpolicy entry attributes, a value of zero indicates that this feature of the policy is not being used. All of the integer valued attributes must be set to 0 or a positive integer and all of the attributes must have logical values in respect to the other related attributes.
 
Note: If you try to set/reset an attribute which conflicts with the settings of the other password policy attributes, then the relevant updates will not be completed and an error message would be flashed to the user saying Error: Some of the changes could not be saved. This is the error message seen in the status bar of the WebAdmin.
Password policy replication
Replica servers, which contain the entries being affected by Password Policy but are read-only to the client, do not have the following operational attributes replicated from the Master Server: pwdFailureTime, pwdAccountLockedTime, pwdGraceUseTime and pwdExpirationWarned.
These Replica servers contain local copies of these operational attributes, but when the entry’s userPassword attribute is modified on the Master Server, these local attributes are cleared as they are on the Master.
The LDAPCHANGEPWD Command
This is a new client tool that users can use to modify their password easily. It always performs a safe modify of the user’s password in case the pwdSafeModify attribute is set to TRUE. The user must supply their DN, current password and new password. Further details on this tool can be seen in Chapter 10, “Client tools” on page 237.
15.4 Password encryption
Storing passwords in clear text in the backend has potential risks. Hence, IBM Tivoli Directory Server supports a function where the passwords can be encrypted before being stored in the directory. This prevents the passwords from being compromised via direct SQL queries, database file look-ups and unauthorized access. The directory administrator too is not authorized to see the passwords in clear text although he has the right to change the password of any user.
The directory server can be configured to encrypt the password using one-way hash algorithms or two way hash algorithms. One-way hash algorithms used by the directory server are:
•SHA-1 (Secure Hash Algorithm)
•crypt
Passwords encrypted using one way hashes can be used for password matching but cannot be decrypted, that is, the clear text version of the password cannot be retrieved by applications. During user login, the login password is encoded and compared with the stored version for matching verifications. Hence, these passwords cannot be used by applications which require a clear text version of the password for authentication purposes.
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 encoding or no encryption on user passwords. In this instance, the clear passwords stored in the directory are protected by the directory ACL mechanism. The two-way hash algorithm used by the directory server is imask.
A two-way masking option, imask, is provided to allow values of the userPassword attribute to be encoded in the directory and retrieved as part of an entry in the original clear format. 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.
After the server is configured for using a given encryption algorithm, all new passwords (for newly added users) or modified passwords (for existing users) are encrypted using the given algorithm and then stored in the directory. The name of the algorithm is tagged to the encoded password so that passwords encrypted using different algorithms can co-exist. If the encryption algorithm is changed, the existing passwords remain unaffected and continue to work.
Here are a set of examples demonstrating the impact of the encryption levels.
In case encryption was set to imask when cn=user2,o=ibm,c=us was created.
C:>ldapsearch -D cn=root -w secret -b cn=user2,o=ibm,c=us objectclass=* userPassword
cn=user2,o=ibm,c=us
userPassword=user
In case now the encryption is changed to sha:
C:>ldapsearch -D cn=root -w secret -b cn=user2,o=ibm,c=us objectclass=* userPassword
cn=user2,o=ibm,c=us
userPassword=user
In case now we create a user cn=user4,o=ibm,c=us:
C:>ldapsearch -D cn=root -w secret -b cn=user4,o=ibm,c=us objectclass=* userPassword
cn=user4,o=ibm,c=us
userPassword={SHA}Et6pb+wgWTVmq3VpLJlJWWgzrck=
In case we set the encryption to crypt:
C:>ldapsearch -D cn=root -w secret -b cn=user4,o=ibm,c=us objectclass=* userPassword
cn=user4,o=ibm,c=us
userPassword={SHA}Et6pb+wgWTVmq3VpLJlJWWgzrck=
Now suppose we create a new user cn=user5,o=ibm,c=us:
C:>ldapsearch -D cn=root -w secret -b cn=user5,o=ibm,c=us objectclass=* userPassword
cn=user5,o=ibm,c=us
userPassword={crypt}m6nQvPf1lTjqI
Now suppose we switch back to imask:
C:>ldapsearch -D cn=root -w secret -b cn=user5,o=ibm,c=us objectclass=* userPassword
cn=user5,o=ibm,c=us
userPassword={crypt}m6nQvPf1lTjqI
 
C:>ldapsearch -D cn=root -w secret -b cn=user4,o=ibm,c=us objectclass=* userPassword
cn=user4,o=ibm,c=us
userPassword={SHA}Et6pb+wgWTVmq3VpLJlJWWgzrck=
We believe the above examples clearly hint what the behavior of the encryption algorithm is. While adding a new entry, the password encryption prevalent at that instant of time will be applicable to the entry’s userPassword and that will be maintained even upon switching the encryption algorithm.
 
Note: To know the name of the encryption algorithm that was used to encrypt the password, take a dump of the directory data using db2ldif utility. The ldif file so created contains the encrypted password along with the name of the encryption algorithm tagged to it.
Using the Web Administration Tool/command line, the directory server can be configured for the following encryption options:
•None: No encryption. Passwords are stored in the clear text format.
•crypt: Passwords are encoded by the UNIX crypt encoding algorithm before they are stored in the directory.
•SHA-1: Passwords are encoded by the SHA-1 encoding algorithm before they are stored in the directory.
•imask: Passwords are encoded by the imask algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format. This is the default.
The screenshot shown in Figure 15-1 on page 442 shows the tab for changing the password through the Web Administration tool.
In addition to userPassword, values of the secretKey attribute are always "imask" encoded in the directory. Unlike userPassword, this encoding 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 always needs to be encoded in the directory and to retrieve the data in clear text format using the directory access control.
 
Note: When imask is used as the server password encryption method, only the first 46 characters of a password entered are effective. Any characters after the 46th character will be ignored and considered as matched. Similarly, if the UNIX crypt method is used, only the first eight characters will be effective. Also since the value of SecretKey is encrypted in the database using the imask encryption, the SecretKey values which are longer than 46 characters will not be maintained.
The attribute associated with directory password encryption in the config file is ibm-slapdPwEncryption. Its value can be dynamically updated (after changing using Web Administration Tool or command line ldapmodify) using the ldapexop command line tool.
Here is how ldapmodify is used to change the encryption algorithm:
C:>ldapmodify -D <admin DN> -w <admin PW>
dn: cn=Configuration
changetype: modify
replace: ibm-slapdPWEncryption
ibm-slapdPWEncryption: sha
That will change the encryption to sha. You can use a file instead of providing everything on the command line. Once you have done the above update you can ask the server to take into effect the above change dynamically, using the ldapexop tool. For more information on ldapmodify/ldapexop please refer to Chapter 10, “Client tools” on page 237.
 
Note: It is not feasible to create a new attribute which would accept values in a masked form as like userPassword. The masking of characters in the field of userPassword is not based on the encryption algorithm chose, but it is the way that attribute is internally designed.
15.5 SSL/TLS support
The IBM Tivoli Directory Server has the ability to protect LDAP access by encrypting data with either Secure Sockets Layer (SSL) security or Transport Layer Security (TLS) or both. When using SSL or TLS to secure LDAP communications with the IBM Directory, both server authentication and client authentication are supported. To use SSL or TLS you must have GSKit installed on your system.
15.5.1 Overview of TLS
The primary goal of the TLS(Transport Layer Security)Protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol.
TLS record protocol
It is the lower layer of TLS. It provides connection security with the following connection properties:
•Connection is private: It is ensured by using symmetric cryptography for data encryption (for example, DES, RC4, etc.). The keys for this encryption are uniquely generated per connection based on secrets negotiated by some other protocol like TLS Handshake protocol. It can be used without encryption also.
•Connection is reliable: Message transportation includes a message integrity check using a keyed MAC (Message Authentication Code). Secure hash functions (SHA or MD5)are used for MAC computations.
TLS handshake protocol
Allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. It ensures that the peer's identity can be authenticated using asymmetric, or public key cryptography (for example, RSA, DSS).
•The negotiation of a shared secret is secure: The negotiated secret key is unavailable to any eavesdropper.
•The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the communicating parties.
For more information on TLS protocol, please visit the following Web site:
 
Note: TLS is started by using the -Y option in the client tools.
TLS and SSL are not interoperable. Starting TLS over a SSL port gives operations error.
15.5.2 Overview of SSL
SSL is an industry-standard security protocol that uses symmetric-key and public-key cryptographic technology. Symmetric-key cryptography uses the same key to encrypt and decrypt messages. Public-key cryptography uses a pair of keys: a public key and a private key. Each server's public key is published, and the private key is kept secret. To send a secure message to the server, a client encrypts the message using the server's public key. When the server receives the message, it decrypts the message using its private key. Only the server can decrypt this message because the private key required to decrypt this message is available only with the server.
SSL provides three basic security services(the below steps are equally valid for TLS also):
•Mutual authentication: Mutual authentication is the process whereby the client and the server convince each other of (and prove) their identities. The client and server identities are encoded in public-key certificates. A public-key certificate contains the following components whereby the issuer, also known as a Certificate Authority (CA), is a trusted organization, such as RSA Data Security Inc. or Verisign Inc.:
 – Subject's distinguished name
 – Issuer's distinguished name
 – Subject's public key
 – Issuer's signature
 – Validity period
 – Serial number
Rather than mutual authentication, which provides for maximum security, many implementations only use server authentication.
•Message privacy: Message privacy is achieved through a combination of public-key and symmetric key encryption. All traffic between an SSL client and an SSL server is encrypted using a key and an encryption algorithm negotiated during session setup.
•Message integrity: The message integrity service ensures that SSL session traffic does not change while en route to its final destination. SSL uses a combination of public/private keys and hash functions to ensure message integrity.
If SSL is used by LDAP for secure communication, the SSL session is established first before the normal LDAP protocol conversation can start. The following events take place for establishing an SSL session:
1. The client and the server exchange hello messages to negotiate the encryption algorithm and hashing function (for message integrity) to be used for the SSL session.
2. The client and server exchange X.509 certificates to validate their identities (if client authentication is not requested, only the server sends its certificate). Certificates are verified by checking the correctness of format and validity dates and by verifying that the certificate bears the signature of a trusted Certificate Authority (CA).
3. The client randomly generates a set of keys that are used for encryption. The keys are encrypted using the server's public key and securely communicated to the server.
4. Encrypted communication can now start using the generated key for encryption and decryption.
For server authentication to function, the IBM Tivoli Directory server must have a digital certificate (based on the X.509 standard). This digital certificate is used to authenticate the IBM Tivoli Directory server to the client application(s). During the initial SSL handshake, the LDAP server supplies the client with its X.509 certificate. If the client validates the server's certificate, a secure, encrypted communication channel is established between the LDAP server and the client application.
If client and server authentication is to be used, both the LDAP server and the client application must have a digital certificate. The server's digital certificate is used to authenticate the LDAP server to the client application (for example, an application built with IBM's LDAP application development toolkit). Similarly, the client's digital certificate is used to authenticate the client to the LDAP server (in terms of SSL's strong authentication mechanism). During the initial SSL handshake, the LDAP server and the client exchange certificates for mutual validation. After the client validates the server's certificate and the server validates the client's certificate, a secure encrypted communication channel is established between the LDAP server and the client application.
15.5.3 SSL utilities
The graphical utility gsk7ikm (IBM Key Management GUI) is provided for IBM AIX, Windows NT, and a number of other IBM and non-IBM platforms to manage SSL X.509v3 certificate databases (also known as keyring files or keyring databases). Its use is required to configure and use Secure Sockets Layer (SSL). The gsk7ikm utility replaces other utilities, like ikeyman, used with earlier versions of IBM SSL support. With the IBM Tivoli Directory Server (and associated clients), both client and server keyring files are managed with gsk7ikm.
The gsk7ikm utility, together with the SSL libraries, form the IBM SSL toolkit known as GSKit (Global Security Kit). GSKit provides the SSL protocol functions as well as a set of Certificate Management Services (CMS) functions. These CMS functions provide access to the certificate database (the keyring file) as well as functions such as validating client certificates (including Certificate Revocation List processing). The current version is GSKit Version 7, which supports SSL Version 3.0, C/C++ for clients and servers and Java for clients.
Since strong encryption (as provided by SSL) is controlled by export and other regulations in the U.S. and other countries, different versions of GSKit exist for different countries. While the installable options differ among these versions, the user interface and configuration steps are generally the same as described in the following sections.
 
Note: Encryption technology is subject to government regulations in the U.S. and other countries. Such regulations have changed recently and may change in the future. Due to this, the SSL packaging and implementation may be different as the product rolls out or may change thereafter.
GSKIT installation
GSKit is an independent installable option required only when SSL security is to be used. GSKit might already be installed on your system if another application required it to be installed. GSKit is shipped with the IBM Tivoli Directory Server in the appropriate version for your country. Please check for and follow any installation instructions that came with the product. If you are using the ISMP for installing IBM Tivoli Directory Server, select GSKit component by checking it when asked. For native installation, you have to use the operating system provided commands(installp in AIX, pkgadd in Solaris, rpm in linux etc.) for installing GSKit.
gsk7ikm utility
This utility with its graphical user interface is used to manage certificates. The specific tasks you can perform with ikmgui include:
•Create a key pair and request a certificate from a CA.
•Receive a certificate into a keyring file.
•Change a keyring password.
•Show information about a key.
•Delete a key.
•Make a key the default key in the keyring file.
•Export a key.
•Import a key into the keyring file.
•Designate a key as a trusted root.
•Remove trusted root key designation.
To run gsk7ikm, you need to have the Java Development Toolkit (JDK version 1.4.1 is recommended) installed and the JAVA_HOME environment variable pointing to its root directory. Figure Figure 15-6 on page 460 shows the screen shot of GSKit when launched using the command gsk7ikm.
Figure 15-6 IBM Key Management tool
15.5.4 Configuring SSL security
To enable security with server authentication, you can follow one of the given steps:
•Create a certificate signed by a well-known certificate authority (CA): Create a public/private key pair and obtain and store a certificate from one of the predefined (well-known) Certificate Authorities. This procedure requires less setup because the keyring file is preconfigured with the CA root certificates required to identify the CAs from whom the certificate is issued.
•Create a self-signed certificate: The process of applying for and receiving a certificate from a CA can take two to three weeks. To enable SSL security until you receive the required CA root and server certificates, you can create a self-signed root certificate and store the certificate in the database and class files. To ensure maximum security for your site, you should only use a self-signed certificate for server authentication until you receive a CA-issued certificate.
Creating a certificate signed by a trusted certificate authority
Using a certificate that was signed by a well-known (trusted) certificate authority gives you the advantage that most SSL communication partners know and trust that CA, and they will, therefore, most likely (depending on their configuration) accept a new certificate. This is especially helpful when communicating with partners outside your organization and beyond your authority to change security options. The disadvantages are that it takes some time (a few days or weeks) to get an official certificate and the fact that it is not for free. Creating a certificate signed by a well-known CA involves the creation of a key database and a certificate request that is then sent to the CA. After returning the certificate from the CA, it needs to be stored in the key database. These steps are detailed below using the GUI of the gsk7ikm utility.
1. Create a key database(.kdb file) for the server:
a. Select New from the on Key Database File pull-down menu on the top of the main window (Figure 15-6 on page 460).
b. On the dialog window that pops up, select CMS key database file in the Key database type selection list and then type in the name and location of the key database file to be created. This file has an extension of .kdb, as, for example, in ldap_key.kdb. Then, click OK to close the dialog panel.
c. A new dialog pops up that requests your input for a password for the key database file, an optional expiration time, and whether or not the password is to be stashed to a file. Enter a password, an optional expiration time, and make sure that you check the check box next to Stash the password to a file? In case you are not stashing the password to a file, the password would be stored in the configuration file. Using a stashed password increases the level of secrecy. The server/applications would get to know the password by reading the stashed password file as and when needed. Consequently you need not mention the password in the communications with the server. Click OK to close this dialog. The password is then encrypted and stored in a file with the same name as database file but with an extension of .sth.
2. Create a certificate request.
a. Select New Certificate Request... from the Create pull-down menu in the main window. In the dialog window that shows up, you will have to fill in the following information for the request:
 • Key label (a clear, descriptive label for the certificate)
 • Key size (512 or 1024, depending on security requirements and country version of the ikmgui utility)
 • Common name
 • Organization and other pertinent information to identify the owner of the certificate
 • Full path of the file name for the certificate request file
b. Click OK to create the request. The .arm file so created contains the certificate request.
3. Send the certificate request, that is, the .arm file, to the certificate authority of your choice by mail or Web (follow their instructions, which can be found on their Web sites). (While you are waiting for the certificate authority to process and return your certificate, you can enable SSL security by creating, storing, and importing a self-signed certificate using the procedure described in the next section.) Once the certificate has been returned to you by the CA, you have to store it into the key database file.
4. Store the certificate into your database.
a. On the ikmgui main menu (Figure 15-6 on page 460), make sure that your key database file is open (check the filename in the Key database information portion of the window). If it is not open, choose Open... from the Key Database File pull-down menu and open your file.
b. Select Personal Certificates from the selection list in the lower Key database content portion of the window.
c. Click Receive... on the right of the window.
d. Supply the information about the file containing the signed certificate and click OK. This adds the certificate to the key database file. You will see the new certificate in the list under Personal Certificates.
5. A root certificate of the CA must be stored in the key database file. By default, root certificates of the most common CAs are already present in the file; so, you do not need to add them again. A trusted root is simply an X.509 certificate that has been signed by a trusted entity (for example, Verisign). You can see what root certificates there are by selecting Signer Certificates from the selection list in the Key database content portion of the main window. If your CA is not present in that list, obtain a root certificate from this CA and add it by clicking Add... on the right of the window.
Creating a self signed certificate
You can use the ikmgui utility to create a self-signed certificate to enable SSL sessions between clients and servers. The steps are essentially the same except that, in this case, you are the CA for the keys you will be creating, and you will be creating your own root certificate. The advantages of using this type of certificate is a quick start, it is free, and you have no dependencies on other organizations. The drawback, on the other hand, is that each client or server using this kind of certificate needs to have the new root certificate imported, which may impose some administrative burden.
1. Create server key database (.kdb file).
a. Click Key Database File (Figure 15-6 on page 460).
b. Click New, from that dropdown that appears in point a above.
c. On the dialog window that pops up, select CMS key database file in the Key database type selection list and then type in the name and location of the key database file to be created. This file has an extension of .kdb, as, for example, in ldap_key.kdb. Then, click OK to close the dialog panel.
d. A new dialog pops up that requests your input for a password for the key database file, an optional expiration time, and whether or not the password is to be stashed to a file. Enter a password, an optional expiration time, and make sure that you check the check box next to Stash the password to a file? otherwise, you have to enter the password manually in the configuration file of the directory server. Click OK to close this dialog. The password is then encrypted and stored in a file with the same name as the key database file but with an extension of .sth.
2. Create a self-signed certificate.
a. Select New Self-Signed Certificate... from the Create pull-down menu in the main window (Figure 15-6 on page 460). In the dialog window that shows up, you will have to fill in the following information:
 • Key label (a clear, descriptive label for the certificate)
 • Key Version (normally X.509 V3, unless you have reasons for other versions)
 • Key size (512 or 1024, depending upon security requirements and country version of the ikmgui utility)
 • Common name
 • Organization and other pertinent information to identify the owner of the certificate
 • Validity period in days
 
Note: The key label and the organization are mandatory fields. The rest are optional.
3. Click OK to create the request. The .arm file so created contains the certificate request.
4. From the certificate just created above, you need to extract the root certificate that is necessary for other communication partners (clients and/or servers) to recognize the newly created certificate. Here are the steps for exporting the root certificate:
a. Select the new certificate’s entry in the Personal Certificate list and click Extract Certificate at the bottom right on the main window.
b. Select Base64-encoded ASCII data from the Data type list and enter a file name (with a .arm extension) and a location (directory) for the new root certificate to be exported to. Then click OK to export the root certificate. (If you want to create a file for the JNDI SSLight client key class, you must select SSLight key database class as data type when creating a file with a .class extension.)
You have now created a file that holds your own root certificate. This must be imported to all communication partners that will connect to the server through SSL.
5. Use the following steps for importing the new root certificate into others’ key database (using ikmgui):
a. Make sure that the certificate extracted above, in the previous step, is made available to all the communication partners. You can transfer the file using ftp or a diskette or any other suitable media.
b. Invoke the ikmgui utility on the receiving system.
c. If not already done, create a key database file (see first step above for creating a self-signed certificate).
d. In the Key database content portion of the window, select Signer Certificates from the selection list and click Add... on the right.
e. Select Base64-encoded ASCII data from the Data type list and type the certificate file name and location into the appropriate fields. Then, click OK to import the certificate.
f. On the upcoming dialog, supply a label for this certificate and click OK.
The steps as described above need to be done on each machine that will communicate using this certificate with the machine from which the certificate was exported.
Each LDAP server should have its own certificate. Sharing certificates across multiple LDAP servers is not recommended. By using different certificates and private keys for each server, your security exposure is minimized should a keyring file for one of the servers be compromised.
Configuring the LDAP server to use SSL
After creating the key database files for the server, follow the steps given below for configuring the server to communicate over SSL:
1. Connect to the directory server using Web Administration Tool.
2. Click the Server administration tab and then select Manage security properties.
3. Click the Settings tab in the right pane. Select the type of secure connection and the type of authentication method you want.
4. Next click the Key database tab and provide the absolute path of your key database (.kdb) file.
5. If you have not stashed your password while creating the key database, you need to provide the password here.
6. From the Encryption tab, select the encryption algorithm. Multiple selections are allowed. If you select multiple encryption methods, the highest level of encryption is used by default; however, clients using the selected lower encryption levels still have access to the server.
7. If the Federal Information Processing Standards (FIPS) mode enablement feature is supported on your server, the Use FIPS certified implementation check box appears under the Implementation tab. If this check box is selected, the ICC library will be used for encryption. If you deselect the check box, a non-FIPS certified library will be used for encryption.
8. Restart the server for the changes to take effect. Also restart the Directory Administration daemon (ibmdiradm).
 
Note: If the ibmdiradm daemon is not restarted, you will not be able to start or stop the ssl configured directory server from the Web administration tool.
Configuring the LDAP client to use SSL
There is no special setup required for LDAP clients using SSL other than the fact that the client must have the CAs root certificate in its key database file (see the steps described above). The application must then initiate a secure SSL connection by using the appropriate API calls, that is, ldap_ssl_client_init() in case of C applications. If client authentication is configured on the server, the client must be set up with its own certificate as described above for the server.
The command line tools supplied with IBM Tivoli Directory Server have special command line options to communicate with the server over SSL.
Here is an example of how you can fire a search to a server via SSL:
C:>ldapsearch -D cn=root -w secret -Z -K F:KEYSclientCMS.kdb -P client -s base objectclass=* | grep -i config
namingcontexts=CN=CONFIGURATION
ibm-configurationnamingcontext=CN=CONFIGURATION
ibm-slapdisconfigurationmode=FALSE
The above query is a root DSE search over SSL.
The -Z flag is used to indicate that this is an SSL query.
The -K attribute is used to specify the path of the client key database.
The -P attribute is used to specify the password of the client key database.
The server’s certificate is stored in clientCMS.kdb and using this the client is able to tell the server that it is a valid client.
This is an illustration of the authentication method of “Server Authentication”. On the same lines the “Server and Client Authentication” can be implemented. The way to implemented is almost the same way as described above. Above we see that the server exports its certificate to import it to the client. Similarly if the clients too export their certificates, which are imported into the server’s key database file, then the corresponding authentication is known as the “Server and client authentication”. In “Server and client authentication” both the server and the clients have a chance to verify that the request is coming from a valid client/server.
Configuring the Web administration tool to use SSL
The Web administration GUI tool is also a special type of client and hence needs some setup to communicate with an SSL configured server:
1. Start the Web Administration Tool and select the Console Admin from the drop down menu. Log in as the console administrator (the default username is superadmin and password is secret)
2. Click the Console administration tab and select Manage console properties.
3. Click SSL key database.
4. You need to have created a client key database of type jks and added the server certificate to it beforehand. Enter the absolute path of the jks key database file.
 
Note: The procedure for creating a jks file and importing certificate is as like the procedure for the CMS databases explained above. The only difference being that while creating the database you give the type as either CMS for a CMS database or JKS for a JKS database.
5. If you have not stashed the password while creating the jks key database, enter the password in the password field.
6. Enter the absolute path for the Trust database file. Its usually the same as the keydatabase file.
7. Next click the Manage console servers tab. Select the appropriate server from the right panel and click Edit.
8. Change the Port to 636 and check the SSL enabled check-box.
9. Click OK to apply the changes.
10. The next time you log into this directory server from the Web administration console, all communication between the server and the console will be over ssl. If the server was configured for SSLonly mode and the corresponding changes were not made in the console, the console will fail to communicate with the sever.
Figure 15-7 show the screenshot for enabling the Web administration tool to access servers via SSL.
Figure 15-7 Enabling Webadmin to access servers via SSL
For more detailed steps for configuring the directory server and Web administration tool, please see the administration guide at:
 
Note: If you wish to use the same server for both SSL and non-SSL communication then you can create an alias for the current server and configure the Webadmin to talk to the server over the non-SSL port. In this way you will have two entries for the same server, one for talking over SSL and the other for talking over non-SSL.
15.6 Protection against DoS attacks
Denial of Service (DoS) refers to a situation where the server is made to crash or is rendered unresponsive by bombarding it with huge number of client requests. These attacks cause huge losses to the victim in terms of time and money.
The IBM Tivoli Directory Server includes many advanced features to keep such attacks at bay. These features are listed below.
15.6.1 Non-blocking sockets
The read and write operations requested by the clients are handled intelligently so that a client which is trying to block the server by sending zero of partial data is automatically disconnected after a specified number of attempts.
On a read request, a client which continuously sends small amounts of data, is disconnected after a limited number of attempts. This limit is configurable and is represented by the attribute ibm-slapdReadBlockedAttempts in the config file under cn=Connection Management,cn=Frond End, cn=Configuration.
On a write request, a client is disconnected depending upon a write timeout value and the number of blocked write attempts. Both the values are configurable and are represented by the attributes ibm-slapdWriteTimeout and ibm-slapdWriteBlockedAttempts respectively in the config file under cn=Connection Management,cn=Frond End, cn=Configuration.
15.6.2 Extended operation for killing connections
This new extended operation, unbind, can be used by the administrator to terminate any faulty client connections and hence stop a probable DoS attack. This extended operation can be used to kill client connections that are:
•Bound to the server as a given DN
•Originated from a given client (IP Address)
•Bound to the server as a given DN and originated from a specified client
•Or all existing connections to the server
A purge all connections request would purge all connections except the connection the request came from. In all the above cases, connections not being served by a worker thread are terminated immediately. In case a worker is currently serving a connection, it is terminated once the operation is complete.
15.6.3 Emergency thread
A major serviceability problem occurs when all the worker threads of the server are busy performing some backend operations or are locked up. Even the directory administrator is unable to perform any diagnostic actions on the server. The emergency thread has been introduced to cope with such situations. It gets activated in case of such overloaded situations.
The emergency thread will be activated depending upon two configurable conditions:
•Size of work queue which represents the number of pending operations. This is represented by the variable ibm-slapdESizeThreshold in the config file.
•Time since the last item was removed from the queue, only if there are more items in the queue. This is represented by the attribute ibm-slapdETimeThreshold in the config file.
The admin can also specify which of the two, or a combination of the two will activate the emergency thread. This configurable parameter is represented by the attribute ibm-slapdEThreadActivate in the config file.
When the emergency thread is activated, a message will be logged into the ibmslapd.log file. The emergency thread will be deactivated when a worker removes an item from the work queue.
The emergency thread will support the following operations from the directory administrator:
•Kill Connection extended operation. It ensures that the admin will be able to stop a DoS attack without having to restart the server.
•Dynamic updates to the attributes in cn=Connection Management, cn=Front End, cn=Configuration section of the config file.
•Dynamic updates to the admin DN and admin password.
•Stopping and requesting the status of the server.
•Reading and clearing log files.
•Monitor and root DSE searches
•Modify and delete operations in the config backend.
15.6.4 Connection reaping
The connection reaping functionality has been enhanced to reap connections depending upon the type of authentication. There are three different thresholds specifying when:
•only anonymous connections will be reaped. It is represented by ibm-slapdAnonReapingThreshold attribute in the config file.
•only connections bound other than admin and replication connections will be reaped. It is represented by ibm-slapdBoundReapingThreshold attribute in the config file.
•all connections will be reaped. It is represented by ibm-slapdAllReapingThreshold attribute in the config file.
With all three thresholds only connections meeting the idle time out criteria will be reaped.
15.6.5 Allow anonymous bind
To add an extra level of protection the server will be able to reject anonymous bind requests. This will be a global setting for all backends. When dynamically updated to false it will trigger the unbind of all anonymous connections. This is represented by the attribute ibm-slapdAllowAnon in the config file.
 
Note: When anonymous binds are not allowed, TLS will not work.
Here is a screenshot of where exactly you set the above attributes:
1. Connect to the server using Web Administration tool.
2. Click Server Administration.
3. Click Manage Connection Properties.
4. On the right-hand side will be a panel which would provide you the options of changing attributes pertaining to the Connection termination reaping, etc., which were just discussed.
Figure 15-8 on page 471 shows the screenshot corresponding to the General tab.
Figure 15-8 Attributes pertaining to connections
Let us see the relation between the Web Admin attributes and the attributes in our configuration file (ibmslapd.conf):
•Allow anonymous connections corresponds to the attribute ibm-slapdAllowAnon.
•Cleanup threshold for anonymous connections corresponds to the attribute ibm-slapdAnonReapingThreshold.
•Cleanup threshold for authenticated connections corresponds to the attribute ibm-slapdBoundReapingThreshold.
•Cleanup threshold for all connections corresponds to the attribute ibm-slapdAllReapingThreshold.
•Idle timeout limit (in seconds) corresponds to the attribute ibm-slapdIdleTimeOut.
•Result timeout limit (in seconds) corresponds to the attribute ibm-slapdWriteTimeout.
Figure 15-9 on page 472 shows the settings of the emergency thread.
Figure 15-9 Attributes pertaining to the emergency thread
And here is the correlation of the attributes mentioned above and the configuration file:
•Enable emergency thread corresponds to the attribute ibm-slapdEThreadEnable.
•Pending request threshold corresponds to the attribute ibm-slapdESizeThreshold.
•Time threshold (in minutes) corresponds to the attribute ibm-slapdETimeThreshold.
•Criteria for emergency thread activation corresponds to the attribute ibm-slapdEThreadActivate.
15.7 Access control
Please refer to Chapter 14, “Access control” on page 395, for detailed description of Access Control Mechanism implemented in the IBM Tivoli Directory Server.
15.8 Summary
Let us summarize as to what we have seen in this chapter:
•We went through the different types of authentication:
 – Anonymous authentication
 – Basic authentication
 – SASL mechanisms
 – Kerberos
•We went through the password policy feature as to how it plays a key role in securing the user’s passwords by enforcing a set of rules on them. We also went through the implementation of the password policy in ITDS 52.
•We went through the password encryptions that the directory server supports and understood the significance of each of them.
•We went through securing the server via SSL and TLS.
•We also studied the IBM’s key management tool and how it is useful in generating and maintaining the keys and the relevant certificates.
•We went through the concept of Denial of Service (DoS) attack and studied the attributes which would help in preventing such attacks.
•We also got to know how ACLs play a vital role in the security of the directory entries/users.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset