Re: Indexing attributes for containerized searches

Tech-Archive recommends: Fix windows errors by optimizing your registry

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:
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:

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:
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
.