Indexing attributes for containerized searches

gordonah · Guest

I'm having an issue where a particular 3rd party product is taking an
excessive time performing a search against the (healthy) AD.

I was thinking about potential causes and resolutions (turns out the
attribute is indexed and replicated to GC which were my first ideas), and
came across the schema attribute property "Index This Attribute For
Containerized Searches In The Active Directory"?
The only reference I can find to this is (from on-line copy of "Inside
Windows Server 2003");
"The search routines provided in the LDAP API and with Microsoft ADSI
permits searching a container rather than the entire directory. You can
select this option to improve lookup times for container searches."

I think I understand what this means, but can anyone provide a more
detailed explanation, or example of where it is applicable? (I don't think
it's useful in my case, but my interest has been pricked).

Thanks.

Gordon

Joe Richards [MVP] · Guest

I discuss this search flag in the book in the signature.

It is only good for one level queries - a query against objects in a single
container.

Define excessive time.

What is the exact search parameters... scope, filter, base, port, etc.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net

---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

gordonah wrote:

gordonah · Guest

Joe

thanks for the clarification. I thought it was a red herring in my case, but
I realised I didn't actually know the exact purpose of the option. I haven't
used your book before, but if it's got the low down on obscure stuff like
that, may be I should pick it up.

I'm going to attend the site to look drill down on this one tomorrow, but as
it stands.

In this case an application group are investigating a 3rd party sales
application, and have been directed to use the corporate AD for
authentication, if viable. They've found that this leads to 'excessive' logon
time as if set to AD logon takes 1 min whereas it's a few second if the app
uses it's own local db.

As part of the authentication the application is coded to look up a certain
user attribute (PrimaryGroupID), and I suspect that this is the root problem.
The attribute is (by default) indexed and in the partial attribute set.
Search is set for user account objects at the root of a domain, including
search of sub-tree. Using LDAP over 389 on a flat network to a local DC in
same domain which is not experiencing any known performance problems.
Ultimately, this needs to be working securely in a multi-domain forest, but
for now we just want to get it working satisfactorily.
I've noted through technet that there are a couple of funnies about the
attribute, so I'll check along those lines as well.

Gordon

"Joe Richards [MVP]" wrote:

Joe Richards [MVP] · Guest

Retrieving the primarygroupid is fast assuming you know the user. The hard
question is how do they resolve it. There are some really bad ideas out there on
how to do it... for instance I once saw a company who pulled all global groups
from AD and compared the primarygroupid value to the primarygrouptoken.

The reason they did it that was is because primaryGroupToken is constructed and
can't be queried directly. Still they had a pretty bad mechanism of doing it
because it doesn't scale generically. Instead they should have taken the
primaryGroupID and constructed the full Group SID with it and resolved that to a
domain. We are talking ms for a slow implementation of this.

I actually can't think of anything off the top of my head that should take a
minute if you are retrieving info about a single user.

Oh, if the user is logging on, the group info (for security groups which
obviously covers primary group) for the local domain is already all present on
the local machine and doesn't require any LDAP lookups. You simply have to look
at the user's token. Check out whoami /groups or if you don't have that
available go download my sectok utility.

Now all of that being said, I would be leery of anyone using the primaryGroupId
for anything. That generally is a horrible idea in Windows. There is a POS
application out there called ClearCase that likes to do this because whomever
was lazy when they ported it from UNIX. The Windows security model is much more
robust than that and easily allows lots of different group accesses and scopes
and locking someone down to just primary group is a good way to not get
implemented in any companies I consult for. Anyone that required use of primary
groups is probably screwing all sorts of Windows things up.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net

---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

gordonah wrote: