How do I interpret the LDAP error messages in the hub log when an LDAP login failure occurs?

Document ID : KB000034380
Last Modified Date : 14/02/2018
Show Technical Document Details

Question:

How do I interpret the LDAP error messages in the hub log when an LDAP login failure occurs?


Answer:

The following example shows a typical error that might occur in the UIM Hub log when an LDAP login failure occurs:

Jun 8 13:33:48:100 [3500] hub: (nim_ldap_query) ldap_search_ext_s(base:=OU=USA_Users,DC=hq,DC=w2k,DC=mycompany,DC=com scope:=LDAP_SCOPE_SUBTREE filter:=(&(objectClass=person)(|(userPrincipalName=george@hq.w2k.mycompany.com)(sAMAccountName=george@hq.w2k.mycompany.com))) attrs:=displayName, userPrincipalName, memberOf
Jun 8 13:33:48:162 [3500] hub: (nim_ldap_query) ldap_search_ext_s: LDAP_SUCCESS
Jun 8 13:33:48:162 [3500] hub: (nim_ldap_query) entries count:= 0, paging results:=no
Jun 8 13:33:48:162 [3500] hub: login [LDAP] - (logon_user) 0 user found for (&(objectClass=person)(|(userPrincipalName=george@hq.w2k.mycompany.com)(sAMAccountName=george@hq.w2k.mycompany.com))), do not know which to use.

------------------------------------------------------------------------------------------------------



The first line logs the actual LDAP search that is going to be performed. This is essentially what we will be passing directly to the LDAP Server.

The following list breaks down the various portions of the above log message:

base:=OU=USA_Users,DC=hq,DC=w2k,DC=mycompany,DC=com

This specifies the "top of the tree" - we are going to begin our LDAP search starting with the above OU/DC combination.

scope:=LDAP_SCOPE_SUBTREE 

This defines the scope of the LDAP search - this is not configurable.  It indicates that the current level (base) and everything below it is included in the search path.


filter:=(&(objectClass=person)(|(userPrincipalName=george@hq.w2k.mycompany.com)(sAMAccountName=george@hq.w2k.mycompany.com)))

This means that we are searching for all LDAP Objects which are in the objectClass "person" which means we are searching user accounts.  We also must match any account which has an attribute called “userPrincipalName” which is equal to “george@hq.w2k.mycompany.com”, or if the object has a attribute called “sAMAccountName” which is equal to “george@hq.w2k.mycompany.com”. Either one is OK with us.


attrs:=displayName, userPrincipalName, memberOf 

With this last bit, we ask to return only three attributes which are of interest to us at this time, which are displayName, userPrincipalName and memberOf.

Next, we see the following line in the log:

 

Jun 8 13:33:48:162 [3500] hub: (nim_ldap_query) ldap_search_ext_s: LDAP_SUCCESS 


This indicates that the search went OK according to the LDAP libraries. No network problems were detected and the directory server did not find anything wrong with our search request and returned an "OK" response to our initial query request.

The next line indicates that we did not find any matches:

Jun 8 13:33:48:162 [3500] hub: (nim_ldap_query) entries count:= 0, paging results:=no 

The final line is intended to warn us if the search returns more than 1 object, because if we match more than one user the hub is not sure which one to use - if two users share the same username we cannot tell them apart. 

However, in this case the line indicates that there were 0 matches:

Jun 8 13:33:48:162 [3500] hub: login [LDAP] - (logon_user) 0 user found for (&(objectClass=person)(|(userPrincipalName=george@hq.w2k.mycompany.com)(sAMAccountName=george@hq.w2k.mycompany.com))), do not know which to use. 

This means, simply put, that 0 users were found who had a userPrincipalName or sAMAccountName matching the given login identity - either because the user does not exist, is not a member of an appropriate LDAP Group linked to a UIM ACL, or is located somewhere in the LDAP tree that is not covered by the base/scope above.