This set up will use the following sub-domains with a root;
root: dc=example,dc=com
sub0: dc=dev,dc=example,dc=com
sub1: dc=stg,dc=example,dc=com
sub2: dc=prod,dc=example,dc=com
Now that we have the above domains, we can set about creating the LDAP configuration. During the project work Puppet manifests were used to create the general LDAP configuration files as per many of the example on the web (e.g. http://ostechnix.wordpress.com/2013/02/05/setup-ldap-server-389ds-in-centosrhelscientific-linux-6-3-step-by-step/) , but to create the master LDIF files I used Puppet files to load the domain initial and any data for the domain, such as user and groups and then DS 389 was started.
Each sub-domain was placed in the LDIF file as a DC and not an OU which most examples show. This keeps in line with the sub-domains of our environment.
The diagram for the set up looks as follows;
In the case of the environment the master had all domains made available to it, thus allowing centralised administration and backups.
The most important part of configuring LDAP replicas through the LDIF files is to remove the following line and have an empty top level domain for the LDIF to allow for replication to add the relevant configuration and data;
aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = "ldap:///cn=slapd-ldaplocal,cn=389 Directory Server,cn=Server Group,cn=master.example.com,ou=example.com,o=NetscapeRoot";)
This line defines the server and top level domain, and is only required in the master server, but removed from all replica configurations.
Your master server should have the following line in it's LDIF file;
aci: (targetattr ="*")(version 3.0;acl "Directory Administrators Group";allow (all) (groupdn = " ldap:///cn=Directory Administrators, dc=example,dc=com");)
Master Replication Script
The following script enables you to set up the server replication. Note you will need to make substitutions based on your hostames, etc, and that this is a Puppet template that generates a shell script.
# Create the Bind DN user that will be used for replication
ldapmodify -v -h <%= @hostname %> -p 389 -D "cn=directory manager" -w <%= scope.function_hiera(['example_389_hiera::root_user_password']) %> <<_end_ font="">
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
cn: replication manager
sn: RM
userPassword: <%= scope.function_hiera(['example_389_hiera::root_user_password']) %>
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0
_END_
# DS389 needs to be restarted after adding this user
service dirsrv restart
# Create the change log
ldapmodify -v -h <%= @hostname %> -p 389 -D "cn=directory manager" -w <%= scope.function_hiera(['example_389_hiera::root_user_password']) %> <<_end_ font="">
dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-<%= @hostname %>/changelogdb
_END_
# Create the replica to share
ldapmodify -v -h <%= @hostname %> -p 389 -D "cn=directory manager" -w <%= scope.function_hiera(['example_389_hiera::root_user_password']) %> <<_end_ font="">
dn: cn=replica,cn="<%= scope.function_hiera(['example_389_hiera::base_dn']) %>",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsds5replica
objectclass: extensibleObject
cn: replica
nsds5replicaroot: <%= scope.function_hiera(['example_389_hiera::base_dn']) %>
nsds5replicaid: 7
nsds5replicatype: 3
nsds5flags: 1
nsds5ReplicaPurgeDelay: 604800
nsds5ReplicaBindDN: cn=replication manager,cn=config
_END_
<% @consumers.each do | consumer | -%>
ldapmodify -v -h <%= @hostname %> -p 389 -D "cn=directory manager" -w <%= scope.function_hiera(['example_389_hiera::root_user_password']) %> <<_end_ font="">
dn: cn=STGAgreement,cn=replica,cn="<%= scope.function_hiera(['example_389_hiera::base_dn']) %>",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsds5replicationagreement
cn: STGAgreement
nsds5replicahost: <%= consumer %>
nsds5replicaport: 389
nsds5ReplicaBindDN: cn=replication manager,cn=config
nsds5replicabindmethod: SIMPLE
nsds5replicaroot: <%= scope.function_hiera(['example_389_hiera::base_dn']) %>
description: agreement between <%= @hostname %> and <%= consumer %>
nsds5replicaupdateschedule: 0001-2359 0123456
nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE authorityRevocationList
nsds5replicacredentials: <%= scope.function_hiera(['example_389_hiera::root_user_password']) %>
nsds5BeginReplicaRefresh: start
_END_
<% end -%>
Adding New Consumber
For each LDAP replica you wish to allow to replicate with the master you will need to add it to the master. Here is some Puppet code that will generate the shell script that will add further replicas.
NOTE: The dn: cn=STGAgreement will need to change for each replica, so ensure that you name them accordingly (one per replica host).
ldapmodify -v -h <%= @hostname %> -p 389 -D "cn=directory manager" -w <%= scope.
function_hiera(['example_389_hiera::root_user_password']) %> <<_end_ font="">
dn: cn=STGAgreement,cn=replica,cn="<%= scope.function_hiera(['example_389_hiera::base_dn']) %>",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsds5replicationagreement
cn: STGAgreement
nsds5replicahost: <%= consumer %>
nsds5replicaport: 389
nsds5ReplicaBindDN: cn=replication manager,cn=config
nsds5replicabindmethod: SIMPLE
nsds5replicaroot: <%= scope.function_hiera(['example_389_hiera::base_dn']) %>
description: agreement between <%= @hostname %> and <%= consumer %>
nsds5replicaupdateschedule: 0001-2359 0123456
nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE authorityRevocationList
nsds5replicacredentials: <%= scope.function_hiera(['example_389_hiera::root_user_password']) %>
nsds5BeginReplicaRefresh: start
_END_
Authenticating The Replica/Consumer
The consumer must also participate in the replication. The following script is run on the replica to enable it to replicate with the master. The following Puppet code generates a shell script that can be run on the consumer;
# Create the Bind DN user that will be used for replication
ldapmodify -v -h <%= @hostname %> -p 389 -D "cn=directory manager" -w <%= scope.function_hiera(['example_389_hiera::root_user_password']) %> <<_end_ font="">
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
cn: replication manager
sn: RM
userPassword: <%= scope.function_hiera(['example_389_hiera::root_user_password']) %>
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0
_END_
# DS389 needs to be restarted after adding this user
service dirsrv restart
ldapmodify -v -h <%= @hostname %> -p 389 -D "cn=directory manager" -w <%= scope.function_hiera(['example_389_hiera::root_user_password']) %> <<_end_ font="">
dn: cn=replica,cn="<%= scope.function_hiera(['example_389_hiera::base_dn']) %>",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsds5replica
objectclass: extensibleObject
cn: replica
nsds5replicaroot: <%= scope.function_hiera(['example_389_hiera::base_dn']) %>
nsds5replicatype: 2
nsds5ReplicaBindDN: cn=replication manager,cn=config
nsds5flags: 0
nsds5replicaid: 2
_END_
Final Steps
Once you have the replication agreements in place it is likely that the consumers are failing, and reporting that they have different generation IDs. To fix this you need to resync the replication.
tail -f /var/log/dirsrv/slapd-
The error may look something like;
[28/Mar/2014:10:54:49 +0000] NSMMReplicationPlugin - agmt="cn=STGAgreement" (master.example.com:389): Replica has a different generation ID than the local data.
If you do see an error such as the above then run the following command from any LDAP server;
ldapmodify -h changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start
_END_
The Clients
The clients must also participate in the LDAP authentication too. This will mean that the following configurations will need changing;
- /etc/ldap.conf
- /etc/nslcd.conf
- /etc/nsswitch.conf
- /etc/ssh/sshd_config
/etc/ldap.conf
The information in this file that is key to enabling multiple domains, and restricting log ons is done as follows;
base example.com
base <%= base_dn %>
port 389
ldap_version 3
ssl no
pam_filter objectclass=posixAccount
pam_password md5
pam_login_attribute uid
pam_member_attribute uniquemember
# For each domain that you wish to access the host add the following;
nss_base_passwd ou=people,dc=mgm.example.com
nss_base_shadow ou=people,dc=mgm.example.com
nss_base_group ou=Groups,dc=mgm.example.com
nss_base_netgroup ou=Netgroup,dc=mgm.example.com
nss_base_passwd ou=people,dc=dev.example.com
nss_base_shadow ou=people,dc=dev.example.com
nss_base_group ou=Groups,dc=dev.example.com
nss_base_netgroup ou=Netgroup,dc=dev.example.com
nss_initgroups_minimum_uid 1000
nss_initgroups_minimum_gid 1000
nss_reconnect_tries 5
nss_reconnect_maxconntries 5
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 5
rootbinddn cn=Directory Manager
uri ldap://ldap.dev.example.com/
tls_cacertdir /etc/openldap/cacerts
URI ldap://ldap.dev.example.com>/
BASE dc=example,dc=com
bind_policy soft
# Tweaking some timeout values
# The following options are documented in man nss_ldap
sizelimit 1000
idle_timelimit 5
timelimit 10
bind_timelimit 5
/etc/nslcd.conf
The following attributes need to be set;
uri ldap://ldap.dev.example.com
binddn cn=Directory Manager
bindpw <%= bind_dn_password %>
# One for each domain that can log on to the host
base dc=mgm.example.com
base dc=dev.example.com
base group ou=Groups,<%= dc=mgm,dc=example,dc=com %>
base passwd ou=People,<%= dc=mgm,dc=example,dc=com %>
base shadow ou=People,<%= dc=mgm,dc=example,dc=com %>
base group ou=Groups,<%= dc=dev,dc=example,dc=com %>
base passwd ou=People,<%= dc=dev,dc=example,dc=com %>
base shadow ou=People,<%= dc=dev,dc=example,dc=com %>
/etc/nsswitch.conf
passwd: files ldap
shadow: files ldap
group: files ldap
/etc/ssh/sshd_config
To enable LDAP authentication through ssh, and to allow ssh keys the following is required in this file;
AuthorizedKeysCommand /usr/libexec/openssh/ssh-ldap-wrapper
<%- if @operatingsystem == 'Fedora' -%>
AuthorizedKeysCommandUser nobody
<%- else -%>
AuthorizedKeysCommandRunAs nobody
<%- end -%>
NOTE: The above is Puppet code that determines if the O/S is Fedora or Red Hat, since the newer version of sshd requires AuthorizedKeysCommandUser.
Testing
You will need to restart sshd, and start nslcd.
Ensure that you are logged on as root in the event that something fails as you will want to disable LDAP if you are unable to log on to the host for some reason.
If all is working you should be able to log on as an LDAP user.
From this point onward you should add your users to the domain that they belong to. Note, a user can only have a a user account in one domain, so it would be good to have an admin domain which is included on all hosts (e.g. the MGM domain shown above) along with either the dev, or the stg or the prod. The dev, stg or prod domains should only appear on the hosts for those domains, whilst MGM appears across all domains.
Disclaimer
This is a shortened overview of what I implemented, and would be glad to consult on any organisation that would like to have a centralised multi-domain DS 389 or LDAP system with replicas and backup.
