On ADAM user authentication….

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 :)).