NotesOnOpenLDAP - Revision history

Jeff at 03:23, 6 September 2009

2009-09-06T03:23:23Z

←Older revision		Revision as of 03:23, 6 September 2009
Line 174:		Line 174:

	==libuser Tools==		==libuser Tools==
		+
		+	----
		+	[[User:Jeff\|Jeff]]

Jeff at 21:22, 23 June 2009

2009-06-23T21:22:14Z

←Older revision		Revision as of 21:22, 23 June 2009
Line 5:		Line 5:
	There are only a few lines needed in /etc/openldap/ldap.conf. Here is a working example:		There are only a few lines needed in /etc/openldap/ldap.conf. Here is a working example:

		+	<pre>
	URI ldap://auth/		URI ldap://auth/
	BASE dc=example,dc=com		BASE dc=example,dc=com
	TLS_CACERTDIR /etc/openldap/cacerts		TLS_CACERTDIR /etc/openldap/cacerts
	TLS_REQCERT allow		TLS_REQCERT allow
		+	</pre>

	Without this file, you would have to specify all these parameters on the command line when using ldapsearch and other tools. You can override the contents of /etc/openldap/ldap.conf in your $HOME/.ldaprc file. You can also specify alternative configuration files with the environment variables LDAPCONF and LDAPRC.		Without this file, you would have to specify all these parameters on the command line when using ldapsearch and other tools. You can override the contents of /etc/openldap/ldap.conf in your $HOME/.ldaprc file. You can also specify alternative configuration files with the environment variables LDAPCONF and LDAPRC.
Line 18:		Line 20:
	As root, do:		As root, do:

		+	<pre>
	mkdir ~/migration		mkdir ~/migration
	cd ~/migration		cd ~/migration
Line 30:		Line 33:
	w		w
	EOF		EOF
		+	</pre>

	Now that you have this configured, you can begin adding users to LDAP.		Now that you have this configured, you can begin adding users to LDAP.
Line 35:		Line 39:
	Begin by adding a normal user with the regular shadow utilities. Note that if you do not include the GECOS information (with the -c flag) then a bunch of fields will not be filled in when we migrate to LDAP.		Begin by adding a normal user with the regular shadow utilities. Note that if you do not include the GECOS information (with the -c flag) then a bunch of fields will not be filled in when we migrate to LDAP.

		+	<pre>
	useradd -c 'Joe User' -s /sbin/nologin juser		useradd -c 'Joe User' -s /sbin/nologin juser
	passwd juser		passwd juser
		+	</pre>

	Then use the migration tools to build an LDIF file of the user's data.		Then use the migration tools to build an LDIF file of the user's data.
Line 44:		Line 50:
	./migrate_group.pl <( grep juser <nowiki>/etc/</nowiki>group ) >> juser.ldif		./migrate_group.pl <( grep juser <nowiki>/etc/</nowiki>group ) >> juser.ldif
	</pre>		</pre>
		+
	Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:		Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:

		+	<pre>
	ldapadd -x -W -D 'cn=Manager,dc=example,dc=com' -f juser.ldif		ldapadd -x -W -D 'cn=Manager,dc=example,dc=com' -f juser.ldif
		+	</pre>

	Keep in mind, only migrate users corresponding to an actual employee (user ID should be 1000 or greater). Service accounts (like loguser) should exist only in the local passwd and group files.		Keep in mind, only migrate users corresponding to an actual employee (user ID should be 1000 or greater). Service accounts (like loguser) should exist only in the local passwd and group files.
Line 62:		Line 71:
	To quickly configure a server to authenticate and identify with LDAP, use the following command:		To quickly configure a server to authenticate and identify with LDAP, use the following command:

		+	<pre>
	authconfig --enableldap{,auth} --ldapserver=ldap://auth/ --ldapbasedn=dc=example,dc=com \\		authconfig --enableldap{,auth} --ldapserver=ldap://auth/ --ldapbasedn=dc=example,dc=com \\
	--enableldaptls --ldaploadcacert=file://`pwd`/cacert.pem --update		--enableldaptls --ldaploadcacert=file://`pwd`/cacert.pem --update
		+	</pre>

	However, this will configure protocols, services, netgroup, and automount in /etc/nsswitch.conf to also use ldap for lookups. This may generate more network traffic than desired if you are not using LDAP for these services. Use the following to strip those entries:		However, this will configure protocols, services, netgroup, and automount in /etc/nsswitch.conf to also use ldap for lookups. This may generate more network traffic than desired if you are not using LDAP for these services. Use the following to strip those entries:

		+	<pre>
	sed -ri '/^(passwd\|shadow\|group):/s/(files) (ldap)/\\1 [UNAVAIL=return] \\2/;		sed -ri '/^(passwd\|shadow\|group):/s/(files) (ldap)/\\1 [UNAVAIL=return] \\2/;
	/^(protocols\|services\|netgroup\|automount):/s/ ldap//' /etc/nsswitch.conf		/^(protocols\|services\|netgroup\|automount):/s/ ldap//' /etc/nsswitch.conf
		+	</pre>

	Also, the default behavior is for the NSS libraries to continue trying to bind to the server indefinitely if it is unavailable. This means it can take up to half an hour before giving up. Add the following to make sure the libraries give up when the server is unavailable:		Also, the default behavior is for the NSS libraries to continue trying to bind to the server indefinitely if it is unavailable. This means it can take up to half an hour before giving up. Add the following to make sure the libraries give up when the server is unavailable:

		+	<pre>
	echo 'bind_policy soft' >> /etc/ldap.conf		echo 'bind_policy soft' >> /etc/ldap.conf
		+	</pre>

	And finally, to perform operations which require root access, such as getent shadow or passwd, the libraries can not bind anonymously. Include the manager password in /etc/ldap.secret (mode 0400), and use the following to bind as the administrator:		And finally, to perform operations which require root access, such as getent shadow or passwd, the libraries can not bind anonymously. Include the manager password in /etc/ldap.secret (mode 0400), and use the following to bind as the administrator:

		+	<pre>
	echo 'rootbinddn cn=Manager,dc=example,dc=com' >> /etc/ldap.conf		echo 'rootbinddn cn=Manager,dc=example,dc=com' >> /etc/ldap.conf
		+	</pre>

	==LDAP Replication==		==LDAP Replication==
Line 84:		Line 101:
	Before we begin replication, the slave server must contain a full replica of the current master server's data tree. You can do this with the master still running.		Before we begin replication, the slave server must contain a full replica of the current master server's data tree. You can do this with the master still running.

		+	<pre>
	slapcat > /tmp/dump.ldif		slapcat > /tmp/dump.ldif
		+	</pre>

	Now copy this dump file over to the slave server and import it.		Now copy this dump file over to the slave server and import it.

		+	<pre>
	slapadd < /tmp/dump.ldif		slapadd < /tmp/dump.ldif
	chown -R ldap. ~ldap/		chown -R ldap. ~ldap/
		+	</pre>

	Now start the slapd daemon and it should start without error. You should be able to perform normal queries against it.		Now start the slapd daemon and it should start without error. You should be able to perform normal queries against it.
Line 95:		Line 116:
	Return to the master server. Add the following information to slapd.conf.		Return to the master server. Add the following information to slapd.conf.

		+	<pre>
	replogfile /var/lib/ldap/SUBDIRECTORY/replog		replogfile /var/lib/ldap/SUBDIRECTORY/replog
	replica host=SLAVEHOSTNAME		replica host=SLAVEHOSTNAME
Line 102:		Line 124:
	bindmethod=simple		bindmethod=simple
	tls=no		tls=no
		+	</pre>

	As you see, the replica user's password is included in plain text in this file, so it is critical that the slapd.conf file should only be readable by the ldap user. Restart the LDAP server. This time slurpd will also start.		As you see, the replica user's password is included in plain text in this file, so it is critical that the slapd.conf file should only be readable by the ldap user. Restart the LDAP server. This time slurpd will also start.
Line 107:		Line 130:
	Once again, return to the slave server. You must create the replica user. First generate the password.		Once again, return to the slave server. You must create the replica user. First generate the password.

		+	<pre>
	openssl passwd -1		openssl passwd -1
		+	</pre>

	Then create the following ldif file.		Then create the following ldif file.

		+	<pre>
	dn: cn=Replica,dc=example,dc=com		dn: cn=Replica,dc=example,dc=com
	objectClass: top		objectClass: top
Line 117:		Line 143:
	cn: Replica		cn: Replica
	userPassword: {CRYPT}GENERATE_THIS_WITH_OPENSSL		userPassword: {CRYPT}GENERATE_THIS_WITH_OPENSSL
		+	</pre>

	And add it to the database on the slave.		And add it to the database on the slave.

		+	<pre>
	ldapadd -x -W -D 'cn=Manager,dc=example,dc=com' -f replica.ldif		ldapadd -x -W -D 'cn=Manager,dc=example,dc=com' -f replica.ldif
		+	</pre>

	Finally, add the following to the slave server's slapd.conf.		Finally, add the following to the slave server's slapd.conf.

		+	<pre>
	updatedn cn=Replica,dc=example,dc=com		updatedn cn=Replica,dc=example,dc=com
	updateref ldap://MASTER_LDAP_SERVER		updateref ldap://MASTER_LDAP_SERVER
		+	</pre>

	Restart the ldap service and now any changes made on the master server will be automatically pushed to the slave server. If someone attempts to write a change to a slave server, they will get redirected to the master.		Restart the ldap service and now any changes made on the master server will be automatically pushed to the slave server. If someone attempts to write a change to a slave server, they will get redirected to the master.
Line 134:		Line 165:
	If you have a look at /var/lib/ldap on the master, you will see there is now a replica subdirectory. Inside it is a set of rej and rej.lock files for each of the slaves for any bit that the slave didn't successfully replicate. All you have to do is play back the rej file and the slave will catch up. You can't run two copies of slurpd so stop the ldap service and run slurpd in one-shot mode.		If you have a look at /var/lib/ldap on the master, you will see there is now a replica subdirectory. Inside it is a set of rej and rej.lock files for each of the slaves for any bit that the slave didn't successfully replicate. All you have to do is play back the rej file and the slave will catch up. You can't run two copies of slurpd so stop the ldap service and run slurpd in one-shot mode.

		+	<pre>
	slurpd -o -r /var/lib/ldap/replica/SLAVE:389.rej		slurpd -o -r /var/lib/ldap/replica/SLAVE:389.rej
		+	</pre>

	When it exits, restart the ldap service.		When it exits, restart the ldap service.

Jeff at 08:00, 18 June 2009

2009-06-18T08:00:08Z

←Older revision		Revision as of 08:00, 18 June 2009
Line 40:		Line 40:
	Then use the migration tools to build an LDIF file of the user's data.		Then use the migration tools to build an LDIF file of the user's data.

		+	<pre>
	./migrate_passwd.pl <( grep juser <nowiki>/etc/</nowiki>passwd ) > juser.ldif		./migrate_passwd.pl <( grep juser <nowiki>/etc/</nowiki>passwd ) > juser.ldif
-	./migrate_group.pl <( grep juser /etc;group ) >> juser.ldif	+	./migrate_group.pl <( grep juser <nowiki>/etc/</nowiki>group ) >> juser.ldif
-		+	</pre>
	Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:		Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:

Jeff at 07:58, 18 June 2009

2009-06-18T07:58:09Z

←Older revision		Revision as of 07:58, 18 June 2009
Line 40:		Line 40:
	Then use the migration tools to build an LDIF file of the user's data.		Then use the migration tools to build an LDIF file of the user's data.

-	./migrate_passwd.pl <( grep juser /etc;passwd ) > juser.ldif	+	./migrate_passwd.pl <( grep juser <nowiki>/etc/</nowiki>passwd ) > juser.ldif
	./migrate_group.pl <( grep juser /etc;group ) >> juser.ldif		./migrate_group.pl <( grep juser /etc;group ) >> juser.ldif

Jeff at 07:56, 18 June 2009

2009-06-18T07:56:27Z

←Older revision		Revision as of 07:56, 18 June 2009
Line 41:		Line 41:

	./migrate_passwd.pl <( grep juser /etc;passwd ) > juser.ldif		./migrate_passwd.pl <( grep juser /etc;passwd ) > juser.ldif
-	./migrate_group.pl <( grep juser ;etc;group ) >> juser.ldif	+	./migrate_group.pl <( grep juser /etc;group ) >> juser.ldif

	Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:		Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:

Jeff at 07:55, 18 June 2009

2009-06-18T07:55:49Z

←Older revision		Revision as of 07:55, 18 June 2009
Line 40:		Line 40:
	Then use the migration tools to build an LDIF file of the user's data.		Then use the migration tools to build an LDIF file of the user's data.

-	./migrate_passwd.pl <( grep juser ;etc;passwd ) > juser.ldif	+	./migrate_passwd.pl <( grep juser /etc;passwd ) > juser.ldif
	./migrate_group.pl <( grep juser ;etc;group ) >> juser.ldif		./migrate_group.pl <( grep juser ;etc;group ) >> juser.ldif

Jeff at 07:50, 18 June 2009

2009-06-18T07:50:52Z

←Older revision		Revision as of 07:50, 18 June 2009
Line 40:		Line 40:
	Then use the migration tools to build an LDIF file of the user's data.		Then use the migration tools to build an LDIF file of the user's data.

-	./migrate_passwd.pl <( grep juser ~~etcpasswd~~ ) > juser.ldif	+	./migrate_passwd.pl <( grep juser ;etc;passwd ) > juser.ldif
-	./migrate_group.pl <( grep juser ~~etcgroup~~ ) >> juser.ldif	+	./migrate_group.pl <( grep juser ;etc;group ) >> juser.ldif

	Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:		Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:

Jeff at 07:47, 18 June 2009

2009-06-18T07:47:09Z

←Older revision		Revision as of 07:47, 18 June 2009
Line 6:		Line 6:

	URI ldap://auth/		URI ldap://auth/
-	BASE dc=~~reachlocal~~,dc=com	+	BASE dc=example,dc=com
	TLS_CACERTDIR /etc/openldap/cacerts		TLS_CACERTDIR /etc/openldap/cacerts
	TLS_REQCERT allow		TLS_REQCERT allow
Line 25:		Line 25:

	cat <<EOF \| ed migrate_common.ph		cat <<EOF \| ed migrate_common.ph
-	/DEFAULT_MAIL_DOMAIN/s/padl.com/~~reachlocal~~.com/	+	/DEFAULT_MAIL_DOMAIN/s/padl.com/example.com/
-	/DEFAULT_BASE/s/dc=padl,dc=com/dc=~~reachlocal~~,dc=com/	+	/DEFAULT_BASE/s/dc=padl,dc=com/dc=example,dc=com/
	/EXTENDED_SCHEMA/s/0/1/		/EXTENDED_SCHEMA/s/0/1/
	w		w
Line 45:		Line 45:
	Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:		Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:

-	ldapadd -x -W -D 'cn=Manager,dc=~~reachlocal~~,dc=com' -f juser.ldif	+	ldapadd -x -W -D 'cn=Manager,dc=example,dc=com' -f juser.ldif

	Keep in mind, only migrate users corresponding to an actual employee (user ID should be 1000 or greater). Service accounts (like loguser) should exist only in the local passwd and group files.		Keep in mind, only migrate users corresponding to an actual employee (user ID should be 1000 or greater). Service accounts (like loguser) should exist only in the local passwd and group files.
Line 61:		Line 61:
	To quickly configure a server to authenticate and identify with LDAP, use the following command:		To quickly configure a server to authenticate and identify with LDAP, use the following command:

-	authconfig --enableldap{,auth} --ldapserver=ldap://auth/ --ldapbasedn=dc=~~reachlocal~~,dc=com \\	+	authconfig --enableldap{,auth} --ldapserver=ldap://auth/ --ldapbasedn=dc=example,dc=com \\
	--enableldaptls --ldaploadcacert=file://`pwd`/cacert.pem --update		--enableldaptls --ldaploadcacert=file://`pwd`/cacert.pem --update

Line 75:		Line 75:
	And finally, to perform operations which require root access, such as getent shadow or passwd, the libraries can not bind anonymously. Include the manager password in /etc/ldap.secret (mode 0400), and use the following to bind as the administrator:		And finally, to perform operations which require root access, such as getent shadow or passwd, the libraries can not bind anonymously. Include the manager password in /etc/ldap.secret (mode 0400), and use the following to bind as the administrator:

-	echo 'rootbinddn cn=Manager,dc=~~reachlocal~~,dc=com' >> /etc/ldap.conf	+	echo 'rootbinddn cn=Manager,dc=example,dc=com' >> /etc/ldap.conf

	==LDAP Replication==		==LDAP Replication==
Line 96:		Line 96:
	replogfile /var/lib/ldap/SUBDIRECTORY/replog		replogfile /var/lib/ldap/SUBDIRECTORY/replog
	replica host=SLAVEHOSTNAME		replica host=SLAVEHOSTNAME
-	suffix="dc=~~reachlocal~~,dc=com"	+	suffix="dc=example,dc=com"
-	binddn="cn=Replica,dc=~~reachlocal~~,dc=com"	+	binddn="cn=Replica,dc=example,dc=com"
	credentials=PASSWORDINPLAINTEXT		credentials=PASSWORDINPLAINTEXT
	bindmethod=simple		bindmethod=simple
Line 110:		Line 110:
	Then create the following ldif file.		Then create the following ldif file.

-	dn: cn=Replica,dc=~~reachlocal~~,dc=com	+	dn: cn=Replica,dc=example,dc=com
	objectClass: top		objectClass: top
	objectClass: organizationalRole		objectClass: organizationalRole
Line 119:		Line 119:
	And add it to the database on the slave.		And add it to the database on the slave.

-	ldapadd -x -W -D 'cn=Manager,dc=~~reachlocal~~,dc=com' -f replica.ldif	+	ldapadd -x -W -D 'cn=Manager,dc=example,dc=com' -f replica.ldif

	Finally, add the following to the slave server's slapd.conf.		Finally, add the following to the slave server's slapd.conf.

-	updatedn cn=Replica,dc=~~reachlocal~~,dc=com	+	updatedn cn=Replica,dc=example,dc=com
	updateref ldap://MASTER_LDAP_SERVER		updateref ldap://MASTER_LDAP_SERVER

Jeff at 07:45, 18 June 2009

2009-06-18T07:45:34Z

←Older revision		Revision as of 07:45, 18 June 2009
Line 40:		Line 40:
	Then use the migration tools to build an LDIF file of the user's data.		Then use the migration tools to build an LDIF file of the user's data.

-	~~<pre>~~	+	./migrate_passwd.pl <( grep juser etcpasswd ) > juser.ldif
-	./migrate_passwd.pl <( grep juser ~~slash etc slash passwd~~	+	./migrate_group.pl <( grep juser etcgroup ) >> juser.ldif
-	./migrate_group.pl <( grep juser	+
-	~~</pre~~>	+	Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:
		+
		+	ldapadd -x -W -D 'cn=Manager,dc=reachlocal,dc=com' -f juser.ldif
		+
		+	Keep in mind, only migrate users corresponding to an actual employee (user ID should be 1000 or greater). Service accounts (like loguser) should exist only in the local passwd and group files.
		+
		+	Also, a note that the wheel group is granted elevated privilege via sudo. If a user needs to be able to gain root on one particular machine, just add that user to the wheel group on that particular box (use the vigr command to do this).

	==Authentication and Identification==		==Authentication and Identification==
Line 72:		Line 78:

	==LDAP Replication==		==LDAP Replication==
		+
		+	Configure another host as an LDAP server, but don't include any replication directives yet. Basically, you must at least specify the database location.
		+
		+	Before we begin replication, the slave server must contain a full replica of the current master server's data tree. You can do this with the master still running.
		+
		+	slapcat > /tmp/dump.ldif
		+
		+	Now copy this dump file over to the slave server and import it.
		+
		+	slapadd < /tmp/dump.ldif
		+	chown -R ldap. ~ldap/
		+
		+	Now start the slapd daemon and it should start without error. You should be able to perform normal queries against it.
		+
		+	Return to the master server. Add the following information to slapd.conf.
		+
		+	replogfile /var/lib/ldap/SUBDIRECTORY/replog
		+	replica host=SLAVEHOSTNAME
		+	suffix="dc=reachlocal,dc=com"
		+	binddn="cn=Replica,dc=reachlocal,dc=com"
		+	credentials=PASSWORDINPLAINTEXT
		+	bindmethod=simple
		+	tls=no
		+
		+	As you see, the replica user's password is included in plain text in this file, so it is critical that the slapd.conf file should only be readable by the ldap user. Restart the LDAP server. This time slurpd will also start.
		+
		+	Once again, return to the slave server. You must create the replica user. First generate the password.
		+
		+	openssl passwd -1
		+
		+	Then create the following ldif file.
		+
		+	dn: cn=Replica,dc=reachlocal,dc=com
		+	objectClass: top
		+	objectClass: organizationalRole
		+	objectClass: simpleSecurityObject
		+	cn: Replica
		+	userPassword: {CRYPT}GENERATE_THIS_WITH_OPENSSL
		+
		+	And add it to the database on the slave.
		+
		+	ldapadd -x -W -D 'cn=Manager,dc=reachlocal,dc=com' -f replica.ldif
		+
		+	Finally, add the following to the slave server's slapd.conf.
		+
		+	updatedn cn=Replica,dc=reachlocal,dc=com
		+	updateref ldap://MASTER_LDAP_SERVER
		+
		+	Restart the ldap service and now any changes made on the master server will be automatically pushed to the slave server. If someone attempts to write a change to a slave server, they will get redirected to the master.
		+	What If It Breaks?
		+
		+	Sometimes the network link between the master and slave goes down and it just so happens that an update was made when the link was broken. Well, it happens. Your slave is now out of sync with your master. Unfortunately, slurpd is not robust enough to catch the slave back up on its own. Well, you could go back to the beginning and rebuild the slave from the current master view. This works, except re-adding the replica user is difficult with that updateref directive in slapd.conf. So edit the file twice? Not necessary.
		+
		+	If you have a look at /var/lib/ldap on the master, you will see there is now a replica subdirectory. Inside it is a set of rej and rej.lock files for each of the slaves for any bit that the slave didn't successfully replicate. All you have to do is play back the rej file and the slave will catch up. You can't run two copies of slurpd so stop the ldap service and run slurpd in one-shot mode.
		+
		+	slurpd -o -r /var/lib/ldap/replica/SLAVE:389.rej
		+
		+	When it exits, restart the ldap service.

	==GUI Tools==		==GUI Tools==

	==libuser Tools==		==libuser Tools==

Jeff: /* Adding Users With Migration Scripts */

2009-06-18T07:44:06Z

Adding Users With Migration Scripts

←Older revision		Revision as of 07:44, 18 June 2009
Line 41:		Line 41:

	<pre>		<pre>
-	./migrate_passwd.pl <( grep juser	+	./migrate_passwd.pl <( grep juser slash etc slash passwd
-	./migrate_group.pl <(	+	./migrate_group.pl <( grep juser
	</pre>		</pre>