Novell Home

Authenticating Linux Machines to eDirectory via LDAP

Novell Cool Solutions: Feature
By Jeff Falgout, Jeffrey Brown

Digg This - Slashdot This

Posted: 8 Jul 2003
 

Update: Check out the new Q&A about this article.

Requirements:

  • 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.

Purpose:

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:

  1. 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.

  2. In ConsoleOne create a group object that will contain users authenticating via LDAP.

  3. 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.





  4. Open up iManager https://:2200/eMFrame/iManager.html and authenticate to edit some LDAP attributes (shown below).

  5. In LDAP Management > LDAP Overview > LDAP Group, check "Require TLS for Simple Binds with Password".



  6. In LDAP Management > LDAP Overview > View LDAP Servers > Connections:
    1. Select the Server Certificate you'd like to use for SSL connections, DNS or IP.
    2. Check "Require TLS for all operations".
    3. CAUTION - Doing these steps will cause clear text authentication to not work.



  7. Unload and reload NLDAP.NLM on the server to refresh or update the changed attributes.

Making it all Work, Client side:

  1. 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

  2. Launch authconfig and add in LDAP authentication information

    • Check TLS if you want to do TLS or SSL.



    • The pertinent data written to /etc/ldap.conf is
      • For TLS, port 389/tcp:
        1. HOST servername.domain.com # In our testing IP address didn't work.
        2. BASE o=temp
        3. ssl start_tls
        4. pam_password md5

      • For SSL, port 636/tcp, you'll have to add some attributes because authconfig does not:
        1. HOST servername.domain.com
        2. BASE o=temp
        3. ssl on
        4. sslpath /usr/share/ssl/certs/, more on this later - -
        5. pam_password md5

    • Authconfig should have added the ldap tag to most services in /etc/nsswitch.conf.

    • And in our login file in /etc/pam.d we added the directive for calling the mkhomedir.so library, like so:

      session required /lib/security/pam_mkhomedir.so
      	skel=/etc/skel/ umask=0077


    • If all of your configuration worked you should have a Linux client that can authenticate to eDirectory via LDAP and all the authentication data that passes on the wire will be encrypted via TLS on port 389. No user accounts need to exist in /etc/passwd or /etc/group, all of this data exists in the directory.

    • For the authenticating on port 636 you'll need to export the server's trusted root certificate and copy it to the client, see 3.2.5 above.

  1. 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.

  2. 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.

  3. 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.

Q&A About this Article

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
loginShell: /bin/bash
uidNumber: 5000
gidNumber: 5000
Language: ENGLISH
passwordAllowChange: TRUE
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: ndsLoginProperties
objectClass: posixAccount
objectClass: uamPosixUser
uid: ldaptest
uid: uniqueID
gecos:
groupMembership: cn=ldapgroup,ou=what,o=ever
loginTime: 20030505212409Z
loginIntruderAddress:: MSPvv70QCAU=
cn: ldaptest
cn: CN
securityEquals: cn=ldapgroup,ou=what,o=ever
homeDirectory: /home/ldaptest
ACL: 2#subtree#cn=ldaptest,ou=what,o=ever#[All Attributes Rights]
ACL: 6#entry#cn=ldaptest,ou=what,o=ever#loginScript
ACL: 2#entry#[Public]#messageServer
ACL: 2#entry#[Root]#groupMembership
ACL: 6#entry#cn=ldaptest,ou=what,o=ever#printJobConfiguration
ACL: 2#entry#[Root]#networkAddress
ACL: 2#entry#[Public]#uidNumber
ACL: 2#entry#[Public]#gidNumber
ACL: 2#entry#[Public]#loginShell
ACL: 2#entry#[Public]#homeDirectory
ACL: 2#entry#[Public]#gecos
ACL: 2#entry#[Public]#groupMembership
ACL: 1#entry#[Public]#cn

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

© 2014 Novell