Clarity: LDAP Synch Job Errors out under Windows Server 2008 R2 due to LDAP: error code12 - 00002040: SvcErr: DSID-031401E0, problem 5010 (UNAVAIL_EXTENSION)

Products

• Clarity PPM SaaS
• Clarity PPM On Premise

Issue/Introduction

Description:

This only happens for customers using Windows Server 2008 R2 for LDAP. Authentication works. But, when they try to run Add/Modify New and Changed Users job, it fails with the following error under Caused by: in the bg-niku.log:

Caused by: javax.naming.OperationNotSupportedException: [LDAP: error code 12 - 00002040: SvcErr: DSID-031401E0, problem 5010 (UNAVAIL_EXTENSION), data 0]; remaining name ''

This is a Windows Server 2008 bug. See the following link:

http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/183a8f2c-0cf7-4081-9110-4cf41b91dcbf/

Here is an explanation of the problem and two possible solutions from that link:

Thought I'd follow up with you guys. Been working with Ritesh Mishra at Microsoft. He had us install the patch referenced in KB977180 followed by a reboot, which did not work by itself. But after adding the following registry key followed by another reboot, everything started working.

HKLM\System\CurrentControlSet\Services\NTDS\Parameters

Add String value DSA Heuristics

Set the value to 000000000001

Then:

We faced this issue when we used modifyTimestamp in search parameters along with others. Explanation given was below ( This has been identified as Microsoft bug and being worked upon, till that time Registry fix should work )

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

The problem is that the modifyTimeStamp is getting changed to whenChanged before the search is executed. When the original request is executed, the system builds a string, called a search argument signature , and hashes it. The resultant hash is then stored with the restart argument. When the second page is retrieved, the restart argument is queried and the search argument signature is recomputed and hashed. If the new hash does not match the stored hash, the system fails the request. The registry change I suggested yesterday causes the system to ignore the hash mismatch failure.

Here s the search argument signature that s first computed when the request originally comes in:

subtreeRoot:DC=ent,DC=bhicorp,DC=com( & ( & ( &(sn=J*)
(whenChanged>=20100713045200.0Z) ) ) )

name,displayName,objectClass,groupType,description,userAccountControl,system
FlagsCommArg.Svccntl.MinNCType(NC_Master),

Notice that whenChanged has been substituted for the original modifyTimeStamp . This is hard-coded and the actual search is based on the whenChanged attribute. When the request for the 2^nd page comes in, this is the search argument signature :

subtreeRoot:DC=ent,DC=bhicorp,DC=com( & ( & ( &(sn=J*)
(modifyTimeStamp>=20100713045200.0Z) ) ) )

name,displayName,objectClass,groupType,description,userAccountControl,system
FlagsCommArg.Svccntl.MinNCType(NC_Master),

Notice that the modifyTimeStamp has not been substituted in this case.
This is the reason for the hash mismatch and subsequent error.

A workaround would be to simply use whenChanged instead of modifyTimeStamp .

Solution:

IMPORTANT: This article contains information about modifying the registry.
Before you modify the registry, make sure to create back up of the registry and ensure that you understand how to restore the registry if a problem may occur.
For more information about how to back up, restore, and edit the registry, please review the relevant Microsoft Knowledge Base articles on support.microsoft.com.

SOLUTION 1:

1. Go to the Security page in the Clarity CSA.
2. Change the Modify Time Stamp field from modifyTimeStamp to whenChanged.
3. Repeat this for each server in the cluster.
4. Restart the app and bg services.

Now, retry the LDAP synch job. It should work.

OR

SOLUTION 2:

1. Go to the Microsoft website and follow the instructions in KB77180 to install the hotfix that fixes this bug.
2. Make the following registry change:
   
   HKLM\System\CurrentControlSet\Services\NTDS\Parameters
   Add String value DSA Heuristics
   Set the value to 000000000001
   
   
3. Reboot the Windows server.

Keywords: ClarityKB

Environment

Release: ESPCLA99000-12.1-Clarity-Extended Support Plus
Component:

Resolution

.