In the previous post I showed how to set up an OpenLDAP server to be the authentication source for the impactadmin user. Reliable authentication of this user is critical for Impact. Not only is impactadmin used as a base administrative user, it is also internally to connect components.
Federating two LDAP servers is accomplished by changing directory to $IMPACT_HOME/install/security and running the confAuth4LDAP.sh script twice. This script not only sets up (or adds) to the LDAP Registry configuration, it also sets (or resets) the default administrative user. Since we want the administrative user to be impactadmin, we will need to add the OpenLDAP repository after adding the Corporate LDAP server.
Note: As a "Best Practice" recommendation, if you have an Impact cluster with two hosts I suggest setting up an instance of OpenLDAP on each host with the same values for the impactadmin password. This will aid the cluster in continuing operation if the opposite host goes down, since it will not depend on authenticating impactadmin "off-host". You will need to perform the federation steps on both hosts, of course.
Let's work through an example:
We'll assume we have a Corporate LDAP server for acme.com and we have the necessary binding information, base DN, and so forth. Start by making a copy of the impactdap.properties file for each LDAP server you will be federating, e.g.:
- cd $IMPACT_HOME/install/security
- cp impactdap.properties impactdap.properties.ACME
- cp impactdap.properties impactdap.properties.NOI
Then edit the two new files following the guidelines from Properties in impactdap.properties. Here are the values for the impactdap.properties.NOI file:
|Property Name||Value in the impactdap.properties.NOI file|
|LDAPRepositoryName||NOI_LOCAL - This must be different from the other repository|
|LDAPHost||Use the fully qualified name of the local host|
|LDAPBindPass||The password for the OpenLDAP "admin" user. It may be necessary to add this line to the file|
|LDAPSSORealm||Make sure this matches (in both files) whatever you've set in DASH if you plan to integrate the Impact GUI server into DASH|
You can leave the custom search filtering settings commented out.
I recommend testing the values for both repositories with the ldapsearch command to make sure everything is correct. In the examples below, replace the text in red with the appropriate values.
- $ ldapsearch -h localhost -b dc=noi,dc=local -D cn=admin,dc=noi,dc=local -w admin_PWD | grep uid
- $ ldapsearch -h ACME_LDAP_HOST -b ACME_BASE -D ACME_BIND_USER -w ACME_BIND_PWD | grep sAMAccountName
Note that the above example assumed that the Corporate LDAP server type was Microsoft AD. Other directory types might require grepping for a different attribute. Make sure that the first ldapsearch command returns 'impactadmin' and the second command returns the corporate users you wish to authenticate.
As noted above, through at least Impact 184.108.40.206, the Impact documentation on LDAP Federation is exactly backwards. It is important to run the confAuth4LDAP.sh script with the Corporate Directory properties first! The reason is that the new "admin" user supplied on the command line will be substituted throughout the configuration files for internal authorizations. Since you want the entire process to end up with that user being impactadmin, you must federate the OpenLDAP repository as the last one.
To federate the Corporate Directory first, you will need a temporary user to act as the impact administrative user. I've generally been able to use the bind user. Make sure to overwrite the impactdap.properties file with the values for the Corporate Directory. You will also need to know the original current impactadmin password that Impact is using for its file-based or ObjectServer based authentication.
- cp impactdap.properties.ACME impactdap.properties
- ./confAuth4LDAP.sh enable ACME_BIND_USER ACME_BIN_PASSWORD CURRENT_impactadmin_PASSWORD
This will convert Impact to using the Corporate Directory and will temporarily set the bind user as the internal Impact administrative user. Now repeat the process for the OpenLDAP server:
- cp impactdap.properties.NOI impactdap.properties
- ./confAuth4LDAP.sh enable impactadmin IMPACTADMIN_PASSWORD ACME_BIN_PASSWORD
This will add the local OpenLDAP server to the federation and set 'impactadmin' back as the Impact internal administrative user.
There's one final task (as of Impact 220.127.116.11 - this may be fixed in later versions).
- cd $IMPACT_HOME/wlp/usr/shared/config
- vi ldapRegistry.xml
Search down for the section that begins with "<primaryRealm name=". You may find that there is only one "<participatingBaseEntry" line, but there should be two.
Correct the entry to look something like this:
<primaryRealm name="ACME_PROD" allowOpIfRepoDown="true">
You will need to stop and restart the GUI Server and Impact Server and then you will be doing all authentication through LDAP, including getting impactadmin from the OpenLDAP repository under local control.