First, you have to establish a name for your store. In my case, this is dc=mox,dc=net, for my domain mox.net.

Packages you will need to install: openldap-servers, openldap-clients

Once you have those, you’ll need to add a special schema file that makes SSH play nice. It goes in /etc/openldap/schema/ldapns.schema, and looks like this:

attributetype ( 1.3.6.1.4.1.5322.17.2.1 NAME 'authorizedService'
DESC 'IANA GSS-API authorized service name'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

objectclass ( 1.3.6.1.4.1.5322.17.1.1 NAME 'authorizedServiceObject'
DESC 'Auxiliary object class for adding authorizedService attribute'
SUP top
AUXILIARY
MAY authorizedService )

objectclass ( 1.3.6.1.4.1.5322.17.1.2 NAME 'hostObject'
DESC 'Auxiliary object class for adding host attribute'
SUP top
AUXILIARY
MAY host )

Now, at the top of your /etc/openldap/slapd.conf file, there are some includes. You’ll need to add to that list so that it includes our new schema listed above. My includes section looks like this:

include        /etc/openldap/schema/core.schema
include        /etc/openldap/schema/cosine.schema
include        /etc/openldap/schema/inetorgperson.schema
include        /etc/openldap/schema/nis.schema
include        /etc/openldap/schema/ldapns.schema

The entirety of non-commented, non-blank lines from my /etc/openldap/slapd.conf:

include        /etc/openldap/schema/core.schema
include        /etc/openldap/schema/cosine.schema
include        /etc/openldap/schema/inetorgperson.schema
include        /etc/openldap/schema/nis.schema
include        /etc/openldap/schema/ldapns.schema
idletimeout 30
allow bind_v2
sasl-regexp     "uid=(.+),cn=login,cn=auth"
"ldap:///ou=People,dc=mox,dc=net??sub?(uid=$1)"
sasl-regexp     "uid=(.+),cn=plain,cn=auth"
"ldap:///ou=People,dc=mox,dc=net??sub?(uid=$1)"
sasl-regexp     "uid=(.+),cn=cram-md5,cn=auth"
"ldap:///ou=People,dc=mox,dc=net??sub?(uid=$1)"
sasl-regexp     "uid=(.+),cn=digest-md5,cn=auth"
"ldap:///ou=People,dc=mox,dc=net??sub?(uid=$1)"
sasl-regexp     "uid=(.+),cn=gssapi,cn=auth"
"ldap:///ou=People,dc=mox,dc=net??sub?(uid=$1)"
sasl-regexp     "uid=(.+),cn=ntlm,cn=auth"
"ldap:///ou=People,dc=mox,dc=net??sub?(uid=$1)"
pidfile        /var/run/openldap/slapd.pid
argsfile    /var/run/openldap/slapd.args
access to attrs=loginShell,shadowLastChange,userPassword
by dn="cn=Manager,dc=mox,dc=net" write
by self write
by * read
access to * by * read
database    bdb
suffix        "dc=mox,dc=net"
rootdn        "cn=Manager,dc=mox,dc=net"
rootpw        ldapadminpassword
directory    /var/lib/ldap
index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

You will need to edit to suit, of course. Leave that user named Manager alone though. That’s your “admin account” for LDAP, and it’ll poke you in the eye if you look at it wrong.

So now you should be able to start up ldap, and have it run without issue. Next up is to create some basic schema. I do this in a couple of phases. First, we have to define the “root” of our tree. I put this in a file named root.ldif:

dn: dc=mox,dc=net
objectClass: dcObject
objectClass: organization
o: mox.net
dc: mox
description: mox.net root record

Then, I define the “base nodes” that go inside the root, namely Groups and People (in SSH-land, this is /etc/passwd and /etc/group, more or less):

dn: ou=People,dc=mox,dc=net
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group,dc=mox,dc=net
ou: Group
objectClass: top
objectClass: organizationalUnit

With those defined, we need to add them to the ldap server. I do this with the following commands:

ldapadd -x -W -D cn=Manager,dc=mox,dc=net < root.ldif
ldapadd -x -W -D cn=Manager,dc=mox,dc=net < base.ldif

With those added, we now have a functional LDAP tree. There’s no users or groups in it, but it is ready for that to happen. Here’s an example user’s ldif file:

dn: cn=cmoates,ou=Group,dc=mox,dc=net
objectClass: posixGroup
objectClass: top
cn: cmoates
gidNumber: 25001
memberUid: cmoates

dn: uid=cmoates,ou=People,dc=mox,dc=net
uid: cmoates
cn: Chris Moates
givenName: Chris
sn: Moates
mail: myemailaddress@mox.net
loginShell: /bin/bash
uidNumber: 25001
gidNumber: 25001
userPassword: testpass
homeDirectory: /home/net/cmoates
telephoneNumber: 7171234567
mobile: 7172345678
street: 123 Main Street
l: Anytown
st: PA
postalCode: 12345
objectClass: top
objectClass: hostObject
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
host: *

I add this the same way as the others above, with:

ldapadd -x -W -D cn=Manager,dc=mox,dc=net < cmoates.ldif

And voila, I’m in the LDAP directory.

On a Fedora/CentOS client, you simply need to run “authconfig-tui” as root from a shell. Check the LDAP options, and it will ask you for the name of your LDAP server. Fill in the blanks, and afterwards, you should be able to do something like:

[root@bob ~]# id cmoates
uid=25001(cmoates) gid=25001(cmoates) groups=25001(cmoates)

If that works, you’re all set. SSH in as that user, using the password in LDAP. Note that the password is clear text. That’s simply for my own ease of use. You can then have the user change their password and it will crypt it automatically.

So, I hope that’s at least a start on this topic. Please let me know what problems you have with these instructions, and I’ll be glad to amend them.

Why isn’t there a distro out there that makes it trivially simple to set up VM’s of all the various popular Linux (and perhaps Solaris/*BSD?) distributions, for the purposes of testing?

I’ve been working with my friend Todd for a few days now to set something like this up. We’re using Fedora 10, Cobbler, Koan, OpenLDAP, Puppet, and a big honkin’ box. So far, so good.

I should add that the first box purchased to do this included an Intel Q8200 quad core processor. Now, being a reasonably new processor, those of us who aren’t hardware news junkies would think that this CPU would support the VT flag which allows for things like KVM to work. Not so! Apparently the entire Q8xxx line has been castrated in this manner. So, I returned that machine and picked up a Phenom X4 instead. It runs like a champ, and being my first AMD purchase in awhile, I’m not disappointed.

I’m hoping to find the time to document some of what we are doing to get all this running. Stay tuned and cross your fingers.