Same Access Tokens, Same Privileges
The magic behind simple access tokens.
- By Bill Boswell
- August 17, 2004
Question: I have an Active Directory domain called XYZ.com.
This domain has a user called userAA whose password is Pa$$word.
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
| Get
Help from Bill |
|
Got a Windows or Exchange question or need troubleshooting
help? Or maybe you want a better explanation than provided
in the manuals? Describe your dilemma in an e-mail
to Bill at mailto:[email protected];
the best questions get answered in this column.
When you send your questions, please include your
full first and last name, location, certifications (if
any) with your message. (If you prefer to remain anonymous,
specify this in your message but submit the requested
information for verification purposes.)
|
|
|
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.