== OpenLDAP Practical, Week 5 == This practical is about installing and configuring an OpenLDAP LDAP server on our virtual machine. We want to setup it from source and link it with Berkeley DB backend. At the end of the practical, we should have a working LDAP directory reflecting more or less what we could have in the LDAP server of the university. === Problem 1: Unsupported version of Java VM === When running the './configure' command for the first time, it fails with > checking if java works... configure: error: The Java VM java failed (see config.log, check the CLASSPATH?) After having a look inside 'config.log', we find this error: > java.lang.UnsupportedClassVersionError unsupported major.minor version 51.0 ==== Resolution ==== This exception ('unsupported major.minor version xx.y') arises when there is a version mismatch between the Java compiler and Virtual Machine. We verifiy this assertion by issuing the following commands and checking their output: $ javac -version; java -version > javac 1.7.0_65 > java version "1.6.0_33" The output confirms that something is messed up so we fix this error by removing the package 'openjdk-6-jre-headless' which was installed for some reason. === Problem 2: schema files are read-only === When willing to modify 'etc/openldap/schema/core.schema', it turns out that the file is actually read-only. ==== Resolution ==== It is actually not advisable to directly modify the default schema files present in 'etc/openldap/schema/'. Installing them read-only is a way to tell the user not to modify them because they are likely to be overriden by an automatic process (especially by running 'make install' again). In our case, instead of modifying 'schema/core.schema', we will extend our schema by creating a 'schema/local.schema' file and write our additional schema inside. Last but not least, we have to instruct 'slapd' to include this file by adding this line in 'slapd.conf' (after replacing '' with slapd's configuration directory). include /schema/local.schema === Problem 3: writing the proper command line to add the DIT === Since we prefer using command line interfaces, we will use 'ldapadd' instead of 'Jxplorer' to create our DIT. Thus we have to understand how to use 'ldapadd' properly. ==== Resolution ==== After having a glance at the manual page 'ldapadd (1)', we find out that: - the option '-W' tells 'ldapadd' to prompt for our password but we can also supply it directly using '-w'. - the option '-D' allows us to pass the Distinguished Name - the option '-f' allows us to pass a LDIF file Thus, our command line can look something like: $ ldapadd -w secret -D 'cn=Manager,c=gb' -f file.ldif === Problem 4: writing the LDIF file === To construct our DIT, we need to write its description in the LDIF file that we will pass to 'ldapadd'. The reason why the practical advise us to create the DIT using a LDAP browser is certainly because writing a LDIF file is rather tricky the first time. ==== Resolution ==== Though the manpage of 'ldapadd' gives us a basic example of LDIF file for adding an entry, it is rather insufficient. The documentation of OpenLDAP, especially the section _LDIF text entry format_ available at the link below gives us more information, including an example with children and parent nodes. http://www.openldap.org/doc/admin24/dbtools.html#The%20LDIF%20text%20entry%20format After a few tries with different syntaxes, we finally get this error: ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax Here, the 'objectClass' refered to is 'organisation'. The problem is that it is misspelled in the practical. The real class is actually 'organization' as stated here: http://www.zytrax.com/books/ldap/ape/ The issue is actually the same with 'organisationalUnit' and 'organisationalPerson'. At this point, our LDIF file looks something like: dn: o=University of Kent,c=gb objectClass: organization dn: ou=MSc ISB,o=University of Kent,c=gb objectClass: organizationalUnit dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb objectClass: organizationalPerson objectClass: pkiUser objectClass: pmiUser After trying to add it using 'ldapadd', the LDAP server sends us this error: adding new entry "cn=Olivier Gayot,ou=MSc ISB,o=KENT,c=gb" ldap_add: Object class violation (65) additional info: object class 'organizationalPerson' requires attribute 'sn' What we understand here is that we need to add an extra attribute 'sn'. To figure out what it actually means, we can have a look in the file 'schema/core.schema', especially this section: attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name ) With that information, we can edit our LDIF file and supply our new attribute: dn: o=University of Kent,c=gb objectClass: organization dn: ou=MSc ISB,o=University of Kent,c=gb objectClass: organizationalUnit dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb objectClass: organizationalPerson objectClass: pkiUser objectClass: pmiUser sn: Gayot By using the command line below, our DIT is successfully created (the option '-c' is used here because, without it, 'ldapadd' stops because our parent nodes have already been created) $ ldapadd -w secret -D 'cn=Manager,c=gb' -f file.ldif -c === Problem 5: Modifying an entry to add other classes === To add new attributes (uid, password and role), to our freshly created user without deleting it, we need to modify its entry. Since 'ldapadd' does not permit to override an entry, we have to find another way. ==== Resolution ==== We start by having a look inside the schema files to figure out what classes and attributes we need to store our new informations. Here is a list of what we need: - an 'uidObject' class which requires a 'uid' attribute - a 'permisRole' attribute which we can be set to our desired value - a 'userPassword' attribute which will store a password in a non-plaintext format Then, by reading the manpage 'ldif (5)', we learn about the syntax of a LDIF file to modify an entry. In our case, we create another '.ldif' to handle our modification and add this content inside: dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb changetype: modify add: objectClass objectClass: uidObject - add: uid uid: ojgg2 - add: permisRole permisRole: student - add: userPassword userPassword: fooBar By running 'ldapmodify' the same way we used 'ldapadd', our entry is successfully modified. After reading the manpage 'ldapsearch (1)', we can check our result by issuing the command below and reading its output (only the interesting excerpt of the output is shown below). $ ldapsearch -H ldap://csvm2C4E.kent.ac.uk -x -b 'c=gb' '(cn=Olivier Gayot)' > # Olivier Gayot, MSc ISB, University of Kent, gb > dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb > objectClass: organizationalPerson > objectClass: pkiUser > objectClass: pmiUser > objectClass: uidObject > sn: gayot > cn: Olivier Gayot > uid: ojgg2 > permisRole: student > userPassword:: Zm9vQmFy That's it! By the way, we can note that our password 'fooBar' is stored as 'Zm9vQmFy' (its NT-OWF hashed format).