I couldn't get much help from Microsoft folks as objectGUID is an indexed attribute and so searches ought to be fast. They suspect Java client issues?
I am searching an AD server using a Java LDAP client from Linux. On some AD setups, searching by objectGUID is extremely slow; at one of our customer's, it consistently takes 60+ seconds. Searching using search base of the GUID looks like it might be faster. Shouldn't objectGUID be an indexed attribute? Why would it be that slow? In another customer, AD was slow but their Global Catalog was faster (the first customer does not have a GC).
LDAP search parameters:
Base = DC=example,DC=com (got this from rootDSE as defaultNamingContext)
Search filter: (|(objectGUID=\b5\86\c6\5f\a1\67\a5\41\a3\66\41\7d\01\47\de\ef)(entryUUID=5fc686b5-67a1-41a5-a366-417d0147deef)(nsuniqueid=5fc686b5-67a141a5-a366417d-0147deef)) // so I can search in other LDAP servers
scope: SUB
attrs: cn description
I guess the Microsoft preferred form would be
Base = <guid=5fc686b5-67a1-41a5-a366-417d0147deef>
Search filter: (objectClass=*)
Scope: base
attrs: cn description</guid=5fc686b5-67a1-41a5-a366-417d0147deef>
The one thing I noticed is that if I used command line ldapsearch, for the first method, I get a referral which is back to where I asked. (referall back to example.com). It couldn't follow the referral automatically (but can from unboundid sdk)
Thanks much to help us debug this performance issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don’t really know much about Active Directory-specific things, and I know nothing at all of its configuration, so I won’t be of much help there. However, it seems extremely unlikely that the LDAP SDK is adding 60+ seconds onto the processing time of something that you expect to be instantaneous. That’s especially true if you only see the problem for certain operations.
It sounds like you’re saying that searching with the filter “ (|(objectGUID=\b5\86\c6\5f\a1\67\a5\41\a3\66\41\7d\01\47\de\ef)(entryUUID=5fc686b5-67a1-41a5-a366-417d0147deef)(nsuniqueid=5fc686b5-67a141a5-a366417d-0147deef))” is slow. This filter tries to search the directory for three different attribute types, and it’s an OR search. That means the server has to find all entries that match the first criteria, plus all entries that match the second criteria, plus all entries that match the third criteria. That means that all three components must be fast, and if any one of them is slow, then the entire search will appear slow. I don’t know whether Active Directory supports entryUUID, but I highly doubt that it supports nsUniqueID. It’s possible that if you issue a search with an attribute that AD doesn’t recognize, it could have to crawl the entire database looking at each individual entry to see if it might have that attribute. The same is also true if AD has been updated to know about that attribute type but hasn’t been indexed for it.
What I would recommend would be to try breaking that filter down into three separate searches rather than just one filter that ORs them together. That will let you see which components are slow and which are fast. Once you decide that, you can decide how to proceed.
If you find that it’s not feasible to make that search fast, then you might just need to find a way to issue only the fast part of the filter and leave off the slow part that you know won’t match anything. You could do that by looking at the root DSE to see what kind of server it is, or perhaps by looking at the schema to see which attribute types are defined.
And by the way, the version of ldapsearch that comes with the LDAP SDK (which you can run by invoking “tools/ldapsearch {args}” or “java -jar unboundid-ldapsdk.jar ldapsearch {args}”) does support referrals. By default, it will tell you if it gets a referral back rather than trying to follow it, but if you add the --followReferrals argument to the command line, then it will try to follow any referrals that are returned.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks much. ActiveDirectory does not have entryUUID or nsuniqueid and so I presumed that it would just search on objectGUID. Will try with the unboundid ldapsearch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I couldn't get much help from Microsoft folks as objectGUID is an indexed attribute and so searches ought to be fast. They suspect Java client issues?
I am searching an AD server using a Java LDAP client from Linux. On some AD setups, searching by objectGUID is extremely slow; at one of our customer's, it consistently takes 60+ seconds. Searching using search base of the GUID looks like it might be faster. Shouldn't objectGUID be an indexed attribute? Why would it be that slow? In another customer, AD was slow but their Global Catalog was faster (the first customer does not have a GC).
LDAP search parameters:
Base = DC=example,DC=com (got this from rootDSE as defaultNamingContext)
Search filter: (|(objectGUID=\b5\86\c6\5f\a1\67\a5\41\a3\66\41\7d\01\47\de\ef)(entryUUID=5fc686b5-67a1-41a5-a366-417d0147deef)(nsuniqueid=5fc686b5-67a141a5-a366417d-0147deef)) // so I can search in other LDAP servers
scope: SUB
attrs: cn description
I guess the Microsoft preferred form would be
Base = <guid=5fc686b5-67a1-41a5-a366-417d0147deef>
Search filter: (objectClass=*)
Scope: base
attrs: cn description</guid=5fc686b5-67a1-41a5-a366-417d0147deef>
The one thing I noticed is that if I used command line ldapsearch, for the first method, I get a referral which is back to where I asked. (referall back to example.com). It couldn't follow the referral automatically (but can from unboundid sdk)
Thanks much to help us debug this performance issue.
I don’t really know much about Active Directory-specific things, and I know nothing at all of its configuration, so I won’t be of much help there. However, it seems extremely unlikely that the LDAP SDK is adding 60+ seconds onto the processing time of something that you expect to be instantaneous. That’s especially true if you only see the problem for certain operations.
It sounds like you’re saying that searching with the filter “ (|(objectGUID=\b5\86\c6\5f\a1\67\a5\41\a3\66\41\7d\01\47\de\ef)(entryUUID=5fc686b5-67a1-41a5-a366-417d0147deef)(nsuniqueid=5fc686b5-67a141a5-a366417d-0147deef))” is slow. This filter tries to search the directory for three different attribute types, and it’s an OR search. That means the server has to find all entries that match the first criteria, plus all entries that match the second criteria, plus all entries that match the third criteria. That means that all three components must be fast, and if any one of them is slow, then the entire search will appear slow. I don’t know whether Active Directory supports entryUUID, but I highly doubt that it supports nsUniqueID. It’s possible that if you issue a search with an attribute that AD doesn’t recognize, it could have to crawl the entire database looking at each individual entry to see if it might have that attribute. The same is also true if AD has been updated to know about that attribute type but hasn’t been indexed for it.
What I would recommend would be to try breaking that filter down into three separate searches rather than just one filter that ORs them together. That will let you see which components are slow and which are fast. Once you decide that, you can decide how to proceed.
If you find that it’s not feasible to make that search fast, then you might just need to find a way to issue only the fast part of the filter and leave off the slow part that you know won’t match anything. You could do that by looking at the root DSE to see what kind of server it is, or perhaps by looking at the schema to see which attribute types are defined.
And by the way, the version of ldapsearch that comes with the LDAP SDK (which you can run by invoking “tools/ldapsearch {args}” or “java -jar unboundid-ldapsdk.jar ldapsearch {args}”) does support referrals. By default, it will tell you if it gets a referral back rather than trying to follow it, but if you add the --followReferrals argument to the command line, then it will try to follow any referrals that are returned.
Thanks much. ActiveDirectory does not have entryUUID or nsuniqueid and so I presumed that it would just search on objectGUID. Will try with the unboundid ldapsearch.