1. As mentioned, Partial Attribute Set (PAS) attributes are not necessarily
indexed. These are not related in AD. However if you put something in the
PAS because you want to do searches against that attribute, you will often
see the object indexed as well.

2. Most every query that only specifies objectclass[1] in a default Active
Directory is inefficient because objectclass is not indexed and it means AD
will need to look at every object within the scope of the query to determine
whether or not an object matches. This means if you generate a subtree
search based at the domain NC down and you have 10,000 objects and you only
have 14 objects of the needed class (for arguments sake,
organizationalUnit), AD would have to look at 10,000 objects instead of 14
objects to figure out what to return.

3. I have had several discussions with folks on this on and offlist and
pretty much am very strongly for indexing objectclass. I haven't personally
seen a case where it turned out to be a bad thing. The more likely you are
to run LDAP apps either run from or ported from UNIX counterparts the more
likely this is going to help because objectclass usually appears to be
indexed in other directories. This also used to help with Exchange 2000
because there were several bad queries that used no indexed attributes and
indexing objectclass made it so those queries did use an indexed attribute,
to my knowledge, those have mostly all been fixed however I can't say I have
done a comprehensive study of all Exchange queries. Generating a list of all
queries going against AD is more of a pain than it needs to be right now
IMO. But anyway, I think that a general going in statement is that it is
good to index objectclass, the investment is generally quite minimal (I had
heard fear stories of possible DIT growth of 50% but have never seen
anything over about 10%). The worst problem is if you happen to have a
program that makes various assumptions based on an attribute being indexed
and starts acting a little odd in some cases afterward. There was a product
from a major vendor that used to do something unusual with how it displayed
information once you indexed objectclass and selected the objectclass column
for sorting (obviously sorting on a multivalue attribute is undefined and
therefor disallowed) but that was straightened out some time ago. If someone
from that company or someone who used to be with that company wants to out
themselves I will let them do so. I will say that once they saw the issue,
they responded quickly and well to it.


4. To determine if a specific attribute is indexed or not, you simply look
at bit 0 (value 1) on the searchFlags attribute. If you want to quickly find
indexed attributes in your directory, you can use ADFIND V01.31.00 do so
with

adfind -sc indexed

Or

adfind -sc indexedl



5. For completeness, if you want to quickly find PAS attributes in your
directory, you can do so with 

adfind -sc pas

Or

adfind -sc pasl

Note that there is more than one way that an attribute could be specified to
be part of the PAS. There is the standard isMemberOfPartialAttributeSet=TRUE
but there is also a systemFlags bit that corresponds to it for things that
Microsoft wants in the PAS and doesn't want you changing. These switches
properly find both items. Run the commands and add the -po switch to see
exactly what it is querying for.

No you cannot combine those switches and get all indexed attributes that are
in the PAS. I stopped just short of inventing a new query language to ride
on top of LDAP, it kind of bothered me when I saw myself moving in that
direction. :)  What would I call it? jQL?? joeLDAP??? RooBurger[2]???? 


6. Oh, one question sort of asked was WHY did MS do this? Well "as I
understand it"(tm), early pre-beta Windows 2000 AD revs did not handle
indexing of multivalue and non-unique value attributes well. The fact that
objectclass was both non-unique and multivalued is a double whammy if
neither of those is good. MSFT fixed both issues but no one ever went back
and corrected the schema def before release and I know some very bright
folks in MSFT were like, oops, we should have done that. You will often hear
this wives tale (or maybe urban legend) running around that you can't index
non-unique or multivalue attributes and it is completely bogus. You _may_
not get as much bang for your buck doing it but will get some benefit at
some level if you use that attribute to search with and don't have another
index in the query. I have even heard MCS folks spout this urban legend and
I usually ask them to join me in the corner for a quick chat for a moment
when they say it (MCS are people too). There is a rumour that the default
index state of objectclass may change in LongHorn Server, I recommend folks
check for themselves.

I think I have blogged on this once or twice and certainly the ADORG
archives will have more than one post on this topic from myself and others.
But again, if someone asks me if they should index objectclass, I will
usually respond with, you mean you haven't already??? Seriously, test it in
your lab, make sure non of your management or LOB apps have an issue with
it, specifically look for cases where they are using the fact that an
attribute is indexed or not as a indicator that you can sort on the
attribute because that is one issue I have personally seen. If you run into
that or some other issue, do not hesitate to tell the vendor, you can even
have them contact me if you want and I can explain. Most vendors will find I
am very easy to get along with if they are willing to change their evil ways
and I will explain the "better" ways to do things they may be running into.
I like doing it because it makes things better for me when I walk into
companies and know that vendor xyz "gets it" and I don't have to focus quite
so much on things they make when looking for problems. Plus I like having
various vendors being aware of me and being willing to listen because it
makes it easier to get their attention if I find a problem with their
products. 


  joe 



[1] The exception here where this is ok is the EXISTS filter which is
objectclass=*, this is perfectly fine to use. 
[2] In the tradition of naming something that has absolutely nothing to do
with anything about the thing....


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matheesha
Weerasinghe
Sent: Tuesday, April 18, 2006 1:00 PM
To: [email protected]
Subject: [ActiveDir] stupid ldap queries

All

Could someone please explain how Non-indexed queries (e.g.
"objectClass=user") fall in this category? I saw this mentioned in some
slides by Gil and couldnt quite understand what he meant. Isn't objectclass
indexed as part of the partial attribute set?

Thanks

M@
List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to