ValiMunteanu-7009 avatar image
0 Votes"
ValiMunteanu-7009 asked ValiMunteanu-7009 answered

Inconsistent LDAP filter results - ldap query works only once, second (and subsequent) runs return only one user

I am trying to query an Active Directory tree for some users. The AD is configured with Nested Groups. I am using the LDAP_MATCHING_RULE_IN_CHAIN.
We are using a java class that is building this LDAP queries from a key/value configuration file. everything on this side works well; below I list the 3 properties involved where I built a filter to retrieve the users that are members to one TargetGroup (the target group has only nested groups under it):

foreign-ldap-users-of-group-searchfilter=(&(objectCategory=Person)(objectClass=user)(sAMAccountType=805306368)(memberOf:1.2.840.113556.1.4.1941:=cn=TargetGroup,ou=Test,ou=Service,DC=domainprefix,DC=domain,DC=DomainSuffix ))

*the -SearchScope SubTree is assumed by default in the java class used for querying the AD
*when using (sAMAccountName=u%) instead of (sAMAccountType=805306368) the results are empty, the (sAMAccountType=805306368) is not really necessary here (same behaviour with or without)

The issue is that it has a different behavior after first run: it works exactly once meaning that at first use is working as expected returns 12 users with their properties, but beginning with second call (running the exact same query again) the result is only one user, actually the first user that is found in the sequence.
We can't explain the behavior. Do you have some insight regarding this behavior?

Thank You!
Valentin M.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

NewbieJones-6218 avatar image
0 Votes"
NewbieJones-6218 answered ValiMunteanu-7009 commented

Not sure why you would need the sAMAccountType if you already have objectClass=user. The objectClass is already defining the type to a certain extent. If it doesn't do anything, remove it.

The main reason to use ObjectClass=User is because its an indexed field and it makes the searches much quicker when you have at least one indexed field.
sAMAccountName would only bring back one entry even if it did work.

The memberOf looks odd. What are those numbers for? 1.2.840.113556.1.4.1941

When I started with LDAP, I used Apache Directory Studio to verify searches and syntax, as it only takes one element in the wrong place to break everything.

Keep it simple to start with. Try the following.


Does that work consistently? Once that works, you can add in other attributes in a controlled manner.

One other attribute for consideration is UserAccountControl
The following is a "normal" user. Enabled user with account expiry set .

I tend to do everything with users in PowerShell now and you can test LDAP searches without having the AD CMDlets installed. For example..

 $searcher=[adsisearcher] '(&(UserAccountControl:1.2.840.113556.1.4.803:=2)(memberOf=CN=groupA,OU=Test,OU=Groups,DC=xx,DC=yy,DC=zz)(objectClass=User))'
 $searcher.FindAll() | Select-Object @{n='displayname';e={$['displayname'][0]}},@{n='mail';e={$['mail'][0]}}

· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hi Jones,

Thanks for answering. the "odd number" used is actually the OID for LDAP_MATCHING_RULE_IN_CHAIN is something similar with your UserAccountControl user Enabled.
The issue that I have here is not that filter is not working, but is working only once (first try) then is returning only first user from the total of 12 in this case.

0 Votes 0 ·
GaryReynolds avatar image
0 Votes"
GaryReynolds answered GaryReynolds commented

Hi @ValiMunteanu-7009

I have tested the LDAP_MATCHING_RULE_IN_CHAIN query against a Windows 2019 AD with LDP, NetTools and ADFind, in all cases they return the same number of objects on the first and subsequent runs. Both NetTools and ADFind initiate a new LDAP connection each time a query executed, while LDP uses a same connection for all queries. So it would appear there might be an issue with your implementation.

I can get the samaccountname filter to work but search must be the complete name or include a wildcard


Based on your query provided I'm not sure what you are trying to achieve and there may be alternative methods to get the same information.

If you are trying to get the complete list of all the members of a group included nested groups, then using the msds-tokenGroupNames attributes of the group object will return a complete list of all the DNs that are members, then its a simple search of the returned list of DNs to check if a user is a member.

Or if you want to see if a user is a member of a specific group, including nested groups, then the msds-TokenGroupNames of the user object, will return the complete list of groups that the user is a member of, again a simple search of the returned list to confirm if the user is a member of a specific group.

The downside of using the ms-TokenGroupName attribute is that it's a constructed attribute and only returned if the search scope is base. And because it's a constructed attribute, you can't use the Attribute Scope Query control to directly query the members attributes.


· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hi Gary,

Thank you for your answer, I am trying to get the complete list of members of a nested group.
Unfortunately i am trying to do this from my application side without support from AD Admin which i hope i'll get very soon, otherwise it will be impossible to get to the bottom of this.
The only issue here is that first run of the query is (correctly working) returning all the 12 users present in the "TargetGroup"; the query is exposing the result in json format on a servlet, if I hit refresh on that servlet (thus running the query agin in AD) only first user in the sequence is returned.
On the application side I can see the java class logs and in this logs everything happens without error, but the second and next runs - indeed return only one user (log is clean and the query is sent the same but returns only first user).
I think this flow uses LDP so might be that when the connection is first opened i have the correct results, then on same connection to have an issue or a limitation so I will get the inconsistent result?
From my tests it seems that this renewal of connection (i am restarting the application server - wildfly) is actually what is bringing all the 12 users.
I will wait for a meeting with the AD Admin, but from my experience with them until now (no support offered so far), i don't have too many expectations...

0 Votes 0 ·
GaryReynolds avatar image GaryReynolds ValiMunteanu-7009 ·

If think the issue is with your implementation, rather than the server. There is nothing on the server or connection that would cause the same query to return different results. The other possibility is that the srvlet is not cleaning up the previous query correctly and you are getting the results from the first query.

LDP is an application rather that an method or interface, in the case of LDP, NetTools, and ADFind they all use the LDAP API to talk to the AD.


1 Vote 1 ·
ValiMunteanu-7009 avatar image
0 Votes"
ValiMunteanu-7009 answered

I found the issue in a value of "query optimization" that was used in the java class.
There was a line in the logs for the case that was returning only one user stating: “searchLdap, property: foreign-ldap-search-optimization : set. Optimization detected so skipping second invocation of hasMoreElements.”
So I added this property to my configuration snippet and set it to false "foreign-ldap-search-optimization=false" and now the results are consistent.
Though I am not sure why this "optimization" was breaking the behaviour.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.