windows authentication & openldap: explanation.

[brian jones]

i've seen posts in the archives mentioning the inability of windows clients
(2000, nt) to authenticate domain logins against an openldap directory, but
i haven't been able to find any explanations of why. can't windows clients
use ldap for their authentication? i thought they used ldap to authenticate
against a dc running active directory, is that incorrect? or is this just
another case of non-standard implementations? anyway, if someone could give
me a clue or at least point me in the right direction i'd really appreciate
it. we're probably going to use a samba server as a pdc and then have that
check passwords against an ldap server instead of a local password file, but
i'm really curious why windows and openldap don't work in this way. thanks
in advance,
-brian



_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

[Kervin L. Pierre]

The protocol windows uses to authenticate domain users is undocumented.
It uses LDAP and Kerberos, both relatively standard implementations,
but there is a lot more to the process of authenticating against the
Windows domain than just these parts. The Samba list would be a good
place to get info on this, I'd guess.

Windows can authenticate against standard LDAP server if you use a GINA
module, eg. http://pgina.cs.plu.edu/ and I think Novell has a GINA
product as well I think. GINA is something like Window's PAM I think. It
replaces at least part of the authentication subsystem.

Another angle is synchronization of the windows accounts and passwords
with that in the LDAP directory eg. Novell's Password Sync, and
iPlanet's NT Sync, and also Psynch http://psynch.com . Again the
windows password synchronization api is what makes these products possible.

Finally, the Windows domain controller could be replaced entirely.
That's what SAMBA does. Win2k native support is not completed yet, I'd
check the samba list before running on a production environment. WinNT
and Win2k mix mode should work fine.

--Kervin

Post by brian jones
i've seen posts in the archives mentioning the inability of windows
clients (2000, nt) to authenticate domain logins against an openldap
directory, but i haven't been able to find any explanations of why.
can't windows clients use ldap for their authentication? i thought they
used ldap to authenticate against a dc running active directory, is that
incorrect? or is this just another case of non-standard
implementations? anyway, if someone could give me a clue or at least
point me in the right direction i'd really appreciate it. we're
probably going to use a samba server as a pdc and then have that check
passwords against an ldap server instead of a local password file, but
i'm really curious why windows and openldap don't work in this way.
thanks in advance,
-brian
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

[David Wright]

How Unix authentication works:
1. Server (or /etc/passwd) stores a hashed password, e.g. "{ROT-1}tfdsfu"
2. Client hands server the cleartext of the user input, e.g. "secret"
3. Server hashes the client user input and compares it with the stored
hased password. If they match, it returns TRUE.

How Windows authentication works:
1. Server stores cleartext of the password, e.g. "secret".
2. Server sends client a challenge, e.g. "abcdef".
3. Client hashes the client input and the challenge together, e.g.
"tgfvjz" and sends this response to the server.
4. Server hases the client input and the challenge together and compares
to the client's response. If they match, it retuns TRUE.

The Windows authentication has the advantage that the cleartext password
is never sent over the wire. It the the disadvantage that the server must
store the cleartext password.

OpenLDAP is designed to store hashed passwords, as is the Unix tradition.
Since Windows authentication would require storing cleartext passwords,
OpenLDAP doesn't implement the challenge/response model of Windows
authentication.

You can get around this limitation. You can store a hashed password in the
userPassword attribute and have your Unix clients authenticate off it via
LDAP. You can also store a cleartext password in the smbPassword attribute
and tell Samba to get passwords from LDAP. Samba implements the Windows
challenge/response model and your Windows clients can authenticate off it.

You then need to do some scheming to make sure that the userPassword and
smbPassword attributes stay in sync.

That answer you question?

[Christoph Neumann]

Brian (Wright), what you mentioned is correct for the old-style windows
authentication with the old NT 4 and below systems. (Actually, Win95 and
NT 3 systems did everything in clear text.) Modern windows clients (2000,
XP) allow for much better authentication mechanisms such as Kerberos.
OpenLDAP supports Kerberos authentication.

So, if you have to support WinME and Win9x clients, yes, you need Samba to
provide the old-style of Windows authentication. However, the question
still stands: Why can't one use OpenLDAP as a replacement for Active
Directory using a modern authentication scheme such as Kerberos? I would
love to hear the answer to that question too.

In addition to the authentication problem, there is the authorization
problem. Active Directory is used for authorization of such things as
user and group policies. Microsoft clients lookup authorization related
fields in Active Directory when the user logs into the domain. Some of
these fields have an undocumented format (such as ntSecurityDescriptor).
I believe the authorization piece of Active Directory makes Active
Directory more difficult to replace then the authentication piece.

- Christoph

Post by David Wright
1. Server (or /etc/passwd) stores a hashed password, e.g. "{ROT-1}tfdsfu"
2. Client hands server the cleartext of the user input, e.g. "secret"
3. Server hashes the client user input and compares it with the stored
hased password. If they match, it returns TRUE.
1. Server stores cleartext of the password, e.g. "secret".
2. Server sends client a challenge, e.g. "abcdef".
3. Client hashes the client input and the challenge together, e.g.
"tgfvjz" and sends this response to the server.
4. Server hases the client input and the challenge together and compares
to the client's response. If they match, it retuns TRUE.
The Windows authentication has the advantage that the cleartext password
is never sent over the wire. It the the disadvantage that the server must
store the cleartext password.
OpenLDAP is designed to store hashed passwords, as is the Unix tradition.
Since Windows authentication would require storing cleartext passwords,
OpenLDAP doesn't implement the challenge/response model of Windows
authentication.
You can get around this limitation. You can store a hashed password in the
userPassword attribute and have your Unix clients authenticate off it via
LDAP. You can also store a cleartext password in the smbPassword attribute
and tell Samba to get passwords from LDAP. Samba implements the Windows
challenge/response model and your Windows clients can authenticate off it.
You then need to do some scheming to make sure that the userPassword and
smbPassword attributes stay in sync.
That answer you question?

[Mark H. Wood]

On Fri, 26 Jul 2002, Christoph Neumann wrote:
[snip]

Post by Christoph Neumann
So, if you have to support WinME and Win9x clients, yes, you need Samba to
provide the old-style of Windows authentication. However, the question
still stands: Why can't one use OpenLDAP as a replacement for Active
Directory using a modern authentication scheme such as Kerberos? I would
love to hear the answer to that question too.

Short answer: because OpenLDAP doesn't provide all of the services that
ADS clients require. Neither does any other LDAP server. You need a big
wad of services (directory, authentication (Kerberos), dDNS, etc.) all
tangled together like spaghetti ("tightly integrated" in MS-speak) to
support an ADS client.

It looks possible to replace ADS with OpenLDAP + Kerberos + very recent
BIND + lots of private Microsoft schema definitions for which there is, so
far as I know, no description which is both public and machine-readable.
(And the human-readable spec. appears to be incorrect in some areas.)

Post by Christoph Neumann
In addition to the authentication problem, there is the authorization
problem. Active Directory is used for authorization of such things as
user and group policies. Microsoft clients lookup authorization related
fields in Active Directory when the user logs into the domain. Some of
these fields have an undocumented format (such as ntSecurityDescriptor).
I believe the authorization piece of Active Directory makes Active
Directory more difficult to replace then the authentication piece.

Huh? SDs are well documented in the Platform SDK. ADS' central mystery,
until recently, was the MS-defined PAC TDATA incorporated into principal
records in the authentication piece, to glue the NT security model onto
Kerberos. The format is now published. (_Utilizing the Windows 2000
Authorization Data in Kerberos Tickets for Access Control to Resources_)

It just takes a loooong time to wrap up all the little pieces and make
them play together nicely. Someone will do it eventually.

[Kervin L. Pierre]

Post by Mark H. Wood
It just takes a loooong time to wrap up all the little pieces and make
them play together nicely. Someone will do it eventually.

This is what Samba 3.0 is going for. I heard CVS is already joining the
Win2k network as a domain controller.

--Kervin

[brian jones]

yes that does answer my question, thanks alot. and thanks to kevin for the
links to pgina and psynch.
-brian

Subject: Re: windows authentication & openldap: explanation.
Date: Fri, 26 Jul 2002 14:51:47 -0700 (PDT)
1. Server (or /etc/passwd) stores a hashed password, e.g. "{ROT-1}tfdsfu"
2. Client hands server the cleartext of the user input, e.g. "secret"
3. Server hashes the client user input and compares it with the stored
hased password. If they match, it returns TRUE.
1. Server stores cleartext of the password, e.g. "secret".
2. Server sends client a challenge, e.g. "abcdef".
3. Client hashes the client input and the challenge together, e.g.
"tgfvjz" and sends this response to the server.
4. Server hases the client input and the challenge together and compares
to the client's response. If they match, it retuns TRUE.
The Windows authentication has the advantage that the cleartext password
is never sent over the wire. It the the disadvantage that the server must
store the cleartext password.
OpenLDAP is designed to store hashed passwords, as is the Unix tradition.
Since Windows authentication would require storing cleartext passwords,
OpenLDAP doesn't implement the challenge/response model of Windows
authentication.
You can get around this limitation. You can store a hashed password in the
userPassword attribute and have your Unix clients authenticate off it via
LDAP. You can also store a cleartext password in the smbPassword attribute
and tell Samba to get passwords from LDAP. Samba implements the Windows
challenge/response model and your Windows clients can authenticate off it.
You then need to do some scheming to make sure that the userPassword and
smbPassword attributes stay in sync.
That answer you question?

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

[Jim C]

This thread is riight up the alley of my most recent headache. ;-)
First off let me warn you guys that I am a student and that I am working
on a accedemic project.
Consequently, purchased solutions are out.

In order to authenticate a Windows based client I am trying to use the
pGINA module with the LDAP plugin.
I've not be able to figure out the configureattion despite haveing a
Unix ldap.conf that works to use as a base.
I can email this to anyone who wants to help.

Any tips I can get on this would be most helpful. Esepcailly any
windows based trouble shooting tricks.
The windows based cleint is a Win2K box. I am basically trying to figure
out the differenece between what the client is sending
and what the server expects.

Alternatively, if there is an easier (cheap) way to authenticate a
Windows based client , I am all ears.

Thanks,

Jim C.

Post by brian jones
yes that does answer my question, thanks alot. and thanks to kevin
for the links to pgina and psynch.
-brian

Subject: Re: windows authentication & openldap: explanation.
Date: Fri, 26 Jul 2002 14:51:47 -0700 (PDT)
1. Server (or /etc/passwd) stores a hashed password, e.g.
"{ROT-1}tfdsfu"
2. Client hands server the cleartext of the user input, e.g. "secret"
3. Server hashes the client user input and compares it with the stored
hased password. If they match, it returns TRUE.
1. Server stores cleartext of the password, e.g. "secret".
2. Server sends client a challenge, e.g. "abcdef".
3. Client hashes the client input and the challenge together, e.g.
"tgfvjz" and sends this response to the server.
4. Server hases the client input and the challenge together and compares
to the client's response. If they match, it retuns TRUE.
The Windows authentication has the advantage that the cleartext password
is never sent over the wire. It the the disadvantage that the server must
store the cleartext password.
OpenLDAP is designed to store hashed passwords, as is the Unix tradition.
Since Windows authentication would require storing cleartext passwords,
OpenLDAP doesn't implement the challenge/response model of Windows
authentication.
You can get around this limitation. You can store a hashed password in the
userPassword attribute and have your Unix clients authenticate off it via
LDAP. You can also store a cleartext password in the smbPassword attribute
and tell Samba to get passwords from LDAP. Samba implements the Windows
challenge/response model and your Windows clients can authenticate off it.
You then need to do some scheming to make sure that the userPassword and
smbPassword attributes stay in sync.
That answer you question?

_________________________________________________________________
http://photos.msn.com/support/worldwide.aspx

[Kervin L. Pierre]

Jim C wrote:
[...]

Post by Jim C
The windows based cleint is a Win2K box. I am basically trying to figure
out the differenece between what the client is sending
and what the server expects.

[...]

Try a network sniffer like ethereal, http://ethereal.com/ . Ethereal
disects the LDAP protocol, so you get a nice break down of the session.
It works really well for debugging clients.

I don't think there's an 'easy' way for doing this. Samba, the synch
products, and the GINAs are all probably going to take some work to
configure.

If you're interested in an opensource synch. solution, I have posted my
NT password filter DLL at http://acctsync.sf.net/ . This is similar to
psynch, novell's and iplanet's approach. The diffence is that mine is
configurable to call any abituary program when the user changes their
password, configurable in the registry. I use an OpenLDAP replica and a
back-perl module on win2k to add/del/modify Win2k domain accounts when
LDAP accounts are add/del/modify in the master ldap server. It works
well with 3500 accounts. But would not fall under easy to configure, I
don't think.

--Kervin

[Adam Williams]

Post by Jim C
This thread is riight up the alley of my most recent headache. ;-)
First off let me warn you guys that I am a student and that I am working
on a accedemic project. Consequently, purchased solutions are out.
In order to authenticate a Windows based client I am trying to use the
pGINA module with the LDAP plugin.
I've not be able to figure out the configureattion despite haveing a
Unix ldap.conf that works to use as a base.
I can email this to anyone who wants to help.

How about asking on the pGina lists? This doesn't have anything to do
with OpenLDAP

Post by Jim C
Alternatively, if there is an easier (cheap) way to authenticate a
Windows based client , I am all ears.

Samba costs the same, and is more "native" IMHO, but I don't know if it
is "easier"

[Luke Howard]

Post by Mark H. Wood
It looks possible to replace ADS with OpenLDAP + Kerberos + very recent
BIND + lots of private Microsoft schema definitions for which there is, so
far as I know, no description which is both public and machine-readable.
(And the human-readable spec. appears to be incorrect in some areas.)

There a number of key components that are not available yet in the
open source realm, such as SPNEGO, back-links, PAC signing, etc. We
have made some progress on this front, and independently the SAMBA
team are making great progress too. But it's a long way from ready.

Post by Mark H. Wood
It just takes a loooong time to wrap up all the little pieces and make
them play together nicely. Someone will do it eventually.

Agreed.

-- Luke

--
Luke Howard | lukehoward.com
PADL Software | www.padl.com