Why Does WinNT Re-Authenticate Users?

• Previous message: jameson: "the classic AOL AIM questions..."
• Reply: Kumar Pandit [MS]: "Re: Why Does WinNT Re-Authenticate Users?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: eric[no_spam]@pmcipa.com
Date: Tue, 22 Jan 2002 03:05:05 GMT

I'm trying to figure out exactly what happens in terms of
authentication when a user requests a network resource (like a server
share or remote disk file) in a Windows NT domain environment.

According to my several hours of reading so far, here is what I think
I know (folks, please check me out on this):

1. When a Windows NT workstation boots up, it starts the WINLOGON
process and presents the SAS (Secure Attention Sequence) banner.

2. When the user presses CTRL+ALT+DEL, the WINLOGON process calls
functions within MSGINA.DLL to bring up the logon challenge and
request the user's credentials.

3. When the user presses ENTER, MSGINA.DLL calls functions within
the LSA, passing it the user's credentials along with the name of the
required authentication package.

4. The LSA calls the requested authentication package, which
determines that the user is not local, so it passes the credentials to
the NETLOGON process.

5. NETLOGON requests a secure connection to a domain controller.
The DC sends back a nonce (a one-time random number) which the
workstation encrypts along with a hash of the user's password and
sends the whole package back to the DC. The DC performs the same
encryption operation using the password from its SAM database and
compares what it derived with what it received. Assuming the
credentials match, it accepts the authentication and returns the
user's SID, the SIDs of any groups that the user belongs to, and the
user's rights.

6. NETLOGON on the workstation receives the SIDs and other info
from the DC and passes them back to the LSA, which creates an access
token, and passes it back to the authentication package, which passes
it back to MSGINA, which passes it back to WINLOGON, which uses
CreateProcess() to start EXPLORER.EXE with the user's access token
attached. Any further operations that the user performs with
EXPLORER.EXE are done with that access token. Microsoft calls this
whole process "Interactive Authentication" because the user had to
enter his credentials.

I think I'm pretty close on all this. What happens next is the
confusing part. Suppose the user, having successfully logged into the
domain, now wants to access the resource \\SERVER\SHARE\File.txt
through EXPLORER. I have been taught that no further authencation is
required, because the EXPLORER.EXE already has the user's access
token. When the user connects to the remote resource, his access token
gets presented against the ACL of the remote resource. The Secrurity
Reference Monitor on the remote server compares the user's access
token to the requested resource's ACL and either grants or denies
access according to what it finds. End of story.

Or not.

>From recent reading, I gather that the whole authentication process
(this time non-interactive using cached credentials) actually happens
each time the user requests a connection to a new resource.

Does anybody know the real scoop? If Windows really behaves this way,
then why? What is the point of creating an access token for the
current logon session?

--Eric Robinson

• Next message: Ken Hagan: "Re: Why Does WinNT Re-Authenticate Users?"
• Previous message: jameson: "the classic AOL AIM questions..."
• Reply: Kumar Pandit [MS]: "Re: Why Does WinNT Re-Authenticate Users?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]