Connections authentication with an AD forrest by using the Global Catalog

This blog post gives some insight how you can configure a WebSphere server
to use the Global Catalog functionality of an Active Directory LDAP as the user repository.

This is the complete LDAP tree of the entire AD forrest. You can reach this Global Catalog
on port 3268. IBM isn’t supporting this but exceptions are known to be made.

A note about limitations of the GC

There are limitations to the Global Catalog. Users from the local domain controller contain
group “memberOf” information. Users from a foreign domain controller contain
limited “memberOf” information because the global group information is not replicated
to every domain controller.

See ->…….ss.doc/info/exp/ae/csec_was_ad_globcat.html

Using the GC is really helpful in AD forrest where domain controllers are spread around
the globe. Imagine a forest with the top level domain set as BIGCOMPANY.COM
and three sub domains named EMEA. AM and AP. Users are only created under
these three sub-domains.

The EMEA domain controller is located in Belgium, the AM DC is located in America and
the AP one is located in New Zealand. All the three servers will contain references
to all the other domain controllers.

When contacting each of the DC’s on port 389 you will be able to browse all content
of the forest but you will notice a drop in performance when you go browsing through
content that reside on a DC in a different continent.

Also these references will not work for the authentication process in WebSphere.
Configuring all three DC’s within WebSphere is an option but WebSphere will try to
resolve the user against all three DC’s.

Even if the user JDOE is found in the EMEA domain it will also try to find it
in the AM and AP domain. This will have a performance impact.

One side thing which you have to be aware of when working with an AD structure
which involves multiple domains is the chance on duplicate sAMAccountName’s.

When you use the sAMAccountName attribute as the login id which it is not unique in
the AD forrest you will have issues with WebSphere when authentication with this user.

– A userPrincipalName must be unique throughout the whole AD forest
– A sAMAccountName must be unique throughout a domain

To workaround this you can configure the userPrincipalName as the login id. Most
users will not know their userPrincipalName ( ) but if
you configure your Connections setup with SPNEGO than this is no problem.

How to do it

WebSphere part

Edit the following file on the DMGR


Change the following section <config:ldapServers> so it points to your GC server.
//You can also do this step by changing it the normal way in the WAS admin console.

Copy the following section

        <config:attributes name=”samAccountName” propertyName=”uid”>

Add and change the copied section like this

        <config:attributes name=”userPrincipalName” propertyName=”cn”>

And change this property to cn


Perform a full sync. to push it to the underlying nodes.

Connections part

Specify the userPrincipalName as the loginId and uid value in the TDISOL
file and run the sync_all_dns command.

This entry was posted in ibm connections. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please leave these two fields as-is:

Protected by Invisible Defender. Showed 403 to 890,155 bad guys.