 |
» |
|
|
 |
The LDAP-UX Client Services provides SSL (Socket Security Layer) support to secure communication between LDAP clients and the Active Directory Servers. An encrypted connection can be established on an encrypted port, 636. The LDAP-UX Client Services supports SSL with password as the credential, using either simple bind or SASL GSSAPI authentication to ensure confidentiality and data integrity between clients and servers. The LDAP-UX Client Services supports Microsoft Windows 2000, 2003 or 2003 R2 Active Directory Server (ADS), Netscape Directory Server (NDS) 6.x and Red Hat Directory Server 7.0/7.1 over SSL. For detailed information on how to enable SSL communication over LDAP for your Windows 2000 Active Directory Server, refer to Microsoft Knowledge Base Article Q247078 at http://support.microsoft.com/default.aspx?scid=kb;en-us;247078 TLS Support |  |
Starting with LDAP-UX Client Services B.04.10, the product supports a new extension operation of TLS (Transport Security Socket) protocol called startTLS to secure communication between LDAP clients and the Windows Active Directory Server. An encrypted session can be established on an un-encrypted port, 389. If an encrypted port is used, it will fail to establish the secure connection. The TLS protocol provides administrators better flexibility for using TLS in their environment by allowing the use of an un-encrypted LDAP port for communication between the clients and the server. LDAP-UX supports TLS with password as the credential, using either simple bind or SASL GSSAPI authentication to ensure confidentiality and data integrity between clients and servers. The LDAP-UX Client Services supports Microsoft Windows 2003 or 2003 R2 Active Directory Server (ADS), Netscape Directory Server (NDS) 6.x and Red Hat Directory Server 7.0/7.1 over TLS. Configuration Parameters |  |
LDAP-UX Client Services provides the following parameter in the /etc/opt/ldapux/ldapux_client.conf file to support TLS. - enable_starttls
This integer variable controls whether the TLS feature is enabled or disabled. The valid values of this parameter are 1 and 0. If you choose to enable TLS, set this parameter to 1. To disable TLS, set this variable to 0. By default, TLS is disabled. If the enable_startTLS parameter is undefined or does not exist, it is processed as the TLS feature is disabled.
If you want to use SSL or TLS, you must perform the following tasks before you run the setup program: Ensure to have the certificate database files, cert8.db or cert7.db and key3.db, on your client system. See “Configuring the LDAP-UX Client to Use SSL or TLS”for details. If you choose to enable TLS, set the enable_starttls parameter to 1 in the /etc/opt/ldapux/lldapux_client.conf file. To use SSL, set enable_starttls to 0. By default, TLS is disabled.
Configuring the LDAP-UX Client to Use SSL or TLS |  |
You can choose to enable SSL or TLS with LDAP-UX when you run the setup program. If you want to use SSL or TLS, you must install Certificate Authority (CA) certificate on your LDAP-UX Client and configure your LDAP directory server to support SSL or TLS before you run the setup program. Steps to Download the CA Certificate from Windows 2000 CA ServerDownloading the certificate database from the Netscape Communicator is one way to set up the certificate batabase into your LDAP-UX Client. The following steps show you an example on how to download the Certificate Authority (CA) certificate from Windows 2000 Certificate Authority Server using Netscape Communicator 4.75: Log in to your system as root. Use Netscape Communicator to connect to your Certificate Authority Server. The following shows an example of using a link to connect to your CA Server: http://ADS servername/CertSrv Enter "administrator" as the usename and the user's password for Active Directory Server. Select a task, retrieve the CA certificate or certificate revocation list, in the Microsoft Certificate Services screen. Then, click the Next button. Click the "Install this CA certificate" link in the retrieve the CA certificate or certificate revocation list window to allow your LDAP-UX client to trust certificates issued from this Certificate Authority. Click the Next button in the window box which prompts that you are about to go through the process of accessing a Certificate Authority. This has serious implications on the security of future encrytions using Netscape. Click the Next button in the window box which prompts that a CA certifies the identity of . By accepting the CA, you will allow Netscape Communicator to connect to and receive information from any site that it certifies without prompting you or warning you. Click the Next button in the window box which prompts that here is the certificate for this CA. Examine it carefully. The Certificate Fingeprint can be used to verify that this authority is who they say they are. Check the "access the CA for certifying network sites", " access the CA for certifying e-mail users" and "access the CA for certifying software developers" checkboxes in the new CA window screen. Click the Next button in the new CA box screen which prompts that by accepting this CA, you have told Netscape Communicator to connect to and receive information from any site that it certifies without warning you or prompting you. Enter a short name to identify this CA in the Name box of new CA window screen. Click the finish button to complete the installation of CA certificate. The Windows 2000 CA certificate will be downloaded to the following two files on your LDAP-UX Client: /.netscape/cert7.db /.netscape/key3.db You can simply copy the /.netscape/cert7.db file to /etc/opt/ldapux/cert7..db and /.netscape/key3.db file to /etc/opt/ldapux/key3.db. Set the file access permissions for/etc/opt/ldapux/cert7..db and /etc/opt/ldapux/key3.db to be read only by root as follows: -r-------- 1 root sys 65536 Jun 14 16:27 /etc/opt/ldapux/cert8.db
-r-------- 1 root sys 32768 Jun 14 16:27 /etc/opt/ldapux/key3.db |
Steps to Download the CA Certificate From Windows 2003 CA ServerThe following steps show you an example on how to download the Certificate Authority (CA) certificate from Windows 2003 Certificate Authority Server using Mozilla browser: Log in to your system as root. Use Mozilla browser to connect to your Certificate Authority Server. The following shows an example of using a link to connect to your Certificate Authority Server: http://ADS servername/Certsrv Click on the "Download a CA Certificate" link. Click on "install this CA Certificate" link in the "Download a CA Certificate, Certificate Chain, or CRL" window screen. Check the "Trust this CA to identify web sites", " Trust this CA to identify email users", and "Trust this CA to identify software developers" checkboxes in the Downloading Certificate window screen. Then click OK button. The Netscape Directory CA certificate will be downloaded to the following two files on your LDAP-UX Client: /.mozilla/default/*.slt/cert8.db /.morilla/default/*.slt/key3.db You can simply copy the /.mozilla/default/*slt/cert8.db file to /etc/opt/ldapux/cert8.db and /.mozilla/default/*slt/key3.db file to /etc/opt/ldapux/key3.db. Set the file access permissions for /etc/opt/ldapux/cert8.db and /etc/opt/ldapux/key3.db to be read only by root as follows: -r-------- 1 root sys 65536 Jun 14 16:27 /etc/opt/ldapux/cert8.db
-r-------- 1 root sys 32768 Jun 14 16:27 /etc/opt/ldapux/key3.db |
 |  |  |  |  | NOTE: For the multiple domain environment, you just need to download the certificate database files, cert7.db or cert8.db and key3.db, from one domain, no additional action is required.You may use the unsupported /opt/ldapux/contrib/bin/certutil command line tool to create the certificate database files, cert8.db and key3.db. For detailed command options and their arguments, refer to Using the Certificate Database Tool available at http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html. |  |  |  |  |
If your browser does not generate cert8.db and key3.db security database files, you must export the certificate (preferably the root certificate of the Certificate Authority that signed the LDAP server's certificate) from your certificate server as a Base64-Encoded certificate and use the certutil utility to create the cert8.db and key3.db security database files. Steps to create database files using the certutil utilityThe following steps show you an example on how to create the security database files, cert8.db and key3.db on your client system using the certutil utility: Retrieve the Base64-Encoded certificate from the certificate server and save it. For example, get the Base64-Encoded certificate from the certificate server and save it as the /tmp/mynew.cert file. This file looks like: --------------- BEGIN CERTIFICATE ------------------------------------
-MIICJjCCAY+gAwIBAgIBJDANBgkghkiG9w0BAQQFADBxMQswCQYDVQQGEwJVUzEL
MAkga1UECBMCQ2ExEjAQBgNVBAcTCWN1cGVvsG1ubzEPMA0GA1UEChmgAhaUy29T
MRIwEAYDVQQLEw1RR1NMLUxkYXAxHDAaBgNVBAMTE0N1cnRpzmljYXR1IE1hbmFn
4I2vvzz2i1Ubq+Ajcf1y8sdafuCmqTgsGUYjy+J1weM061kaWOt0HxmXmrUdmenF
skyfHyvEGj8b5w6ppgIIA8JOT7z+F0w+/mig=
--------------- END CERTIFICATE -------------------------------------- |
Use the rm command to remove the old database files, /etc/opt/ldapux/cert8.db and /etc/opt/ldapux/key3.db: rm -f /etc/opt/ldapux/cert8.db /etc/opt/ldapux/key3.db Use the certutil utility with the -N option to initialize the new database: /opt/ldapux/contrib/bin/certutil -N -d /etc/opt/ldapux Add the Certificate Authority (CA) certificate or the LDAP server's certificate to the security database: Use the certutil command to add a CA certificate to the database: For example, the following command adds the CA certificate, my-ca-cert, to the security database directory, /etc/opt/ldapux, with the Base64-Encoded certificate request file, /tmp/mynew.cert: /opt/ldapux/contrib/bin/certutil -A -n my-ca-cert -t "C,," -d /etc/opt/ldapux -a -i /tmp/mynew.cert  |  |  |  |  | NOTE: The -t "C,," represents the minimum trust attributes that may be assigned to the CA certificate for LDAP-UX to successfully use SSL or TLS to connect to the LDAP directory server. If you have other applications that use the CA certificate for other functions, then you may wish to assign additional trust flags. See http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html for additional information. |  |  |  |  |
Use the certutil command to add the LDAP server's certificate to the security database: For example, the following command adds the LDAP server's certificate, my-server-cert, to the security database directory, /etc/opt/ldapux, with the Base64-Encoded certificate request file, /tmp/mynew.cert: /opt/ldapux/contrib/bin/certutil -A -n my-server-cert -t “P”,,” \ -d /etc/opt/ldapux -a -i /tmp/mynew.cert  |  |  |  |  | NOTE: The -t "p,," represents the minimum trust attributes that may be assigned to the LDAP server's certificat for LDAP-UX to successfully use SSL or TLS to connect to the LDAP directory server. See http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html for additional information. |  |  |  |  |
Adjusting the Peer Certificate PolicyWith SSL/TLS, not only communication between clients (LDAP-UX) and servers (the LDAP directory server) can be protected, but in addition, specific levels of assurance of the identities of the clients and servers can be validated. This section describes how to adjust this validation level. The peer_cert_policy parameter in the /etc/opt/ldapux/ldapux_client.conf configuration file is a string variable used to control the validation level. There are three valid options for this parameter described below: - WEAK
Performs no validation of SSL or TLS certificates. Communication between the client and server can be encrypted, however the client has no assurance that it is communicating with a trusted server. - CERT
Verifies that the issuers of peer SSL or TLS certificates are trusted. Communication between the client and server can be encrypted and the client has some assurance that it is communicating with a trusted server. In this scenario, it is still possible for the server to have a certificate that has been issued for a different server if methods used to protect private keys of server certificates are not in place. CERT is the default mode of operation with LDAP-UX. - CNCERT
Performs both the CERT check and also verifies that the common name or subjectAltName values embedded in the certificate matches the address used to connect to the LDAP server, as described in RFC 4513.
As mentioned above, the default mode of operation for LDAP-UX is CERT. Increasing certificate validation level to CNCERT requires additional and specific configuration steps. If not properly established, it can interfere with LDAP-UX and proper system operation. Because LDAP-UX can be used for host-name resolution (similar to DNS), LDAP-UX normally stores the IP address of LDAP servers in the configuration profile. This procedure assures that if LDAP-UX is asked to resolve a host name, it can do so without first needing to resolve the host name of the LDAP directory server (which could lead to a catch-22). However, since certificates normally embed the host name or fully qualified host name and LDAP-UX only has the IP address of the host, it is not possible for LDAP-UX to verify the host name on the certificate. If you want to configure the CNCERT validation level with the peer_cert_policy parameter, you must manually execute the following configuration steps: Update the preferredserverlist setting in the profile to contain the host name of the LDAP server such that it matches the host name specified in the LDAP server’s certificate. See the “Modifying perferredserverList in the LDAP-UX Profile” section for details. Select and execute one of the following steps: Either LDAP-UX must not be used for host-name resolution by removing “ldap” from the “hosts” service in the /etc/nsswitch.conf file. Or the host name and IP address must be provided by some other name resolution service, such as “files” or “dns”, and that service must appear before “ldap” in the /etc/nsswitch.conf file for the “hosts” service.
Modifying preferredSererList in the LDAP-UX Profile Use the following steps to modify the value of the preferredServerList attribute in the LDAP-UX configuration profile: Run the following steps to find the name of the LDAP server used on the server certificate. Assuming this certificate has been installed in your local certificate database file, /etc/opt/ldapux/cert8.db: Run the following commands to list all server certificates used by LDAP-UX: cd /etc/opt/ldapux certutil -d . -L Run the following command to select the nickname of the certificate from the above list: cetutil -d . -L -n <selected nickname> Select the first name component of the “Subject:” name. For example, if the “Subject:” string is “CN=ldapserver.example.com, O=Example Corp” then the name component would be “ldapserver.example.com".
 |  |  |  |  | NOTE: Depending on how your certificate administrator manages your network, the above server certificate may not be found in your cert8.db file. Instead you may only find certificates for any trusted Certificate Authorities. In this case, contact your certificate administrator for the LDAP server certificate details. |  |  |  |  |
In a separate window, use the Active Directory Services Interface (ADSI) to modify the value of the preferredServerList attribute with the LDAP server name found in step 1. See “Modifying a Profile” for detailed information on changing LDAP-UX configuration profile settings manually. Examine the “preferedServerList” attribute Use the nslookup tool to verify the IP address specified in the preferred server list matches that of the name of the host name found in step 1 above. For example, if the preferredserverlist attribute value is 192.168.1.1:636 and “Subject” is CN=ldapserver.example.com,O=Example Corp, then $ nslookup 192.168.1.1
Name Server: dns-resolver.example.com
Address: 192.169.1.254
Trying DNS
Name: ldapserver.example.com
Address: 192.168.1.1
|
|