"webrod" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
Willy Denoyette [MVP] a écrit :
[...]
> Checking the validity of a password must be done by "authenticating", when authenticating
> an
> ADAM user you'll have perform an LDAP Bind operation, specifying the adam user's
> credentials.
Actually, I thought you were saying the opposite in this post:
http://groups.google.fr/group/micros...89cddc96545689
I thought you were saying it's ridiculous to connect to a LDAP if it's
not to do a quey.
Like if you connect to a oracle database just to authenticate and not
to do a SQL query...
Could you clarify your opinion?
I think I misunderstand something.
Rod
You asked, "how can I check a user/password in LDAP", right? But, in fact your question
was - "how can I retrieve the password from the LDAP directory?"
And I answered - "you can't retrieve a user's password from a directory", one way to check
the password of user is by "authenticating", and because you asked about LDAP, I said you
could use LDAP "bind" as an *Network Authentication* mechanism.
However, as I said in another thread, LDAP is not an *authentication* protocol nor is "LDAP
server" an authentication service. The LDAP bind operation is meant to "validate" the LDAP
clients credentials in order, for the server, to be able to perform directory
"authorization" checks. The bind operation establishes an "authenticated" network session
between a client and a server (here LDAP), just like you establish an authenticated session
between a SQL client and a SQL server, or an authenticated session between a "Windows"
client and a "File server" service (Windows or Samba, you name it). But the fact that you
can use a service like LDAP or SQL or a File server to authenticate a client, doesn't turn a
service into an *authentication service*.
So, if all you need is to "authenticate", you should look for better alternatives, "Kerberos
authentication service" for instance is such an alternative, use it if available, it's
specially designed to authenticate and it is secure.
Note that I'm talking about *Network Authentication* here, where a client needs to "prove"
his/her identity to a server!.
Now, everything depends on what exactly is meant with "users".
Part of Windows Active Directory, is an LDAP service/repository, which stores the "Windows
domain accounts" properties (among other stuff), one of the properties are the accounts
credentials. However, that doesn't mean that Windows will use LDAP to "authenticate",
actually IT DOESN'T! , Windows, by default, uses Kerberos to authenticate Windows users, and
it doesn't need LDAP at all for this. The real "authentication service" is the AS and the
KDC for "Kerberos" and SAM for "NTLM", both part of the LSA (lsass.exe service). The LSA has
direct access to the "credential" store, that is, the directory store for domain accounts,
the SAM DB (the registry) for local accounts (machine account, service accounts etc). The
LSA runs in the TCB and is the only service that has access to the credentials in Windows.
Note that I'm talking about "Network" authentication, Windows Logon service (interactive
logon) uses the same authentication mechanism (NTLM and Kerberos), but the purpose is
somewhat different.
So, if you only need to "validate" a Windows account's credentials, your best bet is
Kerberos (or NTLM) authentication, use LDAP (through System.DirectcoryServices.Protocols
(SDS.P) or C LDAP API's) if you have to, but don't use AD binding through
System.DirectcoryServices (SDS) or ADSI only for the purpose of authentication.
The Kerberos, NTLM and SSL auth. protocol API's are exposed through the SSPI Security API's
in Windows. The SSPI API's are wrapped (partly in V2) by the System.Net.NetworkCredential ,
the System.Net.NegotiateStream and the System.Net.SslStream classes in FCL V2 and V3. Note
that you can also use the LogonUser API to validate Windows account credentials, but this
API is highly constrained by the security system and it's purpose is not really
authentication, it's meant to get an access token.
WCF in V3 uses these classes to implement all sort of network authentication scheme's for
internet/intranet based distributed applications.
Now, back to ADAM (now called AD LDS), LDS is basically an private application based LDAP
server, it doesn't store Windows identities, it stores (among other) users, persons and
inetOrgPers object types, their credentials (secrets) are stored in the AD LDS store, but
they aren't accessed by the LSA. So, they can't be used as Windows accounts (local nor
domain), note however, that AD LDS can be integrated with the enterprise AD, in which case
the user accounts can be stored in both, such they can be used as Windows accounts, but
let's forget about this for now and consider AD LDS as a private DS.
In order to "validate" a *user* (user, person, ....), you have to "bind" to the LDAP server
(ADAM instance), specifying it's "userPrincipalName" (upn) and "userPassword", note the upn,
not the sAMaccountname! But here again, the act of "binding" establishes a network session
with the LDAP server (the AD LDS instance), for the purpose of "authorization". Now, if your
only purpose is "authenticating", you are done after the bind, but this is not exactly what
AD LDS was designed for......
While there is nothing wrong with such an "authentication" scheme, you have to keep in mind
that:
- the bind uses clear text authentication (unless you are using SSL), that means it is NOT
SECURE when used over a network.
- you better use LDAP (SDS.P) instead of ADSI (SDS)for performance reasons.
- you can't retrieve the "userPassword" property of the "user" from the LDAP store, you can
only set or modify this property.
What's applicable to "AD LDS" is also applicable to other LDAP implementations, here it
depends on how well they integrate with Windows or the other OS security provider
infrastructure, but basically you can use it for "simple bind" authentication, but remember
it's insecure over the network, unless you opt for SSL and the certificates mess.
Willy.
Similar Threads
