Before we do anything else we now need to make sure our users can login.
WebSphere only has an internal file repository that will only contain the “wasadmin” entry we created when installing. The users and groups we want to be able to use Connections aren’t in that File Repository, they are in a LDAP directory (or directories) somewhere. We need to tell WebSphere’s deployment manager where to find and authenticate those users.
First we need to consider where our directory is going to be and if there will be one or multiple directories (if all users aren’t held in one place). For instance, if all my users login to Active Directory I might use that, or I might use Domino which itself could be running Directory Assistance.
When deciding on LDAP directory configuration:
- As few directories as possible should be referenced
- Every user should have a unique key in the directory
- If you use multiple directories each user should appear only once with their unique key. If my key is my email, email@example.com, then there should only be one entry with that name across all the directories we reference.
- The directory should be a trusted source with strong password validation
In this case we’re going to choose a single Domino LDAP server but we could have just as easily chosen Active Directory or many other LDAP directory sources.
Adding external directories in WebSphere is known as adding Federated Repositories. Before modifying or adding any federated repository I like to take a backup of the Deployment Manager. Very often if the LDAP configuration is wrong you can end up locking yourself out of WebSphere entirely and you will need to restore from that backup.
To backup go to the /bin directory under /profiles/Dmgr01 and run:
./backupConfif.sh <locationofzipfile> -nostop
To add or modify a Federated Repository we go to Global Security in the ISC and choose “Configure” next to the “Available realm definitions – Federated repositories”:
We are going to add an LDAP repository:
Here we enter the details of the LDAP directory source we’re going to use. In this case I have a Domino server running LDAP on hostname ldap.connections101.info and secure port 636. Note how the “Require SSL Communications” checkbox is enabled, you must select this if you are connecting to LDAP securely.
Choosing the right Directory type from the drop down list ensures that the LDAP query syntax is correctly formed for the directory you are accessing. Selecting “IBM Lotus Domino” when pointing to an Active Directory server will prevent the directory from working.
I do not recommend using bind credentials to login to your LDAP directory unless you are also using a secure SSL protocol to connect. If you are connecting using 389 or another non-encrypted port I would suggest an anonymous bind.
The field “Federated repository properties for login” will determine what values can be used to login. These are all LDAP attributes that map to fields in the source directories. If possible in a Connections environment we want to have “uid” listed first. UID maps to the value ‘shortname’ in Domino LDAP, ‘mail’ maps to the internet mail address and ‘cn’ maps to my fullname. With the values set here as uid,mail,cn I will be able to login using variations of my name including:
Finally the value for failover server can be used to point to other identical directories. Although many customers use a separate load balancer to handle LDAP failover, WebSphere actually responds faster to multiple LDAP failover servers entered here rather than waiting for a load balancer to return a new host.
WebSphere will attempt to validate all the information on this screen including hostname, bind credentials and port when we save. The next step is to define the Unique Distinguished Name for entries in this repository. Whatever we choose here, it must be unique across all directories.
For this directory I could use the value O=Turtle and that will restrict valid users to just those with a hierarchical name containing the Turtle organisation e.g Gabriella Davis/Turtle. In a Domino directory, unique for LDAP sources, not all entries are hierarchical (groups names for instance are flat) so with this configuration WebSphere won’t recognise any Domino groups. One option to workaround that is to use the value “root” for the Unique distinguished name which will tell WebSphere to recognise all organisations and even flat names or groups.
We also need to make sure the Group definitions are correct for the directory type we are using. For Domino the attribute use for defining a group is called “dominoGroup” not the default “groupofNames” and the member attribute is called “member”.
Once the repository is configured we log out of the ISC and restart the deployment manager, then we log back in and go to Users and Groups – Manage Users / Manage Groups to confirm that all our LDAP users and groups are found and displayed.
If I can’t log back in after a restart I can rollback to the earlier backed up instance of the deployment manager and start over.
Now that the Federated Repository is set up the next thing we want to do is add additional accounts that can administer the ISC, including a LDAP account which will become the Connections Administrator. Here we are using an account called “connadmin” that I created in the Domino directory. Once the account is added we can test that it works by logging out of the ISC and attempting to login as “connadmin”.