I guess they've indexed their attribute? Either way, it shouldn't be any faster than querying group membership.
The only danger I see with the custom attribute approach is that it could be the thin end of the wedge. The more applications that use this approach the more custom attributes you will have. You could end up with a messy schema. Unless of course you use a single attribute and make it multi-valued. But then you're still no different to using group membership. If the developers think the group membership lookup is slow they could include a cache mechanism in the application and set a cache refresh interval for the queries against AD. Tony ---------- Original Message ---------------------------------- From: "Creamer, Mark" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Tue, 19 Oct 2004 10:44:36 -0400 Sorry, I didn't word that very well. You're right, Lou, that is what they do. I guess their main point is that querying an attribute that we create for the purpose seems faster than when they check the group membership. I don't know how valid that is... <mc> _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lou Vega Sent: Tuesday, October 19, 2004 10:28 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] groups vs attributes I may be missing something in the reading, but why not just query AD based on the username and determine if that user object is a member of the group in question instead of returning a list of all users for a given group? Another possibility (one you may well have thought of already but didn't mention) is that you can filter your search [searcher.Filter = "(&(objectCategory=user)(sAMAccountName=" & Trim(userName) & "))"] r/ Lou ________________________________________________________________ Sent via the WebMail system at mail.activedir.org List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
