Why Does WinNT Re-Authenticate Users?

eric[no_spam]@pmcipa.com

unread,

Jan 21, 2002, 10:05:05 PM1/21/02

to

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

Ken Hagan

unread,

Jan 22, 2002, 6:20:58 AM1/22/02

to

<"eric[n???????????? wrote...

>
> I think I'm pretty close on all this.

I think so too.

> Suppose the user, having successfully logged into the
> domain, now wants to access the resource \\SERVER\SHARE\File.txt

> through EXPLORER. [snip] 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.

Sort of. The result of the interactive logon is a logon session
on the user's workstation. To access the file, we need a logon
session of the same user on \\SERVER. Since we have the cached
credentials on the workstation, we can do this without bothering
the user. (If wou play about with NET.EXE you can actually log
onto the second machine as someone else, and file access will
use that different token.)

Having done it, subsequent access to files on \\SERVER don't
usually require re-authentication. (In practice, the file server
service will drop the session after a while.)

As a final note, the logon session on \\SERVER does not get a
copy of the user's network credentials, so isn't able to make
further hops.

eric[no_spam]@pmcipa.com

unread,

Jan 22, 2002, 11:32:24 AM1/22/02

to

>Having done it, subsequent access to files on \\SERVER don't
>usually require re-authentication. (In practice, the file server
>service will drop the session after a while.)
>

This is bit unclear with me. Some parts of Microsoft documentation say
that subsequent accesses to the same resource do not require
re-authentication because the original access returned a handle to the
object. Subsequent accesses to the same object just re-use the same
handle. Fine, but...

>As a final note, the logon session on \\SERVER does not get a
>copy of the user's network credentials, so isn't able to make
>further hops.
>

And this is where I lose it. If the non-interactive logon session does
not require credentials, why do we call it a "logon session?" Also,
why would we refer to it as "authentication," since authentication is
all about credentials?

Finally, the whole question that brings this up relates to security in
our Internet DMZ. Our organization has two domains--a master domain at
the corporate location and a resource domain (one-way trust) to a
small domain that is colocated at our ISP, behind a PIX firewall that
we own and administer.

The one-way trust makes it easy for our web team to administer the
machines in the DMZ domain. However, I began to wonder if, whenever
they connected to resources in the DMZ domain, their credentials were
being presented in the DMZ domain. From my reading, the answer appears
to be yes, although the DMZ domain simply passes them back to a DC in
the trusted domain for authentication. The point is that the
credentials do appear to traverse the Ethernet in the DMZ, which I'm
afraid exposes them to interception and cracking by someone who has
managed to commandeer one of the DMZ computers. Having done so, they
could obtain credentials for the corporate domain, which would qualify
as a Bad Thing. (Originally, I thought that the web users would simply
present an access token against the resource in the DMZ domain. The
server in the DMZ would see that the token was authenticated by a
trusted domain and would not re-authenticate the user. That does not
appear to be the case.)

This is why I have to get an absolutely authroitative answer on the
question about re-authentication and the presentation of credentials.

Gary Flynn

unread,

Jan 22, 2002, 3:33:07 PM1/22/02

to

"eric[no_spam]"@pmcipa.com wrote:
>
> The one-way trust makes it easy for our web team to administer the
> machines in the DMZ domain. However, I began to wonder if, whenever
> they connected to resources in the DMZ domain, their credentials were
> being presented in the DMZ domain.

There are some resources listed at the bottom of the following
(out-of-date) page that you might find helpful. Some MS applications
will send NT credentials, or at least their hash, by default to
other systems as part of the connection process.

http://www.jmu.edu/computing/info-security/engineering/issues/desk/windows_passwords.shtml

--
Gary Flynn
Security Engineer - Technical Services
James Madison University

Please R.U.N.S.A.F.E.
http://www.jmu.edu/computing/runsafe

Kumar Pandit [MS]

unread,

Jan 22, 2002, 6:05:21 PM1/22/02

to

If you logon to computerA interactively and then want to access a
resource on computerB, you will need to re-authenticate to
computerB. The reason is that computerB does not trust computerA to
provide any information that it can use without verifying. If that
were the case, if computerA is compromised it can generate an access
token having domain admin SID in it and send to computerB and have a
domain admin access on computerB. This is not what you would
want. Because of this reason, access tokens are local; they are not
transmitted on the wire. The remote machine will generate a new logon
session based on the credentials that you provide.

eric[no_spam]@pmcipa.com writes:

--
Kumar Pandit
Microsoft Security Developer

(This posting is provided "AS IS" with no warranties, and confers no rights.)

Eric Robinson

unread,

Jan 23, 2002, 3:10:36 AM1/23/02

to

On 22 Jan 2002 15:05:21 -0800, kum...@microsoft.com (Kumar Pandit
[MS]) wrote:

>
>If you logon to computerA interactively and then want to access a
>resource on computerB, you will need to re-authenticate to
>computerB. The reason is that computerB does not trust computerA to
>provide any information that it can use without verifying. If that
>were the case, if computerA is compromised it can generate an access
>token having domain admin SID in it and send to computerB and have a
>domain admin access on computerB. This is not what you would
>want. Because of this reason, access tokens are local; they are not
>transmitted on the wire. The remote machine will generate a new logon
>session based on the credentials that you provide.
>

Access tokens are local... not transmitted on the wire. I was
wondering about that since I did not seem to see anything that looked
like access tokens in my network traces. I'm going to have to chew on
that one a bit. Let's see... the purpose of an access token is to
attach to a process so that the Security Reference Monitor can
determine whether that process has rights to any resource protected by
an ACL, right? And as you say, tokens are only locally significant;
they do not get presented against remote resources. So when I use
Explorer from computerA to access \\computerB\share\file.txt, the
access token attached to my Explorer process on computerA actually
does not enter the picture at all? Okay, then I guess computerB would
create its own locally significant access token for any processes I
would run on that computer... except that I'm not running any
processes there, I'm just accessing a file remotely, so what does my
access token on computerB do, if one gets created there? Does
computerB associate a token with the file handle that it returns to
computerA? Or does it associate a token with my logon session? Is it
one token per logon session? That's beginning to sound right to me. I
hope I'm on the right track.

unread,

Jan 24, 2002, 5:46:56 AM1/24/02

to

"Eric Robinson" <"eric[n???????????? wrote...

>
> Let's see... the purpose of an access token is to
> attach to a process so that the Security Reference Monitor can
> determine whether that process has rights to any resource protected by
> an ACL, right?

Yep.

> And as you say, tokens are only locally significant;
> they do not get presented against remote resources. So when I use
> Explorer from computerA to access \\computerB\share\file.txt, the
> access token attached to my Explorer process on computerA actually
> does not enter the picture at all?

Yep.

> Okay, then I guess computerB would create its own locally
> significant access token for any processes I would run on
> that computer... except that I'm not running any processes
> there, I'm just accessing a file remotely, so what does my
> access token on computerB do, if one gets created there?

Yep. Behind the scenes, you log onto computer B. No processes are running,
but the logon session is created and that gives B a token
that its file server can use to perform access checks, or any other
activity for that matter (such as file creation).

> Does computerB associate a token with the file handle that it
> returns to computerA? Or does it associate a token with my logon
> session? Is it one token per logon session? That's beginning to
> sound right to me. I hope I'm on the right track.

No, yes, yes.

Eric Robinson

unread,

Jan 24, 2002, 9:52:17 PM1/24/02

to

Excellent. Thanks guys. I understand this a *lot* better now.

Thanks very much indeed.