Adding LDAP to a federated repository

We have covered how to install Apache DS, we will now look at adding LDAP to our Federated Repository. So far we have the internal fie-based registry names fileRegistry.xml, however our installed JEE application(s) will require a user registry. For this we want to use LDAP. We want to use LDAP as we can connect to the corporate user-directory as presented in LDAP.

Federated repositories recap

In WebSphere it is possible to federate repositories allowing a single virtual repository from which to query administrative and application user accounts. What we are now going to do is federate the internal file-based repository and a newly created LDAP repository, hence the terms Federated Repositories.

To begin the process of creating our federated repository, navigate to the Global Security page and locate the User account repository section. This time select Federated repositories from the Available realm definition pick-list and click the Configure button as seen below.

Note: Now that we have ApacheDS configured and working, we can now configure WebSphere to use the LDAP directory we have created. Before we continue, I would like to explain the Primary administration user which we will set in the next steps. One of the details common to all user registries or repositories is the Primary administrative user name. This ID is a member of the chosen repository, but also has special privileges in 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 user name can access all of the protected administrative methods of WebSphere Application Server.

Security settings

Navigate to the Security section of the left-hand side panel in the administrative console and click on Global security. In the Security page, under the User account repository section click Configure so we can add a new repository to our virtual realm, which contains our “Federated Repositories”

In the Federated repositories screen, we can see that the Rea Name is set, and so is the Primary administrative user name. We know about the primary user being part of the default internal file Registry which we added earlier.

  • To add another repository (registry) click on the Add repositories (LDAP, custom etc…) button On the Repository reference screen, we can

On the Repository references screen as seen above, do the following

  • Click New Repository and select LDAP
  • Then click on the New Repository button and select LDAP registry

 

 

In the LDAP server section, choose Custom from the Type of LDAP server list. There are several pre-configured LDAP server types which are tuned for common LDAP servers because ApacheDS is not a template platform, we have to use a custom LDAP.

 

As shown in the previous screenshot, fill in these fields with the values
as shown in the following table:

Field name Value entered
Host localhost
(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)

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

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.

 

Note: Make sure you save now, or you will have to repeat this again!

Once you have completed filling in the required fields, click Apply and you will then be prompted to save as seen above. You are now required to fill in the field called: Unique distinguished name of the base (or parent) entry in federated repositories. It is a bit annoying that we have to enter it again, but now you know J

Populate the field with the following to give it a name, which just so happens to the same as our base DN as well.

dc=themiddlewareshop,dc=com
  • Click Apply to save and then OK to return back to the previous screens, find your way back to Global security > Federated repositories, you should be able to click cancel on the Repository reference screen shown above

The result is the following:

  • Click OK at the bottom of the Global Security / Federated repositories screen, and you will be again asked to Save and enter a password for the wasadmin user, it is wasadmin. But note, this is not the wasadmin user in the LDAP directory, it is a user stored in the fileRegistry.xml. LDAP in this scenario is used for user administration not was administration,
  • Then click OK, and Save. Hopefully you will not return to the Global Security screen, which means all is configured

Why so many saves? It guess it’s just the order in which security.xml and other files are updated as we progress through screens.

  • Restart the server for the changes to take effect

Restriction: When you configure multiple repositories that includes the internal built-in, file-based repository, the primary administrative user name must exist in the file-based repository. If the primary administrative user name does not exist in the file-based repository, then the name is automatically created in the file-based repository. The primary administrative user name cannot exist in other repositories.

This is really import, please understand the relevance of the point in red above. If you are using a federated repository, and it contains the internal registry and that registry uses wasadmin as the primary user, then it must not exist in the LDAP tree, also the primary admin user must exist in the internal file registry for this to work as intended.

Note: If the save processes occur during this exercise then we know WebSphere Application Server was able to connect to LDAP. If it cannot you will get an error displayed, something similar to the error explained in this blog article:

http://www.themiddlewareshop.com/2015/04/13/validation-failed-secj7716e-primary-administrative-user-id-does-not-exist-in-the-registry/

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.

Wimconfig.xml

The contents of the wimconfig.xml has been altered with the required settings and can be located in the following location

/opt/IBM/WebSphere/AppServer/profiles/DV_AppServer01Prof/config/cells/DV_AppServer01/wim/config

 

 

<config:repositories xsi:type=”config:FileRepositoryType” adapterClassName=”com.ibm.ws.wim.adapter.file.was.FileAdapter”
id=”InternalFileRepository” supportPaging=”false” messageDigestAlgorithm=”SHA-1″>

<config:baseEntries name=”o=defaultWIMFileBasedRealm”/>

</config:repositories>


<config:repositories xsi:type=”config:LdapRepositoryType” adapterClassName=”com.ibm.ws.wim.adapter.ldap.LdapAdapter”

id=”LDAP1″ isExtIdUnique=”true” supportAsyncMode=”false” supportExternalName=”false”

supportPaging=”false” supportSorting=”false” supportTransactions=”false” supportChangeLog=”none”

certificateFilter=”” certificateMapMode=”exactdn” ldapServerType=”CUSTOM”

translateRDN=”false”>

<config:baseEntries name=”ou=system,dc=themiddlewareshop,dc=com” nameInRepository=”ou=system,dc=themiddlewareshop,dc=com”/>

<config:loginProperties>uid</config:loginProperties>

<config:ldapServerConfiguration primaryServerQueryTimeInterval=”15″ returnToPrimaryServer=”true”

sslConfiguration=””>

<config:ldapServers authentication=”simple” bindDN=”uid=wasldapbind,ou=security,dc=themiddlewareshop,dc=com”

bindPassword=”{xor}KD4sMzs+Lz02MTs=” connectionPool=”false” connectTimeout=”20″

derefAliases=”always” referal=”ignore” sslEnabled=”false”>

<config:connections host=”localhostcell01″ port=”10389″/>

</config:ldapServers>

</config:ldapServerConfiguration>

</config:repositories>

 


INTRODUCTION
JEE SECURITY
GLOBAL SECURITY
UNSECURE CONSOLE
TURNING ON GLOBAL SECURITY
Security Configuration Wizard
Virtual Member Manager
ROLE MANAGEMENT
Administrative roles
DISABLING GLOBAL SECURITY
SETTING THE INTERNAL REPOSITORY USING SCRIPTING
APACHEDS
Installing ApacheDS
Adding a new partition
ADDING LDAP TO A FEDERATED REPOSITORY
FEDERATED REPOSITORIES RECAP
Security settings
Wimconfig.xml

CHANGING THE OU FOR LDAP BIND
Looking at User Groups

STANDALONE LDAP
CONFIGURING THE STANDALONE LDAP SERVER
TESTING THE CONNECTION
REVIEW OF SECURITY.XML

SUMMARY

To learn more about the courses available from The Middleware Shop, please go to http://www.themiddlewareshop.com/products to see a full list of the current courses available.

Consulting

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
  • PCI DSS

Industry Qualifications & Recognition

  • TOGAF 9.1
  • IBM Champion 2013
Facebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply