CA Single Sign-On Error# '32': Analysis & Resolution

By: Badal Bhushan, CoreBlox Consultant

Summary of the Problem: Customer reported that their SMPS logs gets filled up with error messages like this one:

[28393/3935185808][Thu Sep 22 2016 11:06:04][SmDsLdapConnMgr.cpp:1180][ERROR][sm-Ldap-02230] Error# '32' during search: 'error: No such object matched dn: ou=people,ou=customer,dc=xxxxxxxx,dc=com' Search Query = 'objectclass=*'

[28393/3945675664][Thu Sep 22 2016 11:06:04][SmDsLdapConnMgr.cpp:1180][ERROR][sm-Ldap-02230] Error# '32' during search: 'error: No such object matched dn: ou=people,ou=customer,dc=xxxxxxxx,dc=com' Search Query = 'objectclass=*'

The actual end users do not seem to be impacted by the error, but it creates a nuisance for administrators who review the SMPS logs.

Analysis: We enabled the Policy Server profiler logs. While reviewing the profiler logs for one of the request with Error 32, we made the following finding:

 

[09/22/2016][11:06:07.547][11:06:07][28393][3998124944][SmDsDir.cpp:66][CSmDsDir::CSmDsDir][][][][][][][][][][][][][][][][][][][About to initialize directory, Oid='0e-00059d48-066c-1174-a102-8301b3dd0000', Name='customer group bind'][][Start of call InitDir.]

[09/22/2016][11:06:07.548][11:06:07][28393][3998124944][SmDsUser.cpp:144][CSmDsUser::CSmDsUser][][][][][][][][][][][][][][][][][][][About to initialize User 'uid=zxcvbn,ou=people,ou=customer,dc=xxxxxxxx,dc=com' in dir 'psysadm customer group RAM bind'][][Start of call InitUser.]

[09/22/2016][11:06:07.550][11:06:07][28393][3998124944][SmDsLdapConnMgr.cpp:1180][][][][][][][][][][][][][][][][][][][][][][LogMessage:ERROR:[sm-Ldap-02230] Error# '32' during search: 'error: No such object matched dn: ou=people,ou=customer,dc=xxxxxxxx,dc=com' Search Query = 'objectclass=*']

[09/22/2016][11:06:07.550][11:06:07][28393][3998124944][SmDsLdapConnMgr.cpp:1191][CSmDsLdapConn::SearchExts][][][][][][][][][][][][][][][][][][][][][LDAP search of objectclass=* took 0 seconds and 2278 microseconds]

[09/22/2016][11:06:07.550][11:06:07][28393][3998124944][SmDsLdapProvider.cpp:2275][CSmDsLdapProvider::Search][][][][][][][][][][][][][No such object][][][][][][(Search) Base: 'uid=zxcvbn,ou=people,ou=customer,dc=xxxxxxxx,dc=com', Filter: 'objectclass=*'][][Ldap Search callout fails.]

Now, the user zxcvbn does not exist in the User Directory 'customer group bind'. In fact, the user does not exist in any user directories the customer has setup. Looking at the User Directory connection:

One can see the LDAP User DN Lookup defined as: UID=*,ou=people,ou=customer,dc=xxxxxxxx,dc=com

If you DO NOT use parentheses in the lookup start and end, then it is assumed that ALL of the users who will be authenticating have IDENTICAL DN's, except for whatever will be entered at the prompt. As a result, there is no search executed. Whatever the user types at the prompt will be sandwiched in between the lookup start and end, and this will be considered a valid DN to bind to the directory.

When a user lookup happens for this UD, it puts the userID typed in(zxcvbn) and searches for the DN:

'uid=zxcvbn,ou=people,ou=customer,dc=xxxxxxxx,dc=com'

If the DN lookup for above DN does not fetch any match, it will throw this error:

 (Search) Base: 'uid=zxcvbn,ou=people,ou=customer,dc=xxxxxxxx,dc=com', Filter: 'objectclass=*'][][Ldap Search callout fails.]

In the corresponding SMPS logs it will log an Error 32. Based on the above flow, this is a valid error we see in the logs as the user DN does not match the defined User DN lookup.

We found all the reported errors (with UTCB Policy servers) were for non-existent users. In previous versions of CA SSO, this error may not be reported. However, for R12 onwards we see this error reported along with the invalid cred error (error 49).

Solution: If you are seeing these errors consistently every minute then there might be a monitor/probe/script using old user creds which do not exist in the User Stores. Search for these connections and contact the team to update the credentials they are using. Alternatively, if the probe is no longer required, disable it. This should reduce the frequency of errors reported.

Workaround: As a workaround option, update the User Directory to have a different User DN Lookup such as:

(&(uid= *)(objectclass=*))

With the root still defined to 'ou=people,ou=customer,dc=xxxxxxxx,dc=com', error reports such as those above should be avoided.