Authenticating to eDirectory via LDAP using an X.509 User Certificate
Novell Cool Solutions: Trench
By Luke Tracy
Digg This -
Posted: 10 Feb 2004
I needed to use OpenLDAP client tools on a Linux box to perform changes to eDirectory users via LDAP and did not want to pass a user name and password each time. Although I am using an encrypted channel, this was something I needed to automate and did not want to store a user name and password in a script. The OpenLDAP client tools and eDirectory's LDAP interface both support TLS/SSL and SASL authentication using the EXTERNAL mechanism. This basically means that you pass a X509 user certificate to the LDAP server as part of securing the channel and then use that certificate instead of a user name and password to authenticate to eDirectory.
Within the server's LDAP Server object:
- LDAP configured with TLS/SSL enabled (note port number)
- Client Certificate: - change from Default to Requested
Be sure the SASL EXTERNAL mechanism is supported on your eDirectory server by issuing the following query via anonymous bind:
ldapsearch -h server.company.com -p 389 -x -b' ' -s base supportedSASLMechanisms
If you have anonymous binds disabled, you will need to provide a valid DN and password:
ldapsearch -h server.company.com -p 389 -D cn=user,o=novell -W -x -b' ' -s base supportedSASLMechanisms
If EXTERNAL is not listed in the response then you will need to install the CertMutual NMAS Method into your tree. You can use the NMAS installer that came with the latest version of eDirectory that you have installed in your tree.
This is the tricky part. There are three files that you have to work with in this step -- certificate, private key, and the Certificate Authority public key. The OpenLDAP tools require that the private key not be encrypted with a password. This requires a few extra steps since eDirectory will not allow the private key to be exported without providing a password to encrypt it with.
Here are the steps:
- Create the user certicate and then export it.
- Use OpenSSL tools to separate the certificate from the private key, and remove the password.
- Copy the CA public key from my server to my workstation.
I used ConsoleOne to create and export the user certificate. Later versions of iManager can also be used to accomplish both tasks. In ConsoleOne, I accessed the properties of the user object I wished to create a certificate for and chose Certificates on the Security tab. I clicked the button to Create, selecting the server to use for the certificate creation, a nickname for the certifcate of 'eDir Cert' and chose the standard creation method. Then I clicked to export the certicate, with the private key, unchecked the box to include all certificates in the chain, and provided a password.
I copied the .pfx file created during the previous step to my workstation and executed the following:
Command to extract the certificate and remove password:
openssl pkcs12 -in 'eDir cert.pfx' -clcerts -nodes -nokeys -out cert.pem <enter password used in step 1 when prompted>
Commands to extract the private key and remove password:
openssl pkcs12 -in 'eDir cert.pfx' -clcerts -out file.pem -nodes <enter password used in step 1 when prompted>
openssl rsa -in file.pem -out key.pem
Now that I had the certificate (cert.pem) and the private key (key.pem) I deleted eDir cert.pfx and file.pem.
I also needed to copy RootCert.der from the SYS:\Public directory of my server to my workstation and use the following command to convert it to .PEM format:
openssl x509 -in RootCert.der -inform DER -outform PEM -out rootcert.pem
Once I had all three files on my workstation, I moved them to /home/ltracy/.certs.
The Linux user needs to have a .ldaprc configuration file in their home directory ($HOME) that identifies where these three files are to the OpenLDAP tools. Here is a sample .ldaprc file:
TLS_CACERT /home/ltracy/.certs/rootcert.pem TLS_CERT /home/ltracy/.certs/cert.pem TLS_KEY /home/ltracy/.certs/key.pem TLS_REQCERT allow
Now that we have all of the configuration and files in place, it's time to make a connection to the ldap server and try it out.
Here is a simple search command the user can issue to make sure it's working:
ldapsearch -H ldaps://server.company.com:636 -Y EXTERNAL -LLL -b"o=organization" -s sub objectclass=user cn
If you would like to see all of the debug information for the transaction, add -d 65535 to the command.
Other OpenLDAP client commands can be issued in much the same manner.
If you have any questions you may contact Luke at firstname.lastname@example.org
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com