By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,664 Members | 1,986 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,664 IT Pros & Developers. It's quick & easy.

check a user password

P: n/a
Hi all,

how can I check a user/password in a LDAP ?

I don't want to connect with this user, I would like to connect to LDAP
with a ADMIN_LOG/ADMIN_PWD, then do a query to find the user and check
the password.

The thing is I can't access the password attribute to compare with the
user's password provided.

So do you have any idea?

Thanks

Rod

Dec 22 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
"webrod" <ro**************@gmail.comwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...
how can I check a user/password in a LDAP ?

I don't want to connect with this user, I would like to connect to LDAP
with a ADMIN_LOG/ADMIN_PWD, then do a query to find the user and check
the password.

The thing is I can't access the password attribute to compare with the
user's password provided.
That's right! Otherwise, you'd be able to know everybody's password... :-)
So do you have any idea?
You don't actually need to connect with a user to validate their
credentials - you only have to simulate a logon:

using System.DirectoryServices;

public static bool Logon(string pstrDomain, string pstrUser, string
pstrPassword)
{
try
{
using (DirectoryEntry objADEntry = new DirectoryEntry("LDAP://" +
pstrDomain, pstrUser, pstrPassword))
{
return !objADEntry.NativeObject.Equals(null);
}
}
catch (System.Runtime.InteropServices.COMException)
{
return false;
}
catch (Exception)
{
throw;
}
}
Dec 22 '06 #2

P: n/a
"webrod" <ro**************@gmail.comwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...
Hi all,

how can I check a user/password in a LDAP ?
Which LDAP? AD or other?

I don't want to connect with this user, I would like to connect to LDAP
with a ADMIN_LOG/ADMIN_PWD, then do a query to find the user and check
the password.
See Q1 above.
The thing is I can't access the password attribute to compare with the
user's password provided.

So do you have any idea?
You can't retrieve the password of a windows account from the AD.

Willy.

Dec 22 '06 #3

P: n/a
The thing is I can't access the password attribute to compare with the
user's password provided.

That's right! Otherwise, you'd be able to know everybody's password... :-)
Actually, I thought I could get the encoded password (MD5) not the real
full text password.
So do you have any idea?

You don't actually need to connect with a user to validate their
credentials - you only have to simulate a logon:
[...]

Thanks for this code! I will test it on wednesday.

Thanks you again.

Rod

Dec 23 '06 #4

P: n/a
Willy Denoyette [MVP] a écrit :
"webrod" <ro**************@gmail.comwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...
Hi all,

how can I check a user/password in a LDAP ?

Which LDAP? AD or other?
Actually, any.
My customer can have AD, ADAM or a Novell AD (don't know yet which
one).
I was doing some test with ADAM and thought I could get the encoded
password (MD5) to compare with the password provided by the user.
You can't retrieve the password of a windows account from the AD.
even the encoded one??
Willy.
thanks you willy

Rod

Dec 23 '06 #5

P: n/a
"webrod" <ro**************@gmail.comwrote in message
news:11**********************@79g2000cws.googlegro ups.com...
Willy Denoyette [MVP] a écrit :
"webrod" <ro**************@gmail.comwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...
Hi all,

how can I check a user/password in a LDAP ?

Which LDAP? AD or other?
Actually, any.
My customer can have AD, ADAM or a Novell AD (don't know yet which
one).
I was doing some test with ADAM and thought I could get the encoded
password (MD5) to compare with the password provided by the user.
You can't retrieve the password of a windows account from the AD.
even the encoded one??

No, while you can set or modify the "userpassword" property, you can't retrive this property
from AD or ADAM (now called AD LDS), don't know for sure about NDS but I would be surprised
if you could.
Try for yourself using adsiedit, bind to NDS, AD or ADAM and try to get the "userpassword"
property, you'll see that this is always empty.
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.
Note, that "ADAM User" identities are NOT "Windows User" identities, binding against ADAM
using an ADAM user's credentials can only be done using basic authentication.

Willy.

Dec 25 '06 #6

P: n/a

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 adamuser'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

Dec 27 '06 #7

P: n/a
"webrod" <ro**************@gmail.comwrote in message
news:11**********************@i12g2000cwa.googlegr oups.com...

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.



Dec 27 '06 #8

P: n/a
webrod wrote:
The thing is I can't access the password attribute to compare with the
user's password provided.

That's right! Otherwise, you'd be able to know everybody's password...
:-)

Actually, I thought I could get the encoded password (MD5) not the real
full text password.
So do you have any idea?

You don't actually need to connect with a user to validate their
credentials - you only have to simulate a logon:
[...]

Thanks for this code! I will test it on wednesday.

Thanks you again.

Rod
Hi Rod,
Actually, I thought I could get the encoded password (MD5) not the real
full text password.
I severely doubt it. And I severely doubt it's MD5 ;-)

--
Hope this helps,
Tom Spink

Google first, ask later.
Dec 28 '06 #9

P: n/a
Willy,

thanks you very much for your complete answer and for your time.
I really appreciate.

Rod

Willy Denoyette [MVP] a écrit :
"webrod" <ro**************@gmail.comwrote in message
news:11**********************@i12g2000cwa.googlegr oups.com...

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 factyour 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 clientneeds 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 authenticateWindows 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 fordomain 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 Windowsaccounts, 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.
Jan 4 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.