diff options
Diffstat (limited to 'ldap1.adoci')
| -rw-r--r-- | ldap1.adoci | 213 |
1 files changed, 0 insertions, 213 deletions
diff --git a/ldap1.adoci b/ldap1.adoci deleted file mode 100644 index 4c8b452..0000000 --- a/ldap1.adoci +++ /dev/null @@ -1,213 +0,0 @@ -== 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 '<PREFIX>' with slapd's -configuration directory). - - include <PREFIX>/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). - |