I don't know if I like this as a generic solution Gil. o Most people have issue enumerating/understanding ACLs to start with. o You can't really query it. o Only viable from Windows. o Resolving SIDS to names for all of the ACEs would be on the slow side. o No auto cleanup if someone were deleted. o If you have an app with a lot of users (thousands or tens of thousands) I would expect you could run into the ceiling on the size of the SD which means you start using groups which is the current solution anyway, why not use it directly? That is off the top of my head.
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: Tuesday, October 19, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] groups vs attributes A very clean way to manage access rights for apps is to create new extended access rights objects in the Extended-Rights container that represent the different categories of access to your app, then create an object that represents the application in the CN=Services container, and create object-ACEs in the SD for the application object for each security principal that is allowed to access the application. Its clean, flexible, extensible, provides any level of granularity you might want, and you can use the Windows access control APIs to determine access level. We've used this strategy in a couple of our applications and are very happy with it. That's what the extended rights objects are there for anyway :) -gil Gil Kirkpatrick CTO, NetPro Got DEC? _____ From: [EMAIL PROTECTED] on behalf of Tony Murray Sent: Tue 10/19/2004 7:55 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] groups vs attributes 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/
<<attachment: winmail.dat>>
