NT authentication in a domain, need clarification

Luke Kenneth Casson Leighton lkcl at regent.push.net
Fri Apr 24 22:58:46 GMT 1998


On Sat, 25 Apr 1998, Phil Cox wrote:

> I have some confusion WRT authenticating in a domain. Here are the
> scenerios, and my understanding of how the authentication happens. 
> 
> Client : NT4 WS
> Server: NT4
> PDC: NT4
> Assume user has already authenticated to the domain on the client and is
> now attempting to access a share.
> 
> BTW: Where is the access token stored on the domain logon? The workstation
> or the PDC (then replicated)? Both?
> 
> 1. Client to PDC share:
> Client sends an SMB negotioation request to PDC. PDC responds. Client then
> sends an SMB session request to PDC. PDC issues challenge, client encrypts
> with stored OWF, and returns it to PDC. PDC verifies it. Issues & stores an
> access token and an associated UID. PDC returns UID to client. Client uses
> UID in all subsequent SMB packets to the PDC.

correct.
 
> 2. Client to Server share:
> Client sends an SMB negotioation request to server. Server responds.Client
> then sends an SMB session request to Server. Server send authentication
> request to PDC. PDC issues challenge to server. Server forwards that
> challenge to client. Client encrypts with stored OWF, and returns it to
> server. Server forwards it to PDC. PDC verifies it, says "ok" to server.
> Server issues & stores an access token and an associated UID. Server
> returns UID to client. Client uses UID in all subsequent SMB packets to the
> Server.

correct!

 
> **I was told that this is not correct.

tell them i suggested they stare at packets for a few days, as a penance. 
if they give you a hard time, tell them that they have to run the above
scenario and send me a netmonitor trace of it, with a fully annotated
explanation of what's going on.

> Can someone please give me a pointer to the nitty gritty.

the "verification" mechanism, of forwarding the OWF to the server, is
called "pass-through" authentication.  there are two forms of this

1) documented in CIFS - you specify pass-through in the SMBsessionsetupX
or something.

2) send a "network" (type 0x3) version of an LsaSamLogon not an
"interactive" version.  the difference is that in the interactive login
the password is both 16 byte LM and the NT hashes; in the network login,
the "password" is the challenge (generated by the "Server: NT4" above)
and the two 24 byte OWF responses (generated by the client in response to
the challenge, and received by the server in the SMBsessionsetupX
response).

the PDC then responds to the LsaSamLogon with login details or
"NT_STATUS_WRONG_PASSWORD".

as you can see, this is not particularly secure if one of your routers are
compromised: the packet can be hijacked and modified...

luke



More information about the samba-ntdom mailing list