Recipient Validation Fails for Some Users: DDS Log Shows error code 32 - No Such Object

book

Article ID: 156907

calendar_today

Updated On:

Products

Messaging Gateway

Issue/Introduction

  • Some end users in the environment are not able to be successfully validated as a good recipient.
    To verify this follow these steps:
    1. Login to the  Symantec Messaging Gateway (SMG) Brightmail Control Center (BCC)
    2. Click on Administration->Settings->Directory Integration
    3. Click on the name of the LDAP server where the end user's mail address is stored.
    4. Click on the Recipient Validation Tab
    5. Enter in the email address of the affected user and press Test Query
    6. Seeing an error message of "The test address was not found in the directory (invalid recipient)." indicates this condition.
     
  • In the DDS log shows the following error "[LDAP: error code 32 - No Such Object]" when the BCC is used to Validate the affected user in the prior steps.
  • When the DDS log is set to DEBUG logging levels, the log shows that the affected user is located however, the second query to load the user's attribute fail.
    For example the following shows a initial lookup for [email protected] which succeeds:
     ...
     Jul 24 2012 19:40:24 [btpool0-1] [DDSSocketFactory] DEBUG - [Lotus Domino LDAP 01]   host: 10.85.209.3
     Jul 24 2012 19:40:24 [btpool0-1] [DDSSocketFactory] DEBUG - [Lotus Domino LDAP 01]   port: 389
     Jul 24 2012 19:40:24 [btpool0-1] [DDSSocketFactory] DEBUG - [Lotus Domino LDAP 01]   connect timeout: 30000
     Jul 24 2012 19:40:24 [btpool0-1] [DDSSocketFactory] DEBUG - [Lotus Domino LDAP 01]   idle timeout: 120000
     Jul 24 2012 19:40:24 [btpool0-1] [DDSSocketFactory] DEBUG - [Lotus Domino LDAP 01] Socket successfully created to 10.85.209.3:389
     Jul 24 2012 19:40:24 [btpool0-1] [DirContextPoolableObjectFactory] DEBUG - [Lotus Domino LDAP 01] Created new READ_ONLY DirContext='[email protected]'
     …
     Jul 24 2012 19:40:24 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01] query string for recipient: [email protected]
     Jul 24 2012 19:40:24 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01]    is: (&(|([email protected])([email protected]))(mail=*))
     Jul 24 2012 19:40:24 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01] ldapTemplate.search: baseDN: o=OrganizationName query: (&(|([email protected])([email protected]))(mail=*))
     Jul 24 2012 19:40:24 [btpool0-1] [FastSyncKeyedObjectPool] DEBUG - [Lotus Domino LDAP 01] fetched idle connection from pool
     Jul 24 2012 19:40:24 [btpool0-1] [DDSDirContextValidator] DEBUG - [Lotus Domino LDAP 01] DirContext validation succeeded
     Jul 24 2012 19:40:24 [btpool0-1] [FastSyncKeyedObjectPool] DEBUG - [Lotus Domino LDAP 01] returning connection to idle pool 
     Jul 24 2012 19:40:24 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01]   found the following result for recipientEmail: [email protected] 
     Jul 24 2012 19:40:24 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01]     cn=affected user,ou=corp,ou=US,o=OrganizationName
     ...

In the second query for the user in the DDS log we can see the LDAP query fail for this user:

...
    Jul 24 2012 19:40:24 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01] fetching Recipient or Group getGenericByUniqueId() for cn=affected user,ou=corp,ou=US,o=OrganizationName
     Jul 24 2012 19:40:24 [btpool0-1] [FastSyncKeyedObjectPool] DEBUG - [Lotus Domino LDAP 01] fetched idle connection from pool
     Jul 24 2012 19:40:24 [btpool0-1] [DDSDirContextValidator] DEBUG - [Lotus Domino LDAP 01] DirContext validation succeeded
     Jul 24 2012 19:40:26 [btpool0-1] [FastSyncKeyedObjectPool] DEBUG - [Lotus Domino LDAP 01] returning connection to idle pool
     Jul 24 2012 19:40:26 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01] couldn't resolve entry for: cn=affected user,ou=corp,ou=US,o=OrganizationName
     Jul 24 2012 19:40:26 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01] (this is expected when the lookup is a result of membership building and there is more than one address resolution source)
org.springframework.ldap.NameNotFoundException: [LDAP: error code 32 - No Such Object]; nested exception is javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=affected user,ou=corp,ou=US,o=OrganizationName'
        at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:172)
     ...
 
  • There are other users in the environment that recipient validation succeeds as expected for.
  • There are failing users and the succeeding users that are within the same LDAP OU structure.

 

Cause

There is an underlying issue with the account that is being access by SMG.  The LDAP server is responding back to SMG that the expected account object is not present.

Resolution

Contact your local LDAP admin to help troubleshoot the issue.  Specifically the LDAP admins should be given examples of LDAPsearch queries for a working user and one for a failing user for comparison.  See the additional information section for the recommended set of data to provide.

 

Additional Information:

The ldapsearch tool which comes installed on SMG can be used to help verify this issue.  By using the same queries that SMG uses, the ldapsearch tool can help verify where the issue is coming from.  

For example, from the above DDS logs from SMG, we can create the same initial query in the ldapsearch too, here <login> is the account used by SMG to access the LDAP server:

ldapsearch –D <login> -x –b ”O=OrganizationName” –h 10.85.209.3 –W ‘(&(|([email protected])([email protected]))(mail=*))’

This query is expected to succeed and return information to the screen.  
The second query, based on the information from the DDS log, would appear similar to the following:

ldapsearch -x -b "cn=affected user,ou=corp,ou=US,o=OrganizationName" -W "objectClass=*" -D "<login>" -h 10.85.209.3

The above query is expected to fail for this issue with the Error code 32 message.

These queries should be used for two users, a working user and a user where the recipient validation fails.   For a working user the OU and O paths should be the same as the affected user to make troubleshooting the affected user as easy as possible.  

For example, the queries for a working user would be similar to the following and would both succeed without errors:

ldapsearch –D <login> -x –b ”O=OrganizationName” –h 10.85.209.3 –W ‘(&(|([email protected])(uid= working_user @place.com))(mail=*))’

ldapsearch -x -b "cn= working user ,ou=corp,ou=US,o=OrganizationName" -W "objectClass=*" -D "<login>" -h 10.85.209.3