Now that we’ve installed the openLDAP server, it is possible to add data to it. Data in a directory is modelled as a tree (called a DIT for directory information tree). We’ve created the root of the tree when we installed and configured slapd. The root or top of the tree is the “base” entry and it has a distinguished name of “dc=telperion,dc=org”. We want to add a user branch (called “people”) and a group branch (called “groups”). Entries in the “people” branch of the DIT are leaves of the tree and contain the uid and other information about users. Entries in the “groups” branch are leaves and contain information about Unix groups.

We’ll create a user named “lobelia” who is a member of the group “telperionusers”. The tree looks like this:

If we were to add more users and another special group for privileged users, the tree may expand to look something like this:

To create the user, we’ll create the tree in an LDIF file (we’ll name this one add-user.ldif). A unix user needs more than just a name. Even if Lobelia doesn’t get the keys to Bag End, she’ll at least need a home directory.

dn: ou=people,dc=telperion,dc=org
objectClass: organizationalUnit
ou: people

dn: ou=groups,dc=telperion,dc=org
objectClass: organizationalUnit
ou: groups

dn: cn=telperionusers,ou=groups,dc=telperion,dc=org
objectClass: posixGroup
cn: telperionusers
gidNumber: 5000

dn: uid=lobelia,ou=people,dc=telperion,dc=org
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: lobelia
sn: Sackville-Baggins
givenName: Lobelia
cn: Lobelia Sackville-Baggins
displayName: Lobelia
uidNumber: 10000
gidNumber: 5000
userPassword: lobelialdappassword
gecos: Lobelia Sackville-Baggins
loginShell: /bin/bash
homeDirectory: /home/lobelia

Use ldapadd command to add the user by passing the LDIF file.

root@barad-dur:~# ldapadd -x -D cn=admin,dc=telperion,dc=org -W -f add-user.ldif 
Enter LDAP Password: 
adding new entry "ou=people,dc=telperion,dc=org"

adding new entry "ou=groups,dc=telperion,dc=org"

adding new entry "cn=telperionusers,ou=groups,dc=telperion,dc=org"

adding new entry "uid=lobelia,ou=people,dc=telperion,dc=org"

Now that we’ve added a user, we can lookup that user by using ldapsearch. This ldapsearch command looks in the base tree “dc=telperion,dc-org” for an entry with a “uid” attribute equal to “lobelia”. It also displays the cn, the uidNumber, and the gidNumber.

root@barad-dur:~# ldapsearch -x -LLL -b dc=telperion,dc=org 'uid=lobelia' cn uidNumber gidNumber userPassword
dn: uid=lobelia,ou=people,dc=telperion,dc=org
cn: Lobelia Sackville-Baggins
uidNumber: 10000
gidNumber: 5000

The default access control list does not let a user other than lobelia access her password.  You can see that it was not displayed even though it was requested.  We can now authenticate as lobelia (either local or from another server) to see the password (stored as a hash)

dave@fangorn:~/ldapsetup$ ldapsearch -x -D uid=lobelia,ou=people,dc=telperion,dc=org -W -LLL -H ldap://barad-dur.telperion.org -b dc=telperion,dc=org uid=lobelia userPassword
Enter LDAP Password: <type 'lobelialdappassword'>
dn: uid=lobelia,ou=people,dc=telperion,dc=org
userPassword:: bG9iZWxpYWxkYXBwYXNzd29yZA==

We can see the default access control lists by querying the config file information on database access:

root@barad-dur:~# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b olcDatabase={1}mdb,cn=config olcAccess
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read

Access Control Lists (ACLs) are parsed and the first one found that matches the situation is applied. When we searched earlier for lobelia’s password, the userPassword attribute was found and because we were anonymously logging in, we were given the “none” access. When we logged in as lobelia and requested the password, lobelia matched as “self” and we were given read access to the userPassword attribute value (write implies read access). The second access control statement defines access to the shadowLastChange attribute. A user can update it (self) and all users can read it. The third access control statement permits read access to everything else.

Now that lobelia has access, she probably should change her password. We haven’t configured any front ends to handle this yet and we can use ldapmodify to update the password field but ldap utils provides the ldappasswd command explicitly for this purpose. After changing the password, we can verify that it changed by authenticating with it to perform an ldapsearch.

dave@fangorn:~$ ldappasswd -x -D uid=lobelia,ou=people,dc=telperion,dc=org -H ldap://barad-dur.telperion.org -w lobelialdappassword -a lobelialdappassword -s ihatebilbo
davd@fangorn:~$ ldapsearch -x -D uid=lobelia,ou=people,dc=telperion,dc=org -LLL -H ldap://barad-dur.telperion.org -w  ihatebilbo -b uid=lobelia,ou=people,dc=telperion,dc=org
dn: uid=lobelia,ou=people,dc=telperion,dc=org
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: lobelia
sn: Sackville-Baggins
givenName: Lobelia
cn: Lobelia Sackville-Baggins
displayName: Lobelia
uidNumber: 10000
gidNumber: 5000
gecos: Lobelia Sackville-Baggins
loginShell: /bin/bash
homeDirectory: /home/lobelia
userPassword:: e1NTSEF9dmJ5N0Iwbk5IeEx1VXR0WjBXSWRUQVdrQWlXRlpsSzQ=

We performed the password update from the fangorn client computer. Cool, right? NO. Not cool. All of that traffic was sent in cleartext over an open network. Eventually we can authenticate with SASL and kerberos but first, we can encrypt the transport layer with TLS to prevent little golems from stealing password information. I’ll cover that in another post.