Saturday, June 1, 2013

Some notes about setting up LDAP

One thing I want my pogo to do is to serve filesystem over NFS, but NFS is not terribly secure without Kerberos. I also want the uid on NFS to match across all my computers, so that means I need a centralized login like what LDAP offers. Since I might want to add Windows boxes some day when hell freezes over, I might as well throw Samba into the mix. So here I am, LDAP + Kerberos + NFS + Samba. Samba will use Kerberos to authenticate, and Kerberos will store credentials in LDAP. At the moment I decided not to use Samba4 which has its own integrated SMB + LDAP + Kerberos stack.

I installed and configured OpenLDAP on Debian. These are the things I learned.

If someone mentions modifying slapd.conf on the web, the guide is out of date. OpenLDAP now uses LDAP to store configuration files (called "olc" which stands for "on line config").

LDAP now serves at least two databases:
  • cn=config for olc
  • dc=example,dc=com for your example.com domain database.
OpenLDAP has two sets of tools.
  • ldapsearch, ldapadd, ldapmodify: these are authenticated through the usual LDAP protocols, either through tcp (ldap://host), TLS (ldaps://host), or Unix domain socket (ldapi:///)
    • When using -Y external -H ldapi:///, the local uid is passed to the server as peer credential. For example, if you run them as root, the credential becomes "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
    • Debian configures a cn=admin,dc=example,dc=com out of the box, so you specify -D cn=admin,dc=example,dc=com if you use -H ldap://host or -H ldaps://host.
  • slapcat, slapadd: these are brute force tools to access the slap database on the local filesystem.
The privilege to modify LDAP and olc is defined in olc itself. On Debian out of the box:
  • dc=example,dc=com can be written by cn=admin,dc=example,dc=com.
  • cn=config cannot be viewed nor modified by cn=admin,dc=example,dc=com.
    • It mentions olcRootDN: cn=admin,cn=config but there is no such dn in the database.
    • It allows "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" to modify this database.
    • Must use -Y external -H ldapi:/// for ldap* tools, or use slap* tools.
    • In theory you could change olcAccess so that cn=admin,dc=example,dc=com can view and make changes. I've decided not to bother.
Importing schema is a pain. The specific steps for Ubuntu Kerberos/LDAP is what worked for me. Generalize this for other things like Samba.
  • First create an input.conf in the old slapd.conf format. All schema prerequisites must be included.
  • Use slapcat -f input.conf -F output/ -n0 to preview the resulting ldif.
    • Identify the dn of the schema you actually want to import (sans the prerequisites if they're already imported),
    • Add -s 'cn={n}foo,cn=schema,cn=config' (change n and foo as appropriate) to slapcat
    • Pipe the ldif to a file.
  • Edit the ldif file and replace {n}foo with just foo (e.g. in the dn: and cn: entries), and remove this epilog:
    structuralObjectClass: olcSchemaConfig
    entryUUID: 76b47d96-5f66-1032-93e8-7152dc9f0505
    creatorsName: cn=config
    createTimestamp: 20130602002359Z
    entryCSN: 20130602002359.309272Z#000000#000#000000
    modifiersName: cn=config
    modifyTimestamp: 20130602002359Z
    
  • Use ldapadd -Y external -H ldapi:/// to import.
    • If you get ldap_bind: Invalid credentials (49), that's because you're still using the cn=admin,cn=config user which is not configured.
    • If you get ldap_add: Insufficient access (50), that's because you're still using the cn=admin,dc=example,dc=com user which does not have access to cn=config.
A special note about Samba: Debian's Samba Server Setup said I should restrict access to sambaLMPassword and sambaNTPassword. It's a good practice if you store Samba passwords in LDAP. Otherwise people will be able to enumerate the hashes and crack them. I will be using Kerberos so don't need to bother. Just configure it in olcAccess so krbPrincipalKey is not revealed. See the Ubuntu Kerberos/LDAP guide.

I will be using ldapscripts instead of smbldap-tools to add/modify users.

Once Kerberos is setup, one thing I found convenient is to authenticate to LDAP using Kerberos. This is what I did:
~# apt-get install libsasl2-modules-gssapi-mit
~# kadmin root/admin
kadmin:  addprinc ldap/host.example.com
kadmin:  ktadd -k /etc/ldap/krb5.keytab ldap/host.example.com
kadmin:  exit
~# chown openldap.openldap /etc/ldap/krb5.keytab
~# echo "export KRB5_KTNAME='FILE:/etc/ldap/krb5.keytab'" >> /etc/defaults/slapd
~# service slapd restart
And now once I kinit, I can run ldap* commands without entering password! Don't use saslauthd. It's a deadend.

I also find Setting up a Linux server for OS X clients, Portable Home Directories w/ OpenLDAP, and Apple OS X Integration With OpenLDAP helpful.

1 comment:

Likai Liu said...

After a year and half, I can confidently say that LDAP is such a stupid idea. I ended up deprecating LDAP and replaced it with NIS instead.