When using an external LDAP server to serve the user database, a Bright cluster can be configured in different ways to authenticate against it.
For smaller clusters, a configuration where LDAP clients on all nodes point directly to the external server is recommended. An easy way to set this up is as follows:
• On the head node:
– the URIs in/etc/ldap.conf, and in the image file /cm/images/ default-image/etc/ldap.conf are set to point to the external LDAP server.1
– theupdateprovisioners command (section 6.2.4) is run to up- date any other provisioners.
• Then, to update configurations on the regular nodes:
– They can simply be rebooted to pick up the updated configu- ration.
– Alternatively, to avoid a reboot, the imageupdate command (section 6.6.2) can be run to pick up the new image from a pro- visioner.
• If using the user portal with user authentication (section 10.9), the changes described in section 10.9.1 for external LDAP server config- uration should be carried out
• In the CMDaemon configuration filecmd.conf (Appendix C): – If another LDAP tool is to be used to manage external LDAP
user management instead of cmgui or cmsh, then altering cmd.conf is not required.
– If, however, system users and groups are to be managed via cmgui or cmsh, then CMDaemon, too, must refer to the external LDAP server instead of the default LDAP server on the head node. To set that up:
* The LDAPHost, LDAPUser, LDAPPass, and LDAPSearchDN di- rectives in cmd.conf are changed to refer to the external LDAP server.
* CMDaemon is restarted to enable the new configurations. For larger clusters the preceding solution can cause issues due to traffic, latency, security and connectivity fault tolerance. If such occur, a bet- ter solution is to replicate the external LDAP server onto the head node, hence keeping all cluster authentication local, and making the presence of the external LDAP server unnecessary except for updates. This opti- mization is described in the next section.
1In distributions that are derived from RHEL 6 or higher,/etc/ldap.conf file does
not exist. The files in which the changes then need to be made are/etc/nslcd.conf and /etc/pam_ldap.conf.
7.3.1 External LDAP Server Replication
This section explains how to set up replication for an external LDAP server to an LDAP server that is local to the cluster, if improved LDAP ser- vices are needed. Section 7.3.2 then explains how this can then be made to work with a high availability setup.
Typically, the Bright LDAP server is configured as a replica (consumer) to the external LDAP server (provider), with the consumer refreshing its local database at set timed intervals. How the configuration is done varies according to the LDAP server used. The description in this section as- sumes the provider and consumer both use OpenLDAP.
External LDAP Server Replication: Configuring The Provider It is advisable to back up any configuration files before editing them.
The provider is assumed to be an external LDAP server, and not nec- essarily part of the Bright cluster. The LDAP TCP ports 389 and 689 may therefore need to be made accessible between the consumer and the provider by changing firewall settings.
If a provider LDAP server is already configured then the following syn- chronization directives must be in the slapd.conf file to allow replica- tion:
index entryCSN eq index entryUUID eq overlay syncprov
syncprov-checkpoint <ops> <minutes> syncprov-sessionlog <size>
The openldap documentation (http://www.openldap.org/doc/) has more on the meanings of these directives. If the values for <ops>, <minutes>, and <size> are not already set, typical values are:
syncprov-checkpoint 1000 60
and:
syncprov-sessionlog 100
To allow the consumer to read the provider database, the consumer’s access rights need to be configured. In particular, theuserPassword at- tribute must be accessible. LDAP servers are often configured to prevent unauthorized users reading theuserPassword attribute.
Read access to all attributes is available to users with replication priv- ileges. So one way to allow the consumer to read the provider database is to bind it to replication requests.
Sometimes a user for replication requests already exists on the provider, or the root account is used for consumer access. If not, a user for replica- tion access must be configured.
A replication user, syncuser with password secret can be added to the provider LDAP with adequate rights using the following syncuser.ldif file: dn: cn=syncuser,<suffix> objectClass: person cn: syncuser sn: syncuser userPassword: secret
Here,<suffix> is the suffix set in slapd.conf, which is originally some- thing likedc=example,dc=com. The syncuser is added using:
ldapadd -x -D "cn=root,<suffix>" -W -f syncuser.ldif
This prompts for the root password configured inslapd.conf.
To verifysyncuser is in the LDAP database the output of ldapsearch can be checked:
ldapsearch -x "(sn=syncuser)"
To allow access to theuserPassword attribute for syncuser the fol- lowing lines inslapd.conf are changed, from:
access to attrs=userPassword by self write by anonymous auth by * none to: access to attrs=userPassword by self write by dn="cn=syncuser,<suffix>" read by anonymous auth by * none
Provider configuration is now complete and the server can be restarted using/etc/init.d/ldap restart.
External LDAP Server Replication: Configuring The Consumer(s) The consumer is an LDAP server on a Bright head node. It is configured to replicate with the provider by adding the following lines to/cm/local/ apps/openldap/etc/slapd.conf: syncrepl rid=2 provider=ldap://external.ldap.server type=refreshOnly interval=01:00:00:00 searchbase=<suffix> scope=sub schemachecking=off binddn=cn=syncuser,<suffix> bindmethod=simple credentials=secret Here:
• Therid=2 value is chosen to avoid conflict with the rid=1 setting used during high availability configuration (section 7.3.2).
• The provider argument points to the external LDAP server.
• The interval argument (format DD:HH:MM:SS) specifies the time interval before the consumer refreshes the database from the exter- nal LDAP. Here, the database is updated once a day.
• The credentials argument specifies the password chosen for the syncuser on the external LDAP server.
More on thesyncrepl directive can be found in the openldap docu- mentation (http://www.openldap.org/doc/).
The configuration files must also be edited so that:
• The<suffix> and rootdn settings in slapd.conf both use the cor- rect<suffix> value, as used by the provider.
• The<base> value in the /etc/ldap.conf uses the correct <suffix> value as used by the provider. This is set on all Bright cluster nodes. If theldap.conf file does not exist, then the footnote on page 174 applies.
Finally, before replication takes place, the consumer database is cleared. This can be done by removing all files, except for theDB_CONFIG file, from under the configured database directory, which by default is at/var/lib/ ldap/.
The consumer is restarted usingservice ldap restart. This repli- cates the provider’s LDAP database, and continues to do so at the speci- fied intervals.
7.3.2 High Availability No External LDAP Server Case
If the LDAP server is not external—that is, if the Bright Cluster Manager is set to its high availability configuration, with its LDAP servers running internally, on its own head nodes—then by default LDAP services are provided from both the active and the passive node. The high-availability setting ensures that CMDaemon takes care of any changes needed in the slapd.conf file when a head node changes state from passive to active or vice versa, and also ensures that the active head node propagates its LDAP database changes to the passive node via a syncprov/syncrepl configuration inslapd.conf.
External LDAP Server With No Replication Locally Case
In the case of an external LDAP server being used, but with no local repli- cation involved, no special high-availability configuration is required. The LDAP client configuration in /etc/ldap.conf simply remains the same for both active and passive head nodes, pointing to the external LDAP server. The file /cm/images/default-image/etc/ldap.conf in each image directory also points to the same external LDAP server. If theldap.conf files referred to here in the head and software images do not exist, then the footnote on page 174 applies.
External LDAP Server With Replication Locally Case
In the case of an external LDAP server being used, with the external LDAP provider being replicated to the high-availability cluster, it is gen- erally more efficient for the passive node to have its LDAP database prop- agated and updated only from the active node to the passive node, and not updated from the external LDAP server.
The configuration should therefore be:
• an active head node that updates its consumer LDAP database from the external provider LDAP server
• a passive head node that updates its LDAP database from the active head node’s LDAP database
Although the final configuration is the same, the sequence in which LDAP replication configuration and high availability configuration are done has implications on what configuration files need to be adjusted.
1. For LDAP replication configuration done after high availability con- figuration, adjusting the new suffix in/cm/local/apps/openldap/ etc/slapd.conf and in /etc/ldap.conf on the passive node to the local cluster suffix suffices as a configuration. If theldap.conf file does not exist, then the footnote on page 174 applies.
2. For high availability configuration done after LDAP replication con- figuration, the initial LDAP configurations and database are prop- agated to the passive node. To set replication to the passive node from the active node, and not to the passive node from an external server, the provider option in the syncrepl directive on the pas- sive node must be changed to point to the active node, and the suf- fix in/cm/local/apps/openldap/etc/slapd.conf on the passive node must be set identical to the head node.
The high availability replication event occurs once only for configu- ration and database files in Bright Cluster Manager’s high availability system. Configuration changes made on the passive node after the event are therefore persistent.