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.
- 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.
- 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.
- 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.
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 restartAnd 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:
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.
Post a Comment