Authenticating Linux Machines to eDirectory via LDAP
Novell Cool Solutions: Feature
By Jeff Falgout, Jeffrey Brown
Digg This -
Posted: 8 Jul 2003
Update: Check out the new Q&A about this article.
- eDirectory 8.7 or higher (tested on Netware 6.0sp2 at the time of this writing).
- ConsoleOne UNIX snapins.
- RedHat Linux 8.0 (tested at the time of this writing).
- Various configuration files elaborated within the document.
- A trusted root server certificate, if you want to do SSL on port 636.
To authenticate Linux clients/servers to an LDAP data source without having an entry in /etc/passwd via encrypted traffic, offers centralized management and secure authentication mechanisms. This tutorial proposes two ways of authenticating to the directory via two different encryption algorithms, TLS (Transport Layer Security) and SSL (Secure Socket Layer).
Authenticating via TLS takes place in the following way, an LDAP client makes an anonymous bind to the LDAP server on port 389/tcp, everything is passed in the clear on the wire. The moment the client requests priviledged data a TLS handshake is negotiated (provided the client can handle TLS) and all traffic becomes encrypted within the protocol/service intiated; there is no secure port the channel switches to like https or 443 in web traffic.
Authenticating via SSL takes place in the following way, the LDAP client binds to the secure LDAP port on the server, 636/tcp. Everything negotiated on this channel is secured at the application layer and the client must possess the LDAP server's public key before communicating over that port. Port 636 is used only for an SSL connection and Port 389 is utilized for anonymous binds and TLS.
Making it all Work, Server side:
- Be sure to have the appropriate snapins in ConsoleOne obtained at http://support.novell.com/cgi-bin/search/searchtid.cgi?/2958561.htm or search for filename c1unx85a.exe. Follow the instructions for installing the snapins to ConsoleOne in the readme. Editing user objects without the appropriate snapins will cause you much frustration because LDAP authentication won't work as we suggest.
- In ConsoleOne create a group object that will contain users authenticating via LDAP.
- Edit user objects in ConsoleOne to add the user to the group and add appropriate values to the attributes (shown below):
- These attributes are contained in the classes posixAccount & posixGroup and are provided to the LDAP client for authentication purposes.
- If the snapins were installed correctly, the Other tab in ConsoleOne (shown below) will reveal the uniqueID attribute. If the the uniqueID attribute doesn't contain the username and uniqueID DO NOT pass GO and DO NOT collect $100, secure authentication via LDAP will not work.
- Select the Server Certificate you'd like to use for SSL connections, DNS or IP.
- Check "Require TLS for all operations".
- CAUTION - Doing these steps will cause clear text authentication to not work.
Making it all Work, Client side:
- Files we'll need to use or have edited by configuration utilities
- /etc/ldap.conf, main configuration file, edited by authconfig and vi
- /etc/nsswitch.conf, name service switch file, edited by authconfig
- login in /etc/pam.d, edited by vi
- Check TLS if you want to do TLS or SSL.
- The pertinent data written to /etc/ldap.conf is
- For TLS, port 389/tcp:
- HOST servername.domain.com # In our testing IP address didn't work.
- BASE o=temp
- ssl start_tls
- pam_password md5
- HOST servername.domain.com
- BASE o=temp
- ssl on
- sslpath /usr/share/ssl/certs/
, more on this later - -
- pam_password md5
session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0077
- For this open ConsoleOne, locate your LDAP server's SSL CertificateDNS or the SSL CertificateIP, depending on which layer you'd like to use, in this example we're using DNS and open the properties of the certificate.
- Export the Trusted Root certificate by using the wizard, don't export the private key and change the name of the exported cert as it's very long.
- Finally copy the certificate to the Linux client in the path specificed (/usr/share/ssl/certs) and you should be able to authenticate via port 636/tcp. This method allows you to block access to port 389/tcp and do all authentication on the secure channel if desired.
Question: How can I set at the uniqueID attribute "uniqueID DO NOT pass GO and DO NOT collect $100"? Are these two normal ASCII-Sequences, which I write in the "Extended Editor Dialog" box at the uniqueID atrribute?
Jeffrey Brown: In our testing the uniqueID attribute values were populated with the creation of the user account and the UNIX snapins. However existing accounts in our production tree needed only the value of the CN in the uniqueID attribute. The document is somewhat in error mandating the need of the uniqueID value in the uniqueID attribute (we're still learning about the ldap -> nds translations). For what it's worth here's the LDIF from one of our test users:
dn: cn=ldaptest, ou=what,o=ever
sn: ldap test
ACL: 2#subtree#cn=ldaptest,ou=what,o=ever#[All Attributes Rights]
I guess to answer the question, use the UNIX snapins from Account Management 2.1 for UNIX mentioned in the document.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com