Re: check a user password

"webrod" <rodolphe.aoustin@xxxxxxxxx> wrote in message news:1167205236.199502.263210@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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/microsoft.public.dotnet.languages.csharp/browse_thread/thread/329b6f018be7d501/9a89cddc96545689

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.









.

Relevant Pages

  • Re: NTLM authentication
    ... Well, it depends on so many things, like the OS versions, Domain versions client types (windows non windows) and the final purpose of the authentication act. ... The same remark here as above, some network manager will not allow you to authenticate using LDAP against a corporate Directory. ... more processing overhead ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: check a user password
    ... ADAM user you'll have perform an LDAP Bind operation, ... However, as I said in another thread, LDAP is not an *authentication* protocol nor is "LDAP ... client and a "File server" service (Windows or Samba, ... domain accounts" properties, one of the properties are the accounts ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: Application to Application authentication models....
    ... Application to Application authentication models.... ... > obtain sensitive data such as connection credentials to database systems? ... The very first thing I would focus on is ensuring that the credentials your ... including pulling credentials off of a separate LDAP ...
    (SecProg)
  • Re: Utilities for simple tasks
    ... Hi Charles, ... usable for anyone who can install programs on Windows. ... authentication modules) and LDAP. ... bit of effort to install a complete authentication framework based on ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Adding Solaris 10 machine to Active Directory Authentication
    ... This allows the Unix systems to access and share out windows style ... Unix style NFS shares. ... Authentication: Do this using Kerberos. ... Do this using LDAP but protect the LDAP bind and data ...
    (microsoft.public.windows.server.active_directory)