Freigeben über

On ADAM user authentication….

  • Artikel

I just noticed that Doug Lawty has a blog, and that he recently posted on ADAM as well. I think Doug is spot on with some of his conclusions, I also feel the need to clarify the statements made along the way a bit. :)

 

> Kerberos (Remember, ldap binds send your password in the clear.)

 

First, the statement assumes that you are using an ADAM user. It is the ADAM user which requires that you authenticate in the LDAP bind with a bind that may yield password in the clear. If you are binding with a Windows user (using secure bind), you can authenticate in any way you normally would.

 

Second, even if you are using ADAM users, you still can bind without credentials being sent in the clear. You can use LDAPS or you can use LDAP_OPT_ENCRYPT to encrypt the bind. And don’t forget our SASL friends….

 

Third, if you elect to use bind proxy, you are sending your AD cred’s in a simple bind (must be simple, no SASL binds allowed for this), but you still can use LDAPS or LDAP_OPT_ENCRYPT. In fact, by default, we require this so as to try and prevent people from sending their normal user password in the clear over the wire.

 

> Windows integrated authentication with IIS (including digest).

Again, we’re assuming that it is an ADAM user. This is true for ADAM users, but if you have normal Windows security principals and are just using ADAM for application data storage this is a non-issue.

 

> So, if you were building an authentication service, why wouldn't you want to use

> the option that is the most full-featured and best supported?

Despite everything I said above <g>, I totally agree here. If given the choice, my users are always located in AD. But ADAM also lets you bridge the authentication gap with bind proxy, so when looking at legacy app’s which require a simple bind, we let you have your cake and eat it too.

Consider this usage scenario…. Assume you have an application which must bind use LDAP simple bind, but the users being used for it are located in many different AD domains which are spread across multiple forests. Simple bind doesn’t play well across forest trusts, so it would be nontrivial to make this work without a massive migration. Using ADAM, one can create proxy users for each of those users and then use simple bind to the ADAM instance such that they can expose their desperate users in a single environment where simple bind can be used. This is very slick IMHO.

At the end of the day, I agree with Doug's conclusion….we should not start using ADAM as the authoritative user store in place of AD as, in the long run, you’ll probably thirst for the OS and application integration that AD brings to the table. But this does not mean that ADAM brings nothing to the table in the area of user auth. Extranet scenarios and legacy app’s can be benefited by the ADAM way of life. And for some people, ADAM user authentication might be well suited, especially if it is for users in a custom application scenario (perhaps these users work for other organizations and they just use a subset of applications….who knows :)).

Comments

  • Anonymous
    October 19, 2004
    My question on ADAM is this:

    What about environments where ADAM gets AD users and needs to assign additional AD schema items for them.

    I'll give you a concrete example. Say LCS used ADAM and not AD, and the LCS extensions to the user schema where kept hidden behind the application firewall that is ADAM.

    How would ADAM assign attributes to a non-adam user?
  • Anonymous
    October 19, 2004
    Oh never mind, I found it here:

    "Proxy objects (and proxy object classes) do not exist by default in ADAM. However, you can import a proxy object class into the ADAM schema during ADAM installation. A proxy object can be created from any object class that contains the msDS-bindProxy auxiliary class. The msds-BindProxy class possesses a single “must contain” attribute, ObjectSid, which holds the SID of the associated Active Directory security principal. You can only set the value of ObjectSid at object creation time. After a proxy object is created, the value of its ObjectSid attribute cannot be modified. You can set the ObjectSid of a proxy object to the SID of any local Windows user or to any user who is a member of a domain or forest that is trusted by the computer on which ADAM is running."

    It would be very nice if MSFT was more clear in describing how to have objects in an AD forest be cross-referenced in an ADAM directory structure. The documentation as it stands now is more than a little unclear.
  • Anonymous
    October 25, 2004
    <a href=http://www.dirty-zone.com/hard13/index7571.html>free adult</a>