YoLinux LDAP Tutorial: OpenLDAP Password Protection, security and Authentication

This tutorial covers adding password protection and security features to an openLDAP directory. Using the "rootdn" and "rootpw" will always allow you to access your system but sharing root privileges with your users is insecure. It is best to create a new user for read access or allow user read access. CONTENTS: Basic OpenLDAP (2.0) security Single login and password protection Unique user login and password protection Administration access assigned by group Access granted by privilege defined by an attribute Limit view of anonymous access Links This example uses the following OpenLDAP data and configuration files: /etc/openldap/slapd.conf fraternity.ldif Also see: Delta House configuration example

LDAP authentication takes three forms:

1. No authentication: Read access granted to all. The Stooges and Delta house examples in the YoLinux LDAP Tutorial are of this form.
2. Basic authentication: Client must bind with a DN and password. (Described in this tutorial)
3. Secure authentication: Secure encrypted or authenticated connection.

In this example a bind user is created for read access. This adds simple password protection with a common login/password for all users. (It is simple and does not require the generation of passwords for all users as in the second example.) This method protects the LDAP database from spammers and is a simple front line defense.

File: /etc/openldap/slapd.conf

.
..
...
database        ldbm
suffix          "o=delta"
suffix          "dc=ldap,dc=delta,dc=org"
rootdn          "cn=DeanWormer,o=delta"
rootpw          secret2
defaultaccess   none                         - Deny anonymous viewing and access
access to attr=userPassword                  - Deny anonymous viewing of passwords
       by dn="cn=DeanWormer,o=delta" write   - LDAP root not denied
       by self write                         - Allow user to update his password
       by * auth                             - Allow access to bind to LDAP (i.e. login requires access to password but still not allowed to view it)
access to *
       by dn="cn=DeanWormer,o=delta"  write  - LDAP root has full access
       by dn="cn=fratbrother,o=delta" read   - Required for first example. Allow this user to read the database. (Except passwords which are denied above)
       by users read                         - Required in second example where user logs in with his own password to read LDAP database. Reading of passwords other than his own is denied.
       by self write
       by * auth
directory       /var/lib/ldap/fraternity
schemacheck     on
lastmod         on
...
..
.
    

Notes:

• The order of granted access is from most specific to most general. (Required) The "access to attr=userPassword" is more specific than the "access to *" rule and thus comes first.
• LDAP passes one rule at a time in the order given until it fails. Order your rules appropriately.
• Giving write also gives read, which gives search, which gives compare.
• Every access to directive ends with an implicit by * none clause.
• Every access list ends with an implicit access to * by * none directive.
• Access directives modify the defaultaccess control.

access to	what	by	who	type-of-access
access to	* ("dn=.*" All) dn=".*,o=organization" filter="sn=Ander*" attr=attribute attr=attribute1,attribute2 attrs=attribute1,attribute2 When using more than one of these rules, separate by space.	by	* (All, anonymous and authenticated users) anonymous (Anonymous non-authenticated users) users (Authenticated users) self (User associated with target entry) dn= (Users matching regular expression) dnattr= (DN Attribute) addr="192.168.100.200" (addr tricks) group [/objectclass[/attrname][.basic style]]=regex ] peername [.basic style]=regex] peername="ip=192.168.100.200:*" sockname [.basic style]=regex] domain [.basic style]=regex] set=setspec aci=attributes	none (no access) auth (=x needed to bind) compare (=cx needed to compare) search (=scx to apply search filters) read (=rscx to read search results) write (=wrscx for modify/rename)

File: fratbrother.ldif

dn: cn=fratbrother,o=delta
cn: fratbrother
sn: fratbrother
objectclass: top
objectclass: person
userPassword: fratsecret

dn: cn=fratbrother,o=delta
cn: fratbrother
sn: fratbrother
objectclass: top
objectclass: person
userPassword: {CRYPT}frzelFSD.VhkI

  []$  perl -e 'print("userPassword: {CRYPT}".crypt("fratsecret","frat-salt")."\n");'
  userPassword: {CRYPT}frzelFSD.VhkI

Add to LDAP:

ldapadd -f fratbrother.ldif -cxv -D "cn=DeanWormer,o=delta" -w secret2

LDAP Bind:

• Bind with the "User ID" or "bind DN": cn=fratbrother,o=delta
• Password: fratsecret

Discussion: This will password protect your LDAP database. It creates a user ID "fratbrother" which can be used by all to have read only access to the LDAP directory. One must bind with the user login: fratbrother and password: fratsecret to access the database. The LDAP root login "DeanWormer" and password retain write privileges. This keeps spammers/hackers from viewing the whole database with a tool like GQ. The drawback is that everyone uses the same login/password but it is simple to configure. Read access is granted specifically to "fratbrother" in the slapd.conf file.

Netscape Address Book: When binding using Netscape Messenger use the "User ID:" fratbrother and "Password:" fratsecret. This is different than the LDAP Bind described above. I am assuming that Netscape employs the "Server Root" to generate the LDAP DN. The dialog box asks you to enter your Email address. This is because the Netscape Messenger LDAP DN uses the email address. This message can be ignored.

Netscape Directory Info	Netscape LDAP Password

[Potential Pitfall]: Some versions of Netscape will attempt to bind using the "User ID" and "Password" of NULL even if you enter values for these fields. This discovery was made using the Ethereal packet sniffer to diagnose problems I was having. I was using Netscape 4.77. (Red Hat Bugzilla: BUG# 55604)