RE: [ActiveDir] groups vs attributes

[Fugleberg, David A]

Title: Message

Yes, a sticky issue indeed.  Many of these 'solutions' are only workable if you have some processes and standards in place beforehand, and you're reasonably sure they are followed (i.e., they're automated).  The 'service account' approach to allow the 'consumer' system to search for the full DN seems like the lesser of two evils, imho.  Given that many of these apps don't run on Windows boxes, the LocalSystem approach isn't always feasible.   Yes, the reason for all of this is usually because the vendor can't assume which flavor of directory the customer has, so they try to use fairly generic mechanisms rather than dive into full AD integration.  Seems to me that if you use extended rights objects as Gil suggests, apps that run on non-Windows boxes would still need a 'service account' or some such in order to read and use them.  Maybe I'm missing something here - I'm thinking primarily of stuff like web applications on Unix servers.   Dave  -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Tuesday, October 19, 2004 12:48 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] groups vs attributes Right.  Some do. But once they go that route, you almost have to question why they just didn't integrate with the Active Directory authentication mechanisms in the first place.  I would guess it has more to do with trying to be interoperable with multiple directory stores, but that's just a guess.   Common simple LDAP bind uses a DN such as cn=amulnick,cn=Admins,dc=domain,dc=com to 'uniquely' identify the user.  That's an RDN in many environments though, so you have no guarantee that it's unique in the ecosystem of directories that you have. Instead, you have to rely on process and procedure being defined, followed and enforced.  That can be a tall order in many environments.   Since the bind operation must be the first operation request of the protocol, you would have either have the RDN of the user + authentication mechanism (kerb or plain-text password) else allow anonymous binds so you could find the user and return the return the current DN.  You *could* provide the application a user account to use for authentication to allow the search, but that's going even further out of the way and acts like a service account which we try to get away from whenever possible. You could also allow it to run under a localsystem account and trust the workstation to allow for the search, but that doesn't allow you to go cross platform to other directory stores.    Using SSL is fine, but you still would have to allow anonymous or come up with some way to allow the user to be uniquely identified such as allowing anonymous binds to AD.    It's a sticky issue to be sure.     Al From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fugleberg, David A Sent: Tuesday, October 19, 2004 1:30 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] groups vs attributes Some LDAP 'consumers' get around these problems by first searching the directory for the user to get their current full DN, and then doing a bind with that.  Of course, that means that you need to search on something that you know to be globally unique, like samAccountName.  Alternatively, you could bind using the UPN.   As someone else pointed out, this ought to be done over SSL if you're using simple binds.   Good food for thought in Gil's post...I'll have to play with that.   Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Tuesday, October 19, 2004 11:14 AM To: '[EMAIL PROTECTED]' Subject: 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.