1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
== 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: 80101
-
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=toto of Kent,c=gb
> objectClass: organizationalPerson
> objectClass: pkiUser
> objectClass: pmiUser
> objectClass: uidObject
> sn: gayot
> cn: Olivier Gayot
> uid: 80101
> 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).
|
