Get started Bring yourself up to speed with our introductory content.

How access control works

This excerpt from Chapter 5 of "The definitive guide to Windows 2000 security" explains what access control really does.

Get a glimpse inside Paul Cooke's e-book "The definitive guide to Windows 2000 security" with this series of book excerpts, courtesy of This excerpt is from Chapter 5, "Configuring access control." Click for the book excerpt series or get the full e-book.

How access control works

The access control model describes the core principles behind Windows 2000's access control; however, more important than understanding this model is understanding what access control really does. Quite simply, access control strives to answer the fairly simple question: "Can [security principal] perform [specified action] on [specified object]?" The question doesn't seem so simple in those terms, so let me change the question to read as Figure 5.2 shows: "Can Bob open the file?" The grammar of the two questions is the same, but the second one provides a more understandable context.

Figure 5.2: The simple goal of access control.

While access control is geared to answer a question as simple as, "Can Bob open the file?" the realities are a lot more complicated. First and foremost, you and I know that Bob cannot actually open a file; some process running on his behalf has to do it. If you recall from the discussion in Chapter 2, a process is a collection of threads of execution. So the reality is that a specific thread is actually going to open the file for the process that is running on Bob's behalf.

Windows 2000 uses access tokens to know that a specific thread is running on behalf of a user. When you log on to a system, Windows 2000 authenticates you and automatically creates a unique access token that is associated with you and your logon session. Each thread that a process launches on your behalf during your logon session receives a copy of this access token. As a result, Windows 2000 can always look at the access token of a thread and know which security principal it's running on behalf of. Because each thread has one, and only one, associated access token, Windows 2000 can use the thread as the security principal for access control decisions.

Now that the subject of our basic question is defined, let's define the other portions of the question. Just as there is a level of indirection between Bob and his access token, so too is there a level of indirection between Bob and the action. When Bob takes an action such as using a process to open a file, program instructions are executed that interact with Windows 2000 to actually open the file. These program instructions use one of the standard application programming interfaces (APIs) provided by Windows 2000 that were created just for this type of action.

As a result of calling a system API to open a file, the action Bob wants to perform (open) and the object he wants to perform the action on (a file) are both defined. If you're not all that familiar with application programming, this description of events may seem a bit odd. But remember that neither you nor Bob can physically reach into a computer and open a file on the hard drive; the action all happens on your behalf inside the code of the computer.

At this point, a thread running on Bob's behalf has made a system call to open a specified file. Now it's time for the access control decision to be made. As I discussed in Chapter 2, this decision is made by the Security Reference Monitor (SRM), which is responsible for validating access rights throughout Windows 2000.

To perform the access control check to determine whether Bob can open the file, the SRM compares information stored in the thread's access token (remember, it's a copy of Bob's access token) with the information stored in the file's security descriptor. This process is shown in Figure 5.3. In the access token are Bob's security identifier (SID) and a SID for every group that he is a member of. In the file's security descriptor is an access control list (ACL) that specifies who is explicitly allowed or denied access to the file on a user and/or group basis.

The SRM walks through the ACL of the file object looking for any access control entries (ACEs) that apply directly to Bob or to any groups that Bob is a member of. If the SRM finds an ACE that explicitly denies access to the file, the SRM denies the thread access to the file. If the SRM finds an ACE that explicitly grants access to the file, it grants the thread access to the file. If it finds no explicit ACE that matches Bob's SID or any of the group SIDs for groups that Bob is a member of, the SRM denies the thread access to the file.

Figure 5.3: The process of comparing access control.

This quick overview of access control gives you a good look at how things are done in Windows 2000, but it probably generates more questions than it answers, such as: What is really in an access token? What are user rights and privileges? What is a security descriptor? and Is there more than one kind of ACL? You probably have other questions as well.

To answer these questions, I'll walk through all the components that make up the access control implementation of Windows 2000. After I'm done, the example of how Bob opens a file should make complete sense to you.


Click for the next excerpt in this series: SIDs


Click for the book excerpt series or get the full e-book.


This was last published in November 2004

Dig Deeper on Windows Server deployment

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.