Standalone LDAP

What we will cover in the next few pages is how to configure WebSphere Application Server to use a standalone LDAP registry. The difference between a standalone LDAP repository and Federated Repositories is that the WAS administrative IDs and User ID’s are both referenced from the same LDAP server. If the LDAP service is down, then you will not be able to log into the WAS Console and application authentication will not work

As far as LDAP servers go, there are many products in the marketplace and your organization will have a solution from one of the big vendors, such as Microsoft’s ADAM, which is a light-weight implementation of Active Directory or IBM’s Tivoli Directory Server. These are just two very common commercial LDAP implementations. However, we are using the Open Source ApacheDS server which we created earlier in this guide.

Configuring the Standalone LDAP Server

We have already created a federated repository, which is defined as the current repository in Global Security as seen below in Security > Global Security.

  • Click the Available realm definition list box and choose Standalone LDAP registry


  • Click Configure

You will now the see the Global security > Standalone LDAP configuration page

The Primary administrative use is wasadmin, this user must exist in the LDAP directory in this configuration. We have also chosen LDAP Server to be Custom.

  • Enter the LDAP server configuration values as required.

We can use the exact same details we used I the Federates repositories example, there are specified in the table below.

Field name Value entered
Host Localhostcell01
(We can use localhost because the LDAP server is installed in the same machine as WebSphere. If this is not the case in your setup, then change accordingly.)
Port 10389
(Default LDAP port for ApacheDS)
Base Distinguished name dc=themiddlewareshop,dc=com This is the root of the LDAP directory which we are doing our lookups to.

Next we have 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. Fill in these fields with the values below, which we configured in Apache DS earlier.

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.


Field name Value entered
Bind distinguished name (DN) uid=wasldapbind,ou=system,dc=themiddlewareshop,dc=com
Bind password wasldapbind


Note: 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.

Also, you can see at the top of the screen this message

We must go back to Global Security screen, and set Standalone as the current configuration when we are done with this page.

Testing the connection

Once you have filled out the details, click Apply to save, then click Test Connection

A default set of predefined filters exist, which are provided for each LDAP server that the WebSphere supports. You can modify these filters to fit your LDAP configuration.

It is also recommended that we configure Additional properties

In the Global security > Standalone LDAP registry > Advanced Lightweight Directory Access Protocol (LDAP) user registry settings page, change the User Filter and Group Member Id Map to fields as per the entries below.

  • Change the User Filter field to the value below

The User filter field contains an LDAP string, which provides the LDAP search filter which is used to obtain information about users from an LDAP directory server.

Note: Since we hand crafted our LDAP directory, we know that our users all have inetOrgPerson for objectClass OR and account objectClass, both have uid as an attribute.

  • Change the Group Member ID Map to the value in the table below

The Group Member ID Map field sets the syntax for user-to-group membership when LDAP is scanning for users belonging to which groups.

Note: Since we hand crafted our LDAP directory, we know that our groups have groupOfNames for objectClass, but could also have groupOfUniqueNames, so I have added an OR condition.

Note: We make these changes because ApacheDS uses slightly different object classes and the default ones are customized for IBM LDAP servers, hence the change. We have only changed the entries required, the other fields are fine as they are.

Note: Each LDAP type, will present pre-configured entries in this page. When in doubt, you will be best to resort to IBM products if you can, however, we have proven that we can use other Open source tooling such as Apache DS. However, it does take some knowledge and you can’t just accept defaults.

  • Click Apply, and Save
  • When back on the Global security > Standalone LDAP registry page click OK, then Save to complete the page and return back to Global security

  • In the Available realm definitions section, select Standalone LDAP registry and click the Set as current button.

You will see the User Account repository will be updated as follows:

Click Apply

If your LDAP Bind username and password are correct and the LDAP server is running the Result will be a follows, as long as all the authentication is correct, and the Primary Administrative user ID can be located in the directory.

Click Save, then restart the server.

Next time we log into the server we will be asked for a username and password.


Note: You will also be prompted for a username and password to stop a running WAS instance when Global Security is enabled.

Congratulations, you have now learned the core fundamentals of securing WAS using a standalone LDAP server for both administrative users and application users.

Review of Security.xml

I think this is a good time to quickly review the security.xml settings for this Standalone LDAP configuration. The security.xml can be found in:


For example:



Looking at the userRegistries stanza contained within security.xml you will see the LDAP Filter settings we have specified. Below is a sample from my configuration.

<userRegistries xmi:type=”security:LDAPUserRegistry” xmi:id=”LDAPUserRegistry_1″ serverId=”” serverPassword=”{xor}” realm=”localhostcell01:10389″ ignoreCase=”true” useRegistryServerId=”false” primaryAdminId=”wasadmin” useRegistryRealm=”true” type=”CUSTOM” sslEnabled=”false” sslConfig=”” baseDN=”dc=themiddlewareshop,dc=com” bindDN=”uid=wasldapbind,ou=system,dc=themiddlewareshop,dc=com” bindPassword=”{xor}KD4sMzs+Lz02MTs=” searchTimeout=”120″ reuseConnection=”true”>
<searchFilter xmi:id=”LDAPSearchFilter_1″ userFilter=”(&amp;(uid=%v)(|(objectclass=inetOrgPerson)(objectclass=account)))” krbUserFilter=”(&amp;(krbPrincipalName=%v)(objectclass=ePerson))” groupFilter=”(&amp;(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)))” userIdMap=”*:uid” groupIdMap=”*:cn” groupMemberIdMap=”groupOfNames:member;groupOfUniqueNames:uniqueMember” certificateMapMode=”EXACT_DN” certificateFilter=””/>

<hosts xmi:id=”EndPoint_1429201817617″ host=”localhostcell01″ port=”10389″/>



You should see within the searchFilter section the user filter we configured earlier, for example: userFilter==”(&amp;(uid=%v)(|(objectclass=inetOrgPerson)(objectclass=account)))” This file is very useful, as you can edit it when things go wrong with your WebSphere administrative logins.

You now have configured WebSphere to use an LDAP registry.


Security Configuration Wizard
Virtual Member Manager
Administrative roles
Installing ApacheDS
Adding a new partition
Security settings

Looking at User Groups



To learn more about the courses available from The Middleware Shop, please go to to see a full list of the current courses available.


If you or your organization require support in architecture, performance tuning, automation or simply advice, then please contact me via my support site and request a conversation, where we can discuss your requirement.

About Steve

Steve is a seasoned passionate technology professional, strategist and leader.

An expert in technical communications, and adept in almost all forms of Internet and mobile related technology, Steve has time and time again proven his tenacity to improve systems around him and deliver.

Steve has worn many hats during his career such as Chief Technical Officer, Founding Member of several business ventures, Programmer, Systems Administrator, Architect, Blogger and Published Author to name a few.

Due to 20 years Industry experience in Middleware, Programming, Networks and Internet Technologies, He combines systems knowledge with efficient working methods and inter personal skills required to build effective relationship with clients and colleagues alike. Exceeding typical expectations in any role undertaken, Steve is certain to become a valuable asset within any organisation He joins.

Key Skills

• Leadership (Team, Project, Business, People).

• Architecture (Solutions, Information, Technical, Applications).

Simply, I help you deal with CANETI: Constant And Never Ending Technological Innovation

Specific IBM WebSphere skills:

WebSphere Application Server (WAS Base, WAS ND & Liberty Profile & Liberty Runtime)

  • Automation
  • Security, SSL
  • Dev Ops
  • Architecture
  • Performance Tuning

Middleware Integration Skills:

  • .NET programming, and Architecture
  • Java Programming, and Architecture
  • SOA, SOAP, and XML messaging
  • JBoss Fuse, WMQ, IIB, Mule

Integration Skills:

  • SOA
  • Process Improvement
  • ICD’s
  • Messaging Architecture
  • Governance

General Digital Architecture & Governance

  • Lightweight Architectures
  • Digital Strategy, platform stacks for example IAAS, PAAS, SAAS

Industry Qualifications & Recognition

  • TOGAF 9.1
  • IBM Champion 2013

Leave a Reply