Intro to LDAP
Australian Unix Users' Group (SA)
Wed 09-Mar-2005

Tim Seeley

The plan for this evening:

• LDAP background - what is it and what can it do?
• live demo of setting up a basic ldap directory for login authentication services
• if time permits, one or more of:
  • replication
  • failover
  • encrypting LDAP communications with SSL
• but we don't want to encroach on the pizza time(!)

Disclaimer

• LDAP is a weird and wonderful beast.
• I am not an expert, and you won't become one by listening to me.
• Most of what you can do with LDAP has significant security implications which I do not attempt to address in any comprehensive way. In the demo I will cut security corners - either for convenience or because I just don't know any better, so don't rely too heavily on my example configurations.
• But hopefully you will get a bit of a feel for what LDAP is and how you might be able to use it.

Recommended Reading

• LDAP System Administration,
  Gerald Carter, O'Reilly (2003)
  • OpenLDAP focus
  • good worked examples for various real-world scenarios
  • limited to just one book? - I'd pick this one
• Understanding and Deploying LDAP Directory Services (2nd ed),
  Tim Howes et al, Addison Wesley (2003)
  • NDS leanings
  • good treatment of more theoretical issues, such as directory design considerations, etc

LDAP Background

What is LDAP?

• L - Lightweight (compared to X500)
• D - Directory (information repository; Note: optimised for reads, so don't expect it to replace all your SQL databases)
• AP - Access Protocol (LDAP is primarily a network protocol - numerous RFCs)
  • non-textual - can't telnet to an LDAP server for debugging like you can to an HTTP or SMTP server
  • session-oriented - bind (login) first, then do one or more operations, then unbind
• Numerous implementations: University of Michigan, NDS, OpenLDAP, M$ Active Directory, ...
• Server implementations need some form of storage: Sleepycat, ... even SQL databases(!)

Some Things People Do With LDAP

• centralised login authentication
• replace NIS
• web site login authentication
• white pages, address book services for email clients
• mail routing
• ...
• custom applications - anything that can benefit from a networki accessible directory

Some Terminology

• attribute - a single data element. Somewhat like a single field of a row of a table in a relational database, but
  • some attributes are optional (a bit like a NULL value?)
  • some attributes can be multi-valued - Boyce-Codd Normal Form is not known here!
• entry - a collection of attributes. Analogous to a row in a table in a relational database.
• RDN (relative distinguished name) - property of an entry that uniquely identifies it among all its siblings. An RDN consists of an attribute name=value pair. NOTE: the attribute name is part of the RDN(!)

      dn: uid=tim
      

• DN (distinguished name) - property of an entry defines it uniquely among all entries in a directory. It consists of the RDN of the entry, followed by the RDN of it's ancestors all the way up to the root of the directory. Note the little-endian orientation (like DNS, opposite to file systems).

      dn: uid=tim,ou=People,dc=shellgrit,dc=com
      

• LDIF (LDAP Interchange Format) - a standard textual notation for representing an entry, as well as for specifying changes to be applied to an entry.

      dn: uid=u2,ou=People,dc=shellgrit,dc=com
      uid: u2
      cn: User 2
      objectClass: account
      objectClass: posixAccount
      objectClass: top
      objectClass: shadowAccount
      userPassword: {crypt}$1$Ht.ugE4R$wVps8Wj9UHqN5DYM1pILT0
      shadowLastChange: 12836
      shadowMax: 99999
      shadowWarning: 7
      loginShell: /bin/bash
      uidNumber: 602
      gidNumber: 602
      homeDirectory: /home/nfs/u2
      gecos: User 2
      

• objectClass - a template for an entry that defines the sets of required and allowed attributes. Each entry must have one 'structural' objectClass, but may have many 'auxiliary' objectClasses as well. The attribute sets will be the union of those specified by all the objectClasses.
• schema - definition of attributes and objectClasses. See /etc/openldap/schema/* for the default schemas, but users may also define their own.

LDAP Demo

Objectives:

• set up a minimal LDAP server
• add some data that will support login authentication
• hook a client machine into the LDAP server
• one working example, rather than full coverage of all the important issues

Starting Point:

• three PII-350 machines with 128Mb RAM
• Fedora Core 3 loaded:
  • two configured with 'server' profile, plus OpenLDAP server and client packages
    • ldap4 will run our first ldap server, and will become the 'master' server if we get as far as replication tonight
    • ldap3 will become our 'slave' LDAP server
  • one configured with 'personal desktop' profile, plus OpenLDAP client package
    • ldap2
  • Note: we are using the Fedora-supplied versions of pam_ldap and nss_ldap.
• minimal NFS configuration:
  • '/ldap' for convenience to share ldap setup files
  • '/home/nfs/' for home directories of LDAP-defined users

Configuring and Starting an OpenLDAP Server

• /etc/openldap/slapd.conf
  • suffix: replace with correct domain
  • rootdn: replace with correct domain
  • rootpw: set in cleartext for now (this is a bad idea, but for now ...)
• the Red Hat thing:
  • service ldap start
  • chkconfig --levels 345 ldap on
• sanity check: query the Root DSE (Directory Server-Specific Entry)
  • ldapsearch -x -s base -b "" "(ObjectClass=*)' +
  • should list info about capabilities of the server
• at this point we have a working server, but no data has been loaded

Preparing user account data to add to the directory

• create some user accounts
  • create_users
• migration tool (set of Perl scripts) from PADL Software
  • customise migrate_common.ph:

        :%s/padl/shellgrit/gc
    
        < $DEFAULT_MAIL_DOMAIN = "padl.com";
        < $DEFAULT_BASE = "dc=padl,dc=com";
        < #define(`confLDAP_DEFAULT_SPEC',`-h "ldap.padl.com"')dnl
        < $DEFAULT_MAIL_HOST = "mail.padl.com";
    
        > $DEFAULT_MAIL_DOMAIN = "shellgrit.com";
        > $DEFAULT_BASE = "dc=shellgrit,dc=com";
        > #define(`confLDAP_DEFAULT_SPEC',`-h "ldap4.shellgrit.com"')dnl
        > $DEFAULT_MAIL_HOST = "mail.shellgrit.com";
        

  • run some of the scripts to generate data in LDIF format:

        ./migrate_base.pl > /ldap/ldif/top.ldif
        ./migrate_group.pl /etc/group > /ldap/ldif/group.ldif
        ./migrate_passwd.pl /etc/passwd > /ldap/ldif/passwd.ldif
        

  • edit out the entries that you don't want to go into the LDAP directory

Loading Data

• /ldap/bin/addfile   /ldap/ldif/top.ldif
• /ldap/bin/addfile   /ldap/ldif/passwd.ldif
• /ldap/bin/addfile   /ldap/ldif/group.ldif

Querying the Directory

• ldapsearch
• search base: the point in the directory tree at which we want to start searching
• search scope: how deep below the search base should we look?
  • base: only look at the entry specified by the search base
  • onelevel: only look at the search base's immediate children
  • sub: look at the search base and all its descendants
• search filter: boolean expression specifying criteria that an entry must meet to be included
  • prefix notation
• select which attributes' values to return:
  • default is to return all attributes (non-operational)
  • name the attributes you want to exclude all others
  • '+' requests return of 'operational' attributes
• can set some local defaults in /etc/openldap/ldap.conf

Debugging OpenLDAP Problems

• slapd logs to LOG_LOCAL4 by default, so add something like this to your /etc/syslog.conf:

  	local4.*    /var/log/slapd.log
      

  and restart syslogd:

          service syslog restart
      

• to select what events slapd will log, set loglevel in slapd.conf

  loglevel	effect
  -1	log everything
  0	log nothing
  otherwise, add values from this list to select what you want to log:
  1	trace function calls
  2	debug packet handling
  4	heavy trace debugging
  8	connection management
  16	print out packets sent and received
  32	search filter processing
  64	configuration file processing
  128	access control list processing
  256	stats log connections/operations/results
  512	stats log entries sent
  1024	print communication with shell backends
  2048	entry parsing

  
  and restart slapd:

          service ldap restart
      

• then watch slapd.log while you run queries:

          tail -f /var/log/slapd.log
      

  The OpenLDAP commandline tools often report useful diagnostics anyway, but this can be a particularly helpful method of debugging opaque 3rd-party applications.

Preparing a Client to Authenticate Against an LDAP Directory

• on client machine (ldap2) run 'authconfig' (as root):
  • options: cache information; use LDAP; use MD5 passwords; use shadow passwords; use LDAP authentication
  • don't use TLS (just because we haven't set up server certificates yet - should really do this unless you are comfortable with cleartext passwords floating around on your network!)
  • server: ldap4.shellgrit.com
  • base dn: dc=shellgrit,dc=com (why not ou=People,dc=shellgrit,dc=com?)
• configuration is stored in /etc/sysconfig/authconfig
• pam_ldap is added to the PAM stack in /etc/pam.d/system-auth
• ldap server settings (server identity and search base) are stored in /etc/ldap.conf

• repeat authconfig setup on the other two machines (ldap3 & ldap4)
  • There is no in-principle reason why a machine cannot authenticate to an LDAP server running on itself.
  • But there are reasons why you might choose not to let general users log into the machine that runs your LDAP server.
  • on ldap4 we will want to remove the locally-defined accounts that will become LDAP-supported: delete_users

User Password Management

• We may want:
  • users to be able to change their passwords in the usual way ('passwd').
  • root to be able to change anyone's password ('passwd u3').
• Add this to /etc/ldap.conf on the clients:

      pam_password exop
    

  Then log in to ldap2 as an LDAP-defined user, and try changing password.
  Problems? ...
  • set server's loglevel to 224 (config file + search filters + ACLs)
  • keep an eye on /var/log/slapd.log while retrying ... Aha!
  • The default access policy is "read-only for everyone except the rootdn". Try this instead:

          access to *
            by self write
            by * read
        

    Probably a more realistic policy would be:
    • let users update their own passwords (but maybe not everything in their own entry)
    • don't let anybody have read-access to password fields
    • but do let passwords be accessed for the purpose of accepting or rejecting bind requests

          access to dn=".*,dc=shellgrit,dc=com" attr=userPassword
            by self write
            by * auth
          access to dn=".*,dc=shellgrit,dc=com"
            by * read
        

• Note that root is still prompted for the user's current password
  We can get around this by configuring the following in /etc/ldap.conf:

        rootbinddn cn=Manager,dc=shellgrit,dc=com
      

  Then, if root is logged in, pam_ldap will attempt to bind to the LDAP directory using this dn with the cleartext password stored in /etc/ldap.secret. [This, of course, would be a really bad idea on a desktop machine that just anyone might be able to easily boot in single-user mode ....(!).] If you want to do this, perhaps do it just on the master LDAP server (which you wouldn't even allow general login access to, would you?).
• ... or in a heterogenous environment it may be better to build a web interface through which users can change their passwords (e.g. PHP can be compiled with an LDAP API included)

Other Topics

• Replication

• SSL

• Access Control Lists

• How to set root dn password in slapd.conf NOT in cleartext

• Indexing for Performance

• Controlling which machines a user can log in on

• Distributed Directories - using referrals

• ...

Questions ...?

sample question