I was perusing some of the newsgroups today and ran across such a (IMO) well written response by Joe Kaplan (JoeK as I normally refer to him) to a question asked about LDAP authentication that I wanted to share it.
——– Original Message ——–
Subject: Re: Authenticate against AD + other DS
Date: Fri, 25 May 2007 17:56:15 -0500
From: Joe Kaplan <joseph.e.kaplan@removethis.accenture.com>
Newsgroups: microsoft.public.active.directory.interfaces
References: <1180116673.063188.255780@g4g2000hsf.googlegroups.com>The only common authentication method supported by all of these LDAP
directories is the LDAP simple bind (hopefully also protected by SSL).
That is the only thing that is specified in the LDAP V3 spec and is thus the
only thing they all have in common.Any of those directories may support other LDAP authentication mechanisms
such as different SASL methods that use Kerberos, or Digest or whatever and
may also support client certificate authentication. However, that will
vary by directory. AD supports a SASL mechanism called GSS-SPNEGO that allows
“Windows negotiate auth”, which is the normal Windows authentication
protocol that selects between Kerberos and NTLM. When you use
“AuthenticationTypes.Secure” in S.DS, you are using GSS-SPNEGO which
translates to Kerberos or NTLM. AD also support SASL Digest auth and
client cert authentication.To authenticate against AD in Windows, you don’t need to use LDAP. You can
just talk to the negotiate protocol directly using SSPI as you said or call
the LogonUser API, which eventually does the same thing under the hood.I recommend against using S.DS for LDAP authentication as it scales very
poorly. The design of ADSI works directly against scalability for this use
case as ADSI opens up a new connection for new set of credentials it sees
and you can basically just run out of sockets if you try to do too many in
too short a time. If you must use LDAP auth in .NET, use S.DS.Protocols so
that you can control the connections directly. This is what the Active
Directory membership provider in ASP.NET 2.0 does.The big problem with LDAP simple bind is that it is not secure as it uses
plaintext credentials. In order for it be secure on the wire, you must
secure the transport itself, usually with SSL. However, not all
directories have SSL support. AD supports SSL but doesn’t come configured
with it by default.The other big problem with LDAP simple bind is that the LDAP spec only says
that the user name for the authentication must support the full
distinguished name. Other names may be supported, but the DN is the only
common denominator. However, most users don’t know their full DN in the
directory or wouldn’t want to type that, so you may need to accept a
shorter user name, search for the object in the directory to get the DN and then
execute a bind with the DN you found. However, that requires a service
account to do the search, which creates a configuration issue, as you must
store those credentials securely. Some directories like AD allow you to do
a simple bind with other user name formats and might allow you to skip the
searching step, but you can’t necessarily count on that.So, this problem is hard to solve in general. You might consider creating
some sort of a provider model that allows you to plug in different models
that work slightly different for different directories and give you
control.
Another way to look at it is to turn the problem on its head. If you
designed your application for federated logon, where you accept some
sort of signed SAML token from a trusted partner, then you can push the
authentication of the end users off on the partner. Problem solved. 🙂Best of luck!
Joe K.
—
Joe Kaplan-MS MVP Directory Services Programming
Co-author of “The .NET Developer’s Guide to Directory Services Programming”
http://www.directoryprogramming.net
—
<weinjare@msu.edu> wrote in message
news:1180116673.063188.255780@g4g2000hsf.googlegroups.com…
> Hi,
>
> I am working on some C# to authenticate against an AD, but also among
> other types of directory services, namely openLDAP, Novell eDirectory,
> and SunONE DS, and I am curious to hear if there are already solutions
> published for this.
>
> I am currently using S.DS to authenticate, and switching the
> AuthenticationTypes depending on the type of DS I am authenticating
> against.
>
> I have heard some mentions of using SSPI, but I doubt that there is
> support for authenticating against non-Microsoft directories with
> SSPI.
>
> Does anybody know of best case solutions for authenticating against
> multiple directory servers with different setups (such as Kerberos,
> SSL/TLS)?
>
