Same Access Tokens, Same Privileges

The magic behind simple access tokens.

• By Bill Boswell
• 08/17/2004

I know that, when userAA logs onto the domain from a member Windows 2000 computer, he will be authenticated through Active Directory using Kerberos and will be granted an access token so he can access all the resources on the network according to his privileges.

I put a freshly installed PC running Windows 2000 on the same physical network as the domain but did not join it to the domain. I created a new local account on this PC with the same user name, UserAA, and the same password as the domain user account.

When I log on locally then connect to domain member servers, I see that this user gets the same privileges on those servers as if he were logged onto the domain. How is this possible? I thought that a local user got a different SID.
— Mohamed

Answer: I get this question quite often, probably because the term "access token" gets used incorrectly in many sources of Windows documentation. Here's what happens in Mohamed's scenario:

First, userAA logs on at the standalone computer by giving the name and password that you set in the local Security Account Manager (SAM) database. When the logon succeeds, the user gets an access token containing the user's SID (extracted from the SAM) along with the SID for any local groups to which the user belongs.

When the user touches a secured object on the local machine (NTFS file or folder, Registry key, printer, etc), the Security Reference Monitor (SRM) compares the content of the access token with the Access Control List (ACL) in the security descriptor for the object. If the SRM finds a matching SID, it grants access to the secured object based on the permissions defined for that particular trustee.

Okay, that's pretty simple stuff that just about all Windows administrators can recite in their sleep. Now let's look at the second piece, when userAA reaches out across the network to a share on a server that is a member of the XYZ.com domain.

Inside the very first Server Message Block (SMB) connection request you'll find a flag indicating the type of authentication supported by the client. At this point, the domain member server determines that the connection does not come from a member of its domain or a domain in the same forest.

At this point, then, the member server puts Kerberos authentication aside and falls back on classic NTLMv2 (NT LanMan version 2) pass-through authentication. As part of pass-through authentication, the member server communicates with its logon server (an Active Directory domain controller) via a secure channel. It passes through the name of the user attempting the connection and essentially asks the domain controller to validate this user's identity.

The domain controller sends a 16-byte random number called a challenge to the member server, which then relays it to the client. The client hashes this challenge along with a hash of the user's local password. Recall at this point that you gave the local account the same password as the domain account.

The domain controller performs the same hash of the challenge using the password hash for the user that it stores in Active Directory. Because both Active Directory and a standalone Windows 2000 PC use the same hashing algorithm for passwords (MD4) and for challenge-response validation, the client's response to the challenge succeeds and the user is authenticated.

Here's where some magic happens: The domain member server now gets a data structure from the domain controller that contains the user's "domain" SID, the user's "domain" group memberships, and the user's "domain" privileges. This data structure is protected by the secure channel between the member server and the domain controller.

The member server uses the contents of that data structure to build a local access token at the server. In effect, this gives the user domain privileges even though the user has connected from a standalone PC.

The key thing to remember is this: access tokens, like politics, are always local.

If you want to see the contents of your access token, the Support Tools has a utility called whoami. Run this with the /all switch and it will list the contents of the access token. This is a handy trick because a user might belong to groups nested into other groups, so that would contain SIDs of those groups, as well.
Hope this helps.

Feedback: RPC over HTTP
I got quite a few replies to the RPC over HTTP column that ran a couple of weeks ago. Many of the requests were for instructions on setting up RPC over HTTP for a single Exchange server rather than a front-end/back-end architecture. I'm working on it.

Daryl from Down Under pointed out that Small Business Server 2003 isn't nearly as complicated to set up as a single Exchange server. Not only does a standard installation of SBS 2003 include RPC over HTTP, the setup wizards collect and apply the HTTP port numbers in the Registry, configure an SSL certificate, and set permissions on the RPC virtual folder. All you need to do is import the certificate at the user's laptop then point a properly configured Outlook client at the server. That's that. Thanks, Daryl.