OpenLDAP 2.4.11 - Revision history

Saruman!: moved OpenLDAP to OpenLDAP 2.4.11: new ldap version

2011-04-12T19:45:50Z

moved OpenLDAP to OpenLDAP 2.4.11: new ldap version

← Older revision	Revision as of 19:45, 12 April 2011
(No difference)

Saruman!: /* OpenLDAP configuration */ divided global and backend directives

2009-07-26T16:16:07Z

OpenLDAP configuration: divided global and backend directives

← Older revision		Revision as of 16:16, 26 July 2009
Line 28:		Line 28:

	==OpenLDAP configuration==		==OpenLDAP configuration==
			To finetune the OpenLDAP configuration, we make some changes to the main configuration file for the OpenLDAP server, ''/etc/ldap/slapd.conf''. Note: make SURE that the permissions on this file are rw-r----- (640) and the owner is ''root:openldap'', so that OpenLDAP can read the configuration, but only you can change it.

			When changing the configuration of your LDAP server, keep in mind that everything ''above'' the first ''backend hdb'' (or ''backend <something>'') should contain only global directives, and everything under it only backend directives that will apply to all databases that you're going to run under that backend type. In our examples, we're only going to run a single database of a single backend type, so all backend directives will apply to our single database. Nevertheless, you should put your global directives above the backend declaration, and the rest below.

	~~To finetune~~ the ~~OpenLDAP configuration, we make some changes to~~ the ~~main configuration~~ file ~~for the OpenLDAP server, ''~~/etc/ldap/~~slapd~~.~~conf''~~. ~~Note: make SURE that the permissions on this file are rw-r-----~~ (~~640~~) ~~and~~ the ~~owner is ''root:openldap'', so~~ that ~~OpenLDAP can read the configuration, but only you can change it~~.		===global directives===
			We check to be certain all necessary '''schemas''' are included: in the beginning of the file we should see
			include /etc/ldap/schema/core.schema
			include /etc/ldap/schema/cosine.schema
			include /etc/ldap/schema/nis.schema
			include /etc/ldap/schema/inetorgperson.schema
			If any line got missing, we need to (re)enter it in order to be able to create the LDAP entries that we want.

	We find the line beginning with "loglevel" and change it from ''none'' to ''256''. This value means connections/operations/results wil be logged to the ''syslogd'' daemon. There, it will be logged to the ''LOG_LOCAL4'' facility.		We find the line beginning with '''loglevel''' and change it from ''none'' to ''256''. This value means connections/operations/results wil be logged to the ''syslogd'' daemon. There, it will be logged to the ''LOG_LOCAL4'' facility.

	The default hash algorithm for encrypting user passwords is {SSHA}, which is the SHA-1 algorithm (FIPS160-1) wit a seed number. However, OpenLDAP can understand more hashes, even multiple at the same time. To specify which hash or hashes, we can specify something like		The default hash algorithm for '''encrypting user passwords''' is {SSHA}, which is the SHA-1 algorithm (FIPS160-1) wit a seed number. However, OpenLDAP can understand more hashes, even multiple at the same time. To specify which hash or hashes, we can specify something like
	password-hash {SSHA} {MD5}		password-hash {SSHA}
			password-hash {MD5}
	Valid hashes are {SHA}, {SSHA} (the default), {MD5}, {SMD5}, {CRYPT} and {CLEARTEXT}. We usually don't need to change the default, but if you do, put in the directive and restart your LDAP server. More information: "man 5 slapd.conf".		Valid hashes are {SHA}, {SSHA} (the default), {MD5}, {SMD5}, {CRYPT} and {CLEARTEXT}. We usually don't need to change the default, but if you do, put in the directive and restart your LDAP server. More information: "man 5 slapd.conf".

	We find the line beginning with ''index'', and add ~~a second line~~ to it. This will make the section look like this:		===backend directives===
			We find the line beginning with ''index'', and add one or more lines under it, containing the attributes that we would like to be indexed. For starters, we would advise you to index not only ''objectClass'', but also ''uid'' and ''memberUid''. This will make the section look like this:
	index objectClass eq		index objectClass eq
	index uid eq		index uid eq
	index memberUid eq		index memberUid eq
	The purpose of this change is to make the OpenLDAP server create another index, on LDAP attribute ''uid'', and another one on LDAP attribute ''memberUid''. The ''uid'' index is important, because under some circumstances you might not receive any result on a valid query unless the searched entries are indexed. This entry makes sure all objects with a ''uid'' attribute are indexed, and thus can be found when queried. The ''memberUid'' index is not so important, but creating it will prevent a lot of informational messages in our syslog that go like		The purpose of this change is to make the OpenLDAP server create another index, on LDAP attribute ''uid'', and another one on LDAP attribute ''memberUid''. The ''uid'' index is important, because under some circumstances you might not receive any result on a valid query unless the searched entries are indexed. This entry makes sure all objects with a ''uid'' attribute are indexed, and thus can be found when queried. The ''memberUid'' index is not so important, but creating it will prevent a lot of informational messages in our syslog that go like
	Nov 9 20:24:40 dworkin slapd[13998]: <= bdb_equality_candidates: (memberUid) not indexed		Nov 9 10:24:40 dworkin slapd[13998]: <= bdb_equality_candidates: (memberUid) not indexed

	~~Finally, we check to be certain all necessary schema's are included: in the beginning of the file we should see~~
	~~include /etc/ldap/schema/core.schema~~
	~~include /etc/ldap/schema/cosine.schema~~
	~~include /etc/ldap/schema/nis.schema~~
	~~include /etc/ldap/schema/inetorgperson.schema~~
	~~If any line got missing, we need to (re)enter it in order to be able to create the LDAP entries that we want.~~

	After these little refinements, we must stop, reindex, and restart the OpenLDAP server. This can be done with the following sequence of commands:		After these little refinements, we must stop, reindex, and restart the OpenLDAP server. This can be done with the following sequence of commands:
Line 56:		Line 60:
	sudo invoke-rc.d slapd start		sudo invoke-rc.d slapd start
	Note: you need to have your ''sudo'' configured to allow you to ''su'' to user ''openldap'' in order to run the second command.		Note: you need to have your ''sudo'' configured to allow you to ''su'' to user ''openldap'' in order to run the second command.


	==Installing and configuring an LDAP Account Manager==		==Installing and configuring an LDAP Account Manager==

Saruman!: split install and config

2009-07-26T10:14:00Z

split install and config

← Older revision		Revision as of 10:14, 26 July 2009
Line 1:		Line 1:
	== OpenLDAP installation ~~and configuration~~==		== OpenLDAP installation==

	Note: we're going to install OpenLDAP on our server as [http://www.openldap.org/doc/admin24/config.html#Local%20Directory%20Service the local directory service], without replication, referrals or other advanced features.		Note: we're going to install OpenLDAP on our server as [http://www.openldap.org/doc/admin24/config.html#Local%20Directory%20Service the local directory service], without replication, referrals or other advanced features.
Line 5:		Line 5:
	Installing OpenLDAP on your Debian server is ridiculously simple. Just make sure your server is up-to-date (''sudo apt-get update'' followed by ''sudo apt-get upgrade''), and then install the two main components for your OpenLDAP server:		Installing OpenLDAP on your Debian server is ridiculously simple. Just make sure your server is up-to-date (''sudo apt-get update'' followed by ''sudo apt-get upgrade''), and then install the two main components for your OpenLDAP server:
	sudo apt-get install slapd ldap-utils		sudo apt-get install slapd ldap-utils
	The Debian configuration script will ask you for only one single thing: an administrator password. As always: generate a strong password! When you've provided the password, the LDAP database is created with the administrator name "admin" and as a base directory path, something based on your DNS name. Suppose your internal domain is "amber.lan.", then the script will generate ''suffix "dc=amber,dc=lan~~,dc=~~"''~~. The last~~, empty, domain component (''dc'') is caused by ~~the~~ trailing dot in your DNS name: the DNS root.		The Debian configuration script will ask you for only one single thing: an administrator password. As always: generate a strong password! When you've provided the password, the LDAP database is created with the administrator name "admin" and as a base directory path, something based on your DNS name. Suppose your internal domain is "amber.lan", then the script will generate ''suffix "dc=amber,dc=lan"''<ref>Should you see a third, empty, domain component (''dc='') then this is caused by a trailing dot in your particular DNS name: the DNS root. You might have specified your domain as "amber.lan.". You ''should'' change your domain name to a name without the DNS root, and you ''must'' regenerate your LDAP directory.</ref>.

	Since this might not always be the most convenient configuration, we recommend that you run the configuration again using ''dpkg-reconfigure slapd''. Interestingly enough, this reconfiguration asks you many ''more'' questions. The answers could look like this:		Since this might not always be the most convenient configuration, we recommend that you run the configuration again using ''dpkg-reconfigure slapd''. Interestingly enough, this reconfiguration asks you many ''more'' questions. The answers could look like this:
Line 16:		Line 16:
	Move old DB: yes		Move old DB: yes
	Allow LDAPv2: no		Allow LDAPv2: no
	As you can see, the reconfiguration yields much more configuration options than plain installation - although really you'll probably answer most questions with their default values anyway, with the exception of the database backend, which by default is BDB.<br>		As you can see, the reconfiguration yields much more configuration options than plain installation - although really you'll probably answer most questions with their default values anyway, with the exception of the database backend, which by default is BDB (see further down for the difference between BDB and HDB).<br>
	Anyway, the above method of configuring yields you an LDAP database with only two objects in it:		Anyway, the above method of configuring yields you an LDAP database with only two objects in it:
	* a single Organization (o="Saruman") with Distinguished Name dn="dc=saruman,dc=biz"		* a single Organization (o="Saruman") with Distinguished Name dn="dc=saruman,dc=biz"
	* a single administrator with Common Name cn="admin", and dn="cn=admin,dc=saruman,dc=biz"		* a single administrator with Common Name cn="admin", and dn="cn=admin,dc=saruman,dc=biz"

	The database that your OpenLDAP server uses is a standard Berkeley DB (BDB) database. Now we most likely will require some other databases as well in our server setup, something modern like PostgreSQL or MySQL - so why don't we configure our OpenLDAP to use this same database as well? For the answer, see [http://www.openldap.org/doc/admin24/intro.html#LDAP%20vs%20RDBMS here] - in short, the LDAP tree structure does not lend itself very well to inclusion in a modern relational database. Thus, we advise to stick with the Berkeley database provided with OpenLDAP.~~<br>~~		The database that your OpenLDAP server uses is a standard Berkeley DB (BDB/HDB) database. Now we most likely will require some other databases as well in our server setup, something modern like PostgreSQL or MySQL - so why don't we configure our OpenLDAP to use this same database as well? For the answer, see [http://www.openldap.org/doc/admin24/intro.html#LDAP%20vs%20RDBMS here] - in short, the LDAP tree structure does not lend itself very well to inclusion in a modern relational database. Thus, we advise to stick with the Berkeley database provided with OpenLDAP.

	Now, for the database backend, we have the choice between two almost identical flavours: the ''bdb'' backend is the recommended primary backend for a normal slapd database. It uses the Oracle Berkeley DB package, referred to as ''BDB'', to store data. It makes extensive use of indexing and caching to speed data access. ''hdb'' is a variant of the ''bdb'' backend that uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the ''bdb'' behavior, and all the same configuration options apply.		Now, for the database backend, we have the choice between two almost identical flavours: the ''bdb'' backend is the recommended primary backend for a normal slapd database. It uses the Oracle Berkeley DB package, referred to as ''BDB'', to store data. It makes extensive use of indexing and caching to speed data access. ''hdb'' is a variant of the ''bdb'' backend that uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the ''bdb'' behavior, and all the same configuration options apply.

	To finetune the OpenLDAP configuration, we make some changes to the main configuration file for the OpenLDAP server, ''/etc/ldap/slapd.conf''. Note: make SURE that the permissions on this file are rw-r----- (640) and the owner is root:openldap.		<references/>

			==OpenLDAP configuration==

			To finetune the OpenLDAP configuration, we make some changes to the main configuration file for the OpenLDAP server, ''/etc/ldap/slapd.conf''. Note: make SURE that the permissions on this file are rw-r----- (640) and the owner is ''root:openldap'', so that OpenLDAP can read the configuration, but only you can change it.

	We find the line beginning with "loglevel" and change it from ''none'' to ''256''. This value means connections/operations/results wil be logged to the ''syslogd'' daemon. There, it will be logged to the ''LOG_LOCAL4'' facility.		We find the line beginning with "loglevel" and change it from ''none'' to ''256''. This value means connections/operations/results wil be logged to the ''syslogd'' daemon. There, it will be logged to the ''LOG_LOCAL4'' facility.
Line 30:		Line 35:
	The default hash algorithm for encrypting user passwords is {SSHA}, which is the SHA-1 algorithm (FIPS160-1) wit a seed number. However, OpenLDAP can understand more hashes, even multiple at the same time. To specify which hash or hashes, we can specify something like		The default hash algorithm for encrypting user passwords is {SSHA}, which is the SHA-1 algorithm (FIPS160-1) wit a seed number. However, OpenLDAP can understand more hashes, even multiple at the same time. To specify which hash or hashes, we can specify something like
	password-hash {SSHA} {MD5}		password-hash {SSHA} {MD5}
	Valid hashes are {SHA}, {SSHA} (the default, {MD5}, {SMD5}, {CRYPT} and {CLEARTEXT}. We usually don't need to change the default, but if you do, put in the directive and restart your LDAP server. More information: "man 5 slapd.conf".		Valid hashes are {SHA}, {SSHA} (the default), {MD5}, {SMD5}, {CRYPT} and {CLEARTEXT}. We usually don't need to change the default, but if you do, put in the directive and restart your LDAP server. More information: "man 5 slapd.conf".

	We find the line beginning with ''index'', and add a second line to it. This will make the section look like this:		We find the line beginning with ''index'', and add a second line to it. This will make the section look like this:
Line 51:		Line 56:
	sudo invoke-rc.d slapd start		sudo invoke-rc.d slapd start
	Note: you need to have your ''sudo'' configured to allow you to ''su'' to user ''openldap'' in order to run the second command.		Note: you need to have your ''sudo'' configured to allow you to ''su'' to user ''openldap'' in order to run the second command.


	==Installing and configuring an LDAP Account Manager==		==Installing and configuring an LDAP Account Manager==

Saruman!: added memberUid index

2008-11-09T20:32:52Z

added memberUid index

← Older revision		Revision as of 20:32, 9 November 2008
Line 35:		Line 35:
	index objectClass eq		index objectClass eq
	index uid eq		index uid eq
	The purpose of this change is to make the OpenLDAP server create another index, on LDAP attribute ''uid''. ~~This~~ is important, because under some circumstances you might not receive any result on a valid query unless the searched entries are indexed. This entry makes sure all objects with a ''uid'' attribute are indexed, and thus can be found when queried.		index memberUid eq
			The purpose of this change is to make the OpenLDAP server create another index, on LDAP attribute ''uid'', and another one on LDAP attribute ''memberUid''. The ''uid'' index is important, because under some circumstances you might not receive any result on a valid query unless the searched entries are indexed. This entry makes sure all objects with a ''uid'' attribute are indexed, and thus can be found when queried. The ''memberUid'' index is not so important, but creating it will prevent a lot of informational messages in our syslog that go like
			Nov 9 20:24:40 dworkin slapd[13998]: <= bdb_equality_candidates: (memberUid) not indexed

	Finally, we check to be certain all necessary schema's are included: in the beginning of the file we should see		Finally, we check to be certain all necessary schema's are included: in the beginning of the file we should see

Saruman!: /* OpenLDAP installation and configuration */ added slapd.conf permissions

2008-09-28T18:38:09Z

OpenLDAP installation and configuration: added slapd.conf permissions

← Older revision		Revision as of 18:38, 28 September 2008
Line 24:		Line 24:
	Now, for the database backend, we have the choice between two almost identical flavours: the ''bdb'' backend is the recommended primary backend for a normal slapd database. It uses the Oracle Berkeley DB package, referred to as ''BDB'', to store data. It makes extensive use of indexing and caching to speed data access. ''hdb'' is a variant of the ''bdb'' backend that uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the ''bdb'' behavior, and all the same configuration options apply.		Now, for the database backend, we have the choice between two almost identical flavours: the ''bdb'' backend is the recommended primary backend for a normal slapd database. It uses the Oracle Berkeley DB package, referred to as ''BDB'', to store data. It makes extensive use of indexing and caching to speed data access. ''hdb'' is a variant of the ''bdb'' backend that uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the ''bdb'' behavior, and all the same configuration options apply.

	To finetune the OpenLDAP configuration, we make some changes to the main configuration file for the OpenLDAP server, ''/etc/ldap/slapd.conf'':		To finetune the OpenLDAP configuration, we make some changes to the main configuration file for the OpenLDAP server, ''/etc/ldap/slapd.conf''. Note: make SURE that the permissions on this file are rw-r----- (640) and the owner is root:openldap.

	We find the line beginning with "loglevel" and change it from ''none'' to ''256''. This value means connections/operations/results wil be logged to the ''syslogd'' daemon. There, it will be logged to the ''LOG_LOCAL4'' facility.		We find the line beginning with "loglevel" and change it from ''none'' to ''256''. This value means connections/operations/results wil be logged to the ''syslogd'' daemon. There, it will be logged to the ''LOG_LOCAL4'' facility.

Saruman!: /* Where to go from here */ shell access link toegevoegd

2008-09-28T16:46:51Z

Where to go from here: shell access link toegevoegd

← Older revision		Revision as of 16:46, 28 September 2008
Line 102:		Line 102:

	==Where to go from here==		==Where to go from here==
	This completes the setup of the LDAP server. To fill it with relevant data, go to [[Filling an OpenLDAP database \| the next section]].		This completes the setup of the LDAP server.
			* To fill it with relevant data, go to [[Filling an OpenLDAP database \| the next section]].
			* To set your system to accept LDAP users logging in to the machine, [[Accessing_a_shell_with_LDAP_authentication \| go here]].

Saruman!: end section

2008-09-28T16:43:02Z

end section

← Older revision		Revision as of 16:43, 28 September 2008
Line 101:		Line 101:
	Until just now, all communications with LAM have taken place over unencrypted connections - not a nice way to work in a production environment. We really need to use SSL to secure the LAM environment. Fortunately, that is as easy as enabling SSL on the underlying Apache2 webserver.		Until just now, all communications with LAM have taken place over unencrypted connections - not a nice way to work in a production environment. We really need to use SSL to secure the LAM environment. Fortunately, that is as easy as enabling SSL on the underlying Apache2 webserver.

			==Where to go from here==
	This completes the setup of the LDAP server. To fill it with relevant data, go to [[Filling an OpenLDAP database \| the next section]].		This completes the setup of the LDAP server. To fill it with relevant data, go to [[Filling an OpenLDAP database \| the next section]].

Saruman!: /* OpenLDAP installation and configuration */ added password-hash

2008-09-27T09:58:13Z

OpenLDAP installation and configuration: added password-hash

← Older revision		Revision as of 09:58, 27 September 2008
Line 27:		Line 27:

	We find the line beginning with "loglevel" and change it from ''none'' to ''256''. This value means connections/operations/results wil be logged to the ''syslogd'' daemon. There, it will be logged to the ''LOG_LOCAL4'' facility.		We find the line beginning with "loglevel" and change it from ''none'' to ''256''. This value means connections/operations/results wil be logged to the ''syslogd'' daemon. There, it will be logged to the ''LOG_LOCAL4'' facility.

			The default hash algorithm for encrypting user passwords is {SSHA}, which is the SHA-1 algorithm (FIPS160-1) wit a seed number. However, OpenLDAP can understand more hashes, even multiple at the same time. To specify which hash or hashes, we can specify something like
			password-hash {SSHA} {MD5}
			Valid hashes are {SHA}, {SSHA} (the default, {MD5}, {SMD5}, {CRYPT} and {CLEARTEXT}. We usually don't need to change the default, but if you do, put in the directive and restart your LDAP server. More information: "man 5 slapd.conf".

	We find the line beginning with ''index'', and add a second line to it. This will make the section look like this:		We find the line beginning with ''index'', and add a second line to it. This will make the section look like this:

Saruman!: /* OpenLDAP installation and configuration */ added indexing

2008-09-25T16:37:29Z

OpenLDAP installation and configuration: added indexing

@@ Line 23: / Line 23: @@
 The database that your OpenLDAP server uses is a standard Berkeley DB (BDB) database. Now we most likely will require some other databases as well in our server setup, something modern like PostgreSQL or MySQL - so why don't we configure our OpenLDAP to use this same database as well? For the answer, see [http://www.openldap.org/doc/admin24/intro.html#LDAP%20vs%20RDBMS here] - in short, the LDAP tree structure does not lend itself very well to inclusion in a modern relational database. Thus, we advise to stick with the Berkeley database provided with OpenLDAP.<br>
 Now, for the database backend, we have the choice between two almost identical flavours: the ''bdb'' backend is the recommended primary backend for a normal slapd database. It uses the Oracle Berkeley DB package, referred to as ''BDB'', to store data. It makes extensive use of indexing and caching to speed data access. ''hdb'' is a variant of the ''bdb'' backend that uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the ''bdb'' behavior, and all the same configuration options apply.
 ==Installing and configuring an LDAP Account Manager==

Saruman!: split off entering accounts to separate page

2008-09-25T15:49:41Z

split off entering accounts to separate page

← Older revision		Revision as of 15:49, 25 September 2008
Line 75:		Line 75:
	Until just now, all communications with LAM have taken place over unencrypted connections - not a nice way to work in a production environment. We really need to use SSL to secure the LAM environment. Fortunately, that is as easy as enabling SSL on the underlying Apache2 webserver.		Until just now, all communications with LAM have taken place over unencrypted connections - not a nice way to work in a production environment. We really need to use SSL to secure the LAM environment. Fortunately, that is as easy as enabling SSL on the underlying Apache2 webserver.

	~~==Migrating User, Password and Group entries to an~~ LDAP server==		This completes the setup of the LDAP server. To fill it with relevant data, go to [[Filling an OpenLDAP database \| the next section]].
	~~It's nice to have an LDAP, but~~ it~~'s ''much'' nicer if it is filled~~ with ~~information. We'll try~~ to ~~enter all existing users and groups from the host server into LDAP, using~~ [[~~Migrating existing Unix users to~~ OpenLDAP \| the ~~available migration tools~~]].

	~~==Creating new users ==~~
	~~If we need new users (e.g. when the server you're setting up is spankin' new) then we can create them in several ways. Let's discuss two of them:~~

	~~=== Adding a user with an LDIF file===~~
	~~To add a user with the LDAP command line utilities, we first need to create an LDIF file. This file is a simple text file, that could look something like this:~~
	~~# Create the user group~~
	~~dn: cn=networkusers,ou=groups,dc=saruman,dc=biz~~
	~~objectClass: posixGroup~~
	~~description: Internal network users~~
	~~gidNumber: 10001~~
	~~cn: TestGroup~~

	~~# Create a new user:~~
	~~dn: uid=sixpacjo,ou=people,dc=saruman,dc=biz~~
	~~objectclass: top~~
	~~objectclass: inetOrgPerson~~
	~~objectclass: posixAccount~~
	~~objectclass: shadowAccount~~
	~~cn: Joe Sixpack~~
	~~description: Your Average Network User~~
	~~givenName: Joe~~
	~~sn: Sixpack~~
	~~mail: joe.sixpack@saruman.biz~~
	~~# The Unix login-name for the user:~~
	~~uid: sixpacjo~~
	~~# The group and user IDs:~~
	~~gidNumber: 10001~~
	~~uidNumber: 10001~~
	~~# The Unix account data:~~
	~~homeDirectory: /home/sixpacjo~~
	~~loginShell: /bin/bash~~
	~~# The encrypted password for the user:~~
	~~userPassword: {crypt}$1$qs70ynbk$UBuewN7ZdIvqavIxkxdmX0~~
	~~AHA! you'll say. But how do I get to this encrypted password? It's simple. Try this:~~
	~~openssl passwd -crypt "secret"~~
	The argument ''-crypt'' makes openssl generate a password using the standard Unix password algorithm; this is also the default setting. An alternative would be to use ''-1'' instead of ''-crypt'', which'll give you an MD5 encrypted password. Ofcourse, using an MD5 encrypted password means you have to change the last line of the LDIF file to
	~~userPassword: {MD5}$1$yCuyTf63$NoAjuX/dYBmE29hXrsDb41~~
	Note that prefixing the used encryption method is totally fine with OpenLDAP, but it actually is not according to the LDAP standard; this LDIF file can be understood by OpenLDAP, but not by every other piece of LDAP software out there...

	~~Back to the LDIF file.~~

	~~=== Adding a user with LAM===~~