i received the following message from one of our developers that has been encountering issues with directory synchronization ever since we upgraded our dcs, and raised forest & domain functional level to ws08r2:
The problem exists only when connecting to an Active Directory 2008 R2 server (works for all Active Directory versions prior). We verified that the open-source code is using the correct LDAP standard API for accessing the domain controller. As further confirmation of the problem, I have also found numerous forum posts online for a variety of other applications (Alfresco, Java, Oracle, Symantec, Liferay, etc.) experiencing the same problem as we are seeing (worked up until an upgrade to 2008 R2).
It seems to be an inherent problem with Microsoft's pagination control "1.2.840.1135126.96.36.1999 (pagedResultsControl)" in AD 2008 R2, and Microsoft has not released a fix yet.
We are going to discontinue use of Active Directory for synchronization from our applications, as all of our applications utilize standards-based technologies (e.g. LDAP), and it is clear that Microsoft is moving away from supporting the necessary standards.
Thank you for all your help looking into this on your end, but it seems like we will have to wait for Microsoft to release a fix for this one.
we applied kb977180-v2 http://support.microsoft.com/kb/977180 to each dc, but we apparently still have an issue... anybody have suggestions to keep our developers from abandoning ad for directory searches?
not according to http://msdn.microsoft.com/en-us/library/cc223320(PROT.10).aspx
What exactly are the problems you are running into?
We are having the same problem with Oracle's SSO app...only returns 249 objects. We get all objects when pointing to 2003 domain controllers.
Can we get an answer to this??? What exactly has changed with regard to Server 2008 and the pagedResultsControl?
Oracle is already pointing a finger at Microsoft:
here's the error message we're apparently receiving in our app's logs (occurs when trying to query the "next page" in a paged query):
Caused by: javax.naming.OperationNotSupportedException: [LDAP: error code 12 - 00002040: SvcErr: DSID-031401E7, problem 5010 (UNAVAIL_EXTENSION), data 0]; remaining name 'ou=people,dc=domain,dc=local'
Getting same error. Applied Patch but no luck. This is Java applicaiton which is trying to pull Active directory (Windows 2008) Users using Pagination. What I observed that if Result set is less than Pagination size ( say LDAP search filter returns 100 records while Paginaiton size is set to 200 ) then it doesn't return any error and it goes smooth. But when Result is larger and pagination happens it throws the error below. ( Pagination or whatsoever works fine Windows 2003 LDAP Server, issue being faced is on Windows 2008 server only )
com.niku.security.directory.DirectoryServiceException: javax.naming.OperationNotSupportedException: [LDAP: error code 12 - 00002040: SvcErr: DSID-031401E7, problem 5010 (UNAVAIL_EXTENSION), data 0
]; remaining name ''
Any clues ?
one change in WS08 R2 is that a continued search is required to have the same search argument as the original search, so your paged search might fail against WS08 R2 if the continued search has say a different search base. There's an example of this problem here:
and I know of at least one other third-party product that has an issue as a result of this change. A packet trace or debug step through of your code might indicate if this is the problem you are hitting. Increasing AD DS diagnostics IIRC will log an event if this is the case, although caution is required when doing this on a production DC.
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.
Add String value “DSA Heuristics”
Set the value to 000000000001
I hope this helps.
As Jason mentioned, this problem is RESOLVED by making above registry change. 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) ) ) )
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<sup>nd</sup> page comes in, this is the “search argument signature”:
“subtreeRoot:DC=ent,DC=bhicorp,DC=com( & ( & ( &(sn=J*) (modifyTimeStamp>=20100713045200.0Z) ) ) )
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”.
- Proposed as answer by Vishal Seth Friday, February 17, 2012 5:50 AM
Dear Csp122,you can get contact with Aukcell to help you out on the issue.
Aukcell is a seasoned and recognized expert in all aspects of Liferay deployment ,which is based in China. There are lots of details that you need to setup correctly in order to make Liferay work your way. Aukcell know them all. Business case? Architecture? Theme? Custom portlets? Performance tuning? Migration from other portals? Liferay training ?Liferay custom consutling ? We have done that. And much more.
At Aukcell you’ll find one-stop solutions for all your Liferay projects: From support, consulting and training we offer services to help you implement and develop Liferay based solutions.
Skype : aukcell
We have the same issue on AD Windows 2008 R2
- applied kb977180-v2 http://support.microsoft.com/kb/977180
-and added key
Add String value “DSA Heuristics”
Set the value to 000000000001
after this issue solved , MANY THANKS!
- Proposed as answer by Mantu Shaw Wednesday, April 17, 2013 11:05 AM
Confirming that Jason/SangeetC's posts helped fix this exact same problem in our environment. We did NOT do the registry change but simply used the whenChanged filter keyword instead of the modifyTimestamp keyword.
Ours was .Net code that was failing against a Windows 2008 R2 SP1 domain controller. SP1 already has the KB 977180 fix so we knew that did not fix it.
the error we saw was:
System.DirectoryServices.DirectoryServicesCOMException (0x8007202C): The server does not support the requested critical extension.
As mentioned just using the whenChanged keyword in the filter solved this problem. As a side note we did not have this problem when going against our windows 2003 domain controller.
i recently experienced similar issue using LDAP connector via an app running on Win2008 R2. It was successully 'connected' but we haven't been able to pull user related info from the group. I did follow instructions suggested by #stefanvsn but that didn't help (NOTE: KB article i tried to install showed as 'not relevant'?!).
Here is the extract from the log file hence was wondering if you could comment/advise how can we remedy it? 2013-03-25 11:38:00,546 [common] [JettyThread-22392] ERROR U:tomadej o.s.l.c.AbstractRequestControlDirContextProcessor - No matching response control found for paged results - looking for 'class javax.naming.ldap.PagedResultsResponseControl
2013-03-25 11:38:00,546 [common] [JettyThread-22392] WARN U:tomadej c.c.t.m.u.exception.ExceptionWrapper - Unknown LDAP exception
org.springframework.ldap.OperationNotSupportedException: [LDAP: error code 12 - The server is not configured to pass through control 1.2.840.1135188.8.131.529]; nested exception is javax.naming.OperationNotSupportedException: [LDAP: error code 12 - The server is not configured to pass through control 1.2.840.1135184.108.40.2069]; remaining name ''