RE: [ActiveDir] groups vs attributes

[Mulnick, Al]

Title: Re: [ActiveDir] groups vs attributes

Anytime you use LDAP binding you create two problems: 1) Active Directory was designed to let users be moved around when needed.  It happens as a matter of course and will often break LDAP applications that rely on LDAP bind.  When the RDN changes, so does the user name right? 2) You are downgrading the security, because you're often only checking for the existence of an value vs. a challenge/response and strong password etc.    Applications that do this are often web or database based.  For example, several "security" applications allow access based on what your DN value is (that's the identity portion of the transaction) and your group membership (that's the authorization portion of the transaction) but they often assume that you've authenticated.  Typically, an authentication process includes identification, authentication, and authorization to resources.  That's what AD provides for you and you are no longer using that with LDAP bind. Not that you couldn't, but it's often left out.  Older version of Siteminder do it this way for example if you choose to use a different LDAP store.    Mark, I certainly didn't mean to imply that attribute vs. group is any more or less secure.  It's the same.  The speed difference would be due to the way they write their code and because if you have a multi-valued attribute such as memberOf, you have to iterate through the array until you find your matched group or fail.  Using a custom, indexed attribute could be faster (and is certainly sexier as Rick mentions) because you can have a single value in there.  No iteration required.    Personally, I've found that using arrays in memory for a user is still very fast.  In fact, I wasn't able to discern a difference when using proper search filter criteria.  It's a few lines of code to check and only a few ticks of the clock cycle extra along with a slightly more on the wire.  Not a big enough deal to warrant the confusion and change in administrative practice it would inevitably produce, nor as Rick mentioned, the problems of accommodating applications that come and go on a different cycle than your AD infrastructure.   If they want to post the filters, I think we could easily help them optimize if that's all that's needed. And don't get me wrong, I think you can see from all of this that it can be done either way that works for you.  That's the flexibility and power of AD.  The questions to answer are why? how long?  and what do I really gain at what cost?   I wouldn't let them unless they had a REALLY good reason. They are a consumer of the service, not the other way around :)   Al From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Creamer, Mark Sent: Tuesday, October 19, 2004 10:35 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] groups vs attributes I'm not following Rick and Al on the security factor. Why would using the attribute method be less secure, assuming we control who can populate the attribute, the same as we control who can add members to a group? Maybe I'm missing the point though...thanks for your thoughts guys   <mc> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Boza Sent: Tuesday, October 19, 2004 10:05 AM To: ActiveDir List Subject: Re: [ActiveDir] groups vs attributes   >From a Dev standpoint using attributes and requiring schema extensions is undeniably sexier.  And you would be extending the schema eventually - possibly for every application that you deploy.  There are only so many attributes to use for this sort of thing before you start wanting your own specific one.     >From an administrative standpoint, I'm with Al - only I'll go a level further - managing that would become a nightmare, and every application that gets rolled out would make things even more convoluted.  There are lots of good reasons to populate attributes with different values, but circumventing AD security probably isn't one of them!  (The term 'Recipe for Disaster' comes to mind) On 10/19/04 9:36 AM, "Mulnick, Al" <[EMAIL PROTECTED]> wrote: Personally, I think they should have a look at why their queries take longer than they want.  Likely they are checking the memberof attribute to find out what the group membership is, right? I think they could use an attribute, but I think that's not guaranteed to be faster either.  I think they also may want to consider what the administrative and troubleshooting overhead is if they use an attribute vs. a group membership (why aren't they using Active Directory security again?). That's the way I think though :) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Creamer, Mark Sent: Tuesday, October 19, 2004 9:21 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] groups vs attributes As our developers (as well as our 3rd party vendors) continue to create apps that leverage AD, the question comes up frequently - which is a better solution...to search AD for a group membership, or for the value of a given attribute, when validating a user's access to a custom application? Our "standard" has been to use universal groups for this sort of thing, that is, UserA can access the application, if he is a member of the appropriate universal group. However, our developers have discovered in their ad hoc queries that returning a list of users that have a given value assigned to a custom attribute is much faster that returning a list of users that are members of a universal group. So they are asking, shouldn't we be adding a custom attribute when an application requires a validation that a user can access the application, rather than using a group membership? Any notes from the field would be much appreciated! Mark Creamer Systems Engineer Cintas Corporation The Service Professionals Sent using the Microsoft Entourage 2004 for Mac Test Drive.