Websphere LDAP registry Configuration | WAS 8
One of the details common to all user registries or repositories is the primary administrative username. This ID is a member of the chosen repository, but also has special privileges on the WebSphere Application Server. The privileges for this ID and the privileges that are associated with the administrative role ID are the same. The primary administrative username can access all of the protected administrative methods of WebSphere.
For Windows users: The primary administrator ID must not be the same name as the machine name of your system because the repository sometimes returns machine-specific information when querying a user of the same name.When configuring standalone LDAP registries, as we are about to, it is important to verify that the Primary administrative username is a member of the repository and not just the LDAP administrative role ID. The Primary administrative username does not run WebSphere Application Server processes. Rather, the process ID runs the WebSphere Application Server processes. A process ID is determined by the way the process Standalone LDAP repositories must contain the primary administrative user ID; otherwise, you will not be able to log in to the administrative console.starts. For example, if you use a command line to start processes, the user ID that is logged in to the system is the process ID. If running as a service, the user ID that is logged in to the system is the user ID running the service.
If you choose the local operating system registry, the process ID requires special privileges to call the operating system APIs. The process ID must be assigned the platform-specific privileges on the OS where WebSphere is installed.
Now that we have covered a few formal points about the primary administrator we can configure WebSphere to use a standalone LDAP repository.
LDAP security settings
Follow these steps to configure WAS to use a stand-alone LDP repository:
1. Navigate to the Security section of the left-hand-side panel in the Administrative console and click on Global security.
2. In the Security page, under the User account repository section, select Standalone LDAP registry from the Available realm definitions list and click Configure to enter the Standalone LDAP registry settings page. Here, you can configure all the appropriate settings for WAS to use an LDAP repository. As shown in the next screenshot, type wasadmin in the Primary administrative user name field. This is the primary user WebSphere will use for the server identity.
For users using the sample LDIF tree, the password for wasadmin is wasadmin.
3. In the LDAP server section, choose an appropriate LDAP server type from the Type of LDAP server list. There are several pre-configured LDAP server types which are tuned for common LDAP servers. If you are not sure of the type of LDAP server you are using, you can choose the custom option. In our examples, we have chosen the IBM Tivoli Directory Server option because we are using Tivoli Directory Server as our LDAP directory. If you decide not to use Tivoli Directory Server, ensure that you modify settings appropriately.
4. Next, specify the Host and Port of the LDAP server and an optional Base Distinguished Name (DN). The Base distinguished name (DN) indicates the starting point for LDAP searches within the LDAP directory tree. Following is a table of settings used in the example:
Host – localhost (We can use localhost because the LDAP server is installed on the same machine as WebSphere. If this is not the case in your setup, then change accordingly)
Port – 339 (Default LDAP port)
Base distinguished Name (DN) o=techpaste.com (The base DN is where the LDAP bind will start searches)
5. Next, we need to complete the Security section located on the right-hand side of the page. In this section, we have two fields to fill in. Bind distinguished name (DN) is the name which WebSphere will use to connect to LDAP for name searches. The Bind password is the password for this user. If you have chosen to import the sample LDIF file, fill in these fields with the appropriate values shown in the following screenshot. If you have not chosen to use the sample directory tree, then modify it according to your needs:
In production systems, you would use a non-LDAP administration user as your bind username. Normally, a separate LDAP user is used for WebSphere connection binding.
Bind distinguished name (DN) – cn=ldapbind,ou=users,o=mycompany.org
Bind password – ldapadmin
If no name is specified for the Bind distinguished name (DN), the application server binds anonymously. The LDAP server must be setup to allow anonymous binding.
6. Once you have completed filling in the required fields, click Apply and you will then be prompted with the following message:
7. Click Save.
8. Before we can complete our LDAP configuration, we need to look at the default LDAP search filters. To edit the advanced LDAP settings, click on Advanced Lightweight Directory Access Protocol (LDAP) user registry settings in the configuration page for a Standalone LDAP Registry, as shown in the following screenshot:
9. Within the Advanced Lightweight Directory Access Protocol (LDAP) user registry settings screen, you will now be presented with the option to change LDAP attributes:
10. A default set of predefined filters exists, which are provided for each LDAP server that the WAS supports. You can modify these filters to fit your LDAP configuration. The User filter field contains an LDAP string, which provides the LDAP search filter that is used to obtain information about users and groups from an LDAP directory server. If you are using the sample directory tree, you will need to change the User filter field from (&(uid=%v)(objectclass=ePerson)) to (&(uid=%v)(objectclass=inetOrgPerson)) as shown in the previous screenshot, to ensure that WAS queries the Tivoli Directory Server’s LDAP tree correctly. If you have not used the sample LDAP tree, you will need to ensure that the LDAP filters are correctly set for your LDAP directory. Click OK to return to the Global security screen.
11. Once again, you are informed that the server needs restarting for the repository to take effect. Click Save but, before you restart, it is wise to click the Test connection button located at the top of the screen, just above the General properties section, to ensure that your LDAP bind settings are correct. If your configuration is correct, a message is displayed at the top of the page, similar to the one shown in the next screenshot. If an error occurs, a corresponding message will be displayed. Common cause(s) of connection failure are the ports being incorrect or blocked by a firewall, and/or bind name and password details are incorrect:
12. From within the current Standalone LDAP registry settings page, click OK to accept all the settings. You will be returned to the Global security page.
13. Within the Global security page, ensure that Standalone LDAP registry is selected from the Available realm definition pick-list and click the Set as current button, as shown in the following screenshot:
14. Click Apply and you will be prompted to save the configuration. Click Save to save the security changes to the master configuration.
15. Restart WAS for the LDAP settings to take effect.
In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.
This is good stuff – helped me get a good understanding of the process. I had to do the above and then wound up migrating to Federated Repositories for LDAP. http://www-01.ibm.com/support/knowledgecenter/SSEQTJ_8.5.5/com.ibm.websphere.zseries.doc/ae/usec_singleldaprepos.html .
Glad it helped. thanks for sharing the IBM KB link too, It will surely help someone in future.
All my settings are correct the Test Connection check is passing but after step 14 i get the following error:
Primary administrative user Id does not exist in the registry.
Any ideas ?