Security Principals and Subjects
Security Watch Subjects and Security Principals
Jesper M. Johansson

At the most basic level, everything in security boils down to subjects and objects. Objects are the things you protect and subjects are the things you protect objects from. These two constructs are used in authentication (proving who you are), authorization (granting access to something), and auditing (tracking who accessed what). Fundamentally, these concepts are very simple, as shown in Figure 1.
Figure 1 A user attempts to read a file
Subjects are things that do things, while objects are the things they do them to. Moreover, sometimes the objects to which subjects do things are other subjects.
Windows supports some immensely rich semantics when it comes to security and has greatly extended the definitions of subjects and objects. A subject can be much more than just a user, and the representation is far more complex than just a basic user identifier.
In Windows parlance, a security principal encompasses not only the typical subject (what you would think of as a user) but also groups and computers. A security principal is anything that can be assigned a security identifier (SID) and given permission to access something.
In this installment of Security Watch, I am giving an introduction to how subjects are represented and used in Windows.
The Subject/Object/Action Tuple
Managing security very often comes down to the subject/object/action tuple. The subject is the actor that is trying to perform some action on an object. For example, a user may try to access a file, as shown in Figure 1. When a user tries to read the file, the operating system needs to check whether permissions are set on the object (the file) that permits the subject (the user) to perform the action (read) on that particular object. If the permissions are in order, the access request succeeds. If the permissions are not in order, the access request is denied. So far, this is all very simple.
Case Matters
In Windows literature, when you see the words "Administrator" or "Administrators" with a capital "A," this typically refers to the user or the group, respectively. When you see it spelled in all lowercase—"administrator"—it refers to some user account or person that has administrative privileges. The same holds for other entities, such as "Guest" and "guest."

Types of Security Principals
Subjects—or security principals, as I shall henceforth refer to them—in a Windows-based system, and by extension a Windows-based network, can be much more than just users. However, the user is still the most basic concept.
Users A user is some distinct entity that logs on to a computer. Fundamentally, all security principals are at least somewhat related to users. In Windows, there can be two types of users: local and domain. A local user is defined in the local Security Accounts Manager (SAM) database on a computer. Every Windows-based computer has a local SAM, which contains all the users on that computer.
It is commonly thought that domain controllers (DCs) do not have a local SAM and hence no local users. This, however, is incorrect. Even a DC has a local SAM, but the accounts in its SAM can only be used in Directory Services Restore Mode.
The local SAM always contains at least two user accounts: the Administrator and the Guest, and the Guest account is always disabled by default.
On all versions of Windows Server 2008 (with the exception of Windows Small Business Server 2008), the Administrator account is enabled by default and you must use this account the first time you log on to the computer. On Windows Vista, the Administrator account is disabled by default and can only be used under very restrictive circumstances.
In either case, you should create at least two accounts for each person that will administer a given computer. If you are subject to almost any kind of regulation (and you probably are), this is a requirement. For each user, one account should be the user's own personal administrative account. The other account is the user's personal non-administrative account for non-administrative tasks.
Users Who Are Not Local Are Domain Users These users are defined on the DCs for the domain. The difference between local and domain accounts is primarily the scope of the accounts. Domain accounts can be used on any computer in the domain while local accounts are valid only on the computer on which they are defined. Furthermore, domain accounts can have a considerably larger number of properties associated with them as compared to a local account (see Figures 2 and 3 for comparison).
Figure 2 Properties window for a local account
Figure 3 Properties window for a domain account
Domain accounts have a richer set of semantics, covering a variety of attributes in an organizational environment, such as telephone numbers, management relationships, and e-mail accounts. Domain accounts are also far more useful in a network because they can be used and assigned permissions on computers across the network. In addition, defining accounts in the domain simplifies management as now you only have to maintain accounts in one place.
Computers A computer is just another type of user. In Active Directory, this is particularly true and is borne out by the inheritance model. The inheritance structure leading to a computer is outlined in Figure 4.
Figure 4 The inheritance hierarchy in Active Directory showing how users and computers are related
There are several very interesting things illustrated in Figure 4. First, as you can see, all classes in Active Directory derive from a root class called Top. In fact, even Top is considered a subclass of Top. Second, the User class is derived from the organizationalPerson class. Third (and this is the most interesting point), the Computer class is derived from the User class. In other words, in object-oriented parlance, a Computer is a type of user. Anthropomorphizing computers in this way does actually make a lot of sense, though, because computers need to be treated as subjects as well and have almost all the same attributes as a person.
Groups A subject, you will recall, is something that attempts to access an object. The operating system verifies this access attempt by checking the permissions of the object. Very early on, OS designers realized that it would be very unwieldy to assign permissions to every single object for every single user that needed it. To solve that problem, the designers permitted users to be members of groups. This allows you to assign permissions to groups in addition to users.
A group may not be a user, but a group is still a type of security principal because it can have an identifier, just like users and computers. In Windows, a user can be a member of many groups and an object can have permissions assigned for many groups. Nested groups are also permitted, with some restrictions.
A non-domain controller has only two types of groups, built-in groups and local groups that the administrator has defined. In Active Directory, however, you will find six different kinds of security groups: built-in Domain Local groups, built-in Global groups, built-in Universal groups, user-defined Domain Local groups, user-defined Global groups, and user-defined Universal groups.
Domain Local groups can only be assigned permissions to resources within the domain where they are defined. They can, however, contain users, universal and global groups from any trusted domain or forest, and Domain Local groups from their own domain.
A Global group may only contain users and global groups from the domain in which it was defined, but it may be assigned permissions to resources in any domain in the forest the domain is part of or any trusting forest.
A Universal group may contain users and Universal and Global groups from any domain. A Universal group may be assigned permissions to resources in any trusting domain or forest. In other words, a Universal group is a kind of hybrid between Domain Local and Global groups.
While a workstation comes with only two groups by default—Administrators and Guests—a domain comes with a relatively large number, of all three types. Figure 5 shows the default groups in a domain. All are designated as Security Groups, which means they can be assigned permissions. (Security groups should not be confused with Distribution Groups, which are used by Microsoft Exchange Server to group users into e-mail lists. Both are defined in Active Directory.) The local groups that exist on all Windows-based computers are defined in Active Directory on DCs.
Figure 5 Default groups defined in the Users container in Active Directory
As with DCs, some non-DCs have large numbers of groups as well. Figure 6 shows 16 built-in groups on a test computer. The exact number of groups on any given computer will differ depending on the roles you've installed on that computer.
Figure 6 Built-in groups on a non-DC (Click the image for a larger view)
If you were to attempt to assign permissions to an object, you would find still more groups than what I have shown so far. In fact, on a basic DC, you would find no fewer than 63 groups and built-in security principals, shown in Figure 7.
Many of the 63 groups that are shown in Figure 7 are abstract concepts, which are sometimes known as "special identities," that represent a dynamic group of security principals. They are also sometimes also referred to as Logon Groups.
Logon Groups Logon groups are groups that represent some dynamic aspect of a security principal, such as how a user or other security principal has logged on. For example, the INTERACTIVE group shown in Figure 7 includes all users that logged on to the console of the computer and via Terminal Services. By contrast, the NETWORK group includes all users that logged on via the network. By definition, a user can only be a member of one of these groups at a time and membership in them is assigned at logon time. You can use these groups to grant permissions to all users logging on a certain way, but you cannot control who becomes a member of those groups.
Figure 7 A basic DC has no fewer than 63 groups and built-in security principals
There are other groups of this nature, as well. Of particular note are the Everyone group and the Authenticated Users group. The Everyone group includes, as the name implies, every user accessing this computer—with the exception that, starting with Windows XP, completely anonymous, unauthenticated users are not included. In other words, the infamous NULL user is not included in Everyone on any supported Windows-based operating system. Guests are included, though.
The Authenticated Users group, while also populated dynamically, includes only those users that are actually authenticated. Thus, guests are not included in Authenticated Users. That is the only difference between these two groups. But since the only guest account that exists on the operating system is disabled, there is no functional difference between Authenticated Users and Everyone unless you have taken manual steps to enable the Guest account, in which case, presumably, you want Guests to be able to access resources, and therefore need the Everyone group intact.
In spite of this, many administrators have lost many hours of sleep over the fact that "everyone in the world has permissions on my server" and have taken very drastic steps to modify permissions to rectify this situation. Typically these modifications have completely disastrous results. You have no reason whatsoever to try to replace permissions for Everyone with Authenticated Users. Either you want guests to have permissions to your computer and you enable the guest account, or you do not and you leave the guest account disabled. If you do want guests to have permissions, you need the permissions for Everyone. If you do not, the Everyone group will not be any different from Authenticated Users.
Some people argue that making these changes are "defense-in-depth" changes. That would be true if you define "defense-in-depth" as "changes you cannot justify any other way." The fact is that such modifications provide little or no security improvement while carrying a very large risk. Leave the defaults alone.
If that argument was not persuasive enough, I direct you to Microsoft Knowledge Base article 885409 ("Security configuration guidance support"). It states, in a nutshell, that wholesale permissions replacement can void your support contract. When you do that, you basically build your own operating system and Microsoft can no longer guarantee that it works.
It is also worth pointing out the difference between Users, which is a built-in group, and Authenticated Users. The difference is the rather obvious fact that Authenticated Users includes every user that has authenticated to the computer, including users in different domains, users that are members of local groups other than Users, and users that are not members of any groups at all (yes, such a thing is possible). This means the Users group is far, far more restrictive than Authenticated Users.
In spite of this fact, I have seen organizations destroy their networks attempting to replace permissions for Users with permissions for Authenticated Users in an attempt to "harden their systems." I have argued endlessly with clueless PCI/DSS Auditors who claim that the payment card industry requires you to replace all permissions for Users with Authenticated Users. This simply is not true.
I have also defended organizations around the world from consultants who seem to view wholesale access control list (ACL) replacement as a great way to rack up billable hours. Needless to say, you can expect any attempts to do wholesale replacement of Users or Everyone with Authenticated Users to be largely unsuccessful with respect to both security and stability.

Windows Vista and Windows Server 2008 support one new type of Security Principal: a service. To understand how these entities are valuable, consider the ongoing debate about host-based firewalls. Many people, supported eagerly by the vendors selling the products, argue that host-based firewalls must filter outbound traffic to be worthwhile because this protects the remainder of the network from a compromised computer. More objective minds point out that if a computer is compromised, the malware is already present on the computer and thus the malware has the ability to bypass or disable the host-based firewall entirely.
To understand why this is the case, consider two services running as the same Security Principal. Service A is permitted to communicate through the firewall, Service B is not. If Service B is compromised, the attacker could bypass that restriction simply by taking over another process running as this Security Principal, Service A, for instance, and communicate from that process instead.
To address this problem, Microsoft needed a way to apply permissions to a process, or more specifically, to a service. For this purpose, services became security principals in their own right. And as a result, each service now has an identifier that can be used to apply permissions against. You can run the "sc showsid" command from the command line to see the service SID for any service.
With Service SIDs, you can restrict access to resources for specific processes, as opposed to only restricting access for specific users. This change makes outbound host-based firewall filters meaningful, in some situations. The exact nature of those situations is beyond the scope of this discussion, but if you're interested in reading more about this, I suggest you read the article I wrote about the Windows Vista firewall in the June 2008 issue of TechNet Magazine (see "Managing the Windows Vista Firewall").

Wrapping Up
Security principals underlie so much of Windows security that it is essential for any administrator to have at least a basic understanding of how the various types of Security principals work and how they are used. Only by understanding these topics can you effectively create a security strategy that effectively uses these security principals. This knowledge will be handy when you must withstand pointless arguments from people who do not thoroughly understand security principals and expect you to endanger the health of your network with unnecessary and inappropriate changes.
This column is based on material in my book Windows Server 2008 Security Resource Kit (Microsoft Press).

Jesper M. Johansson is Principal Security Architect for a well-known Fortune 200 company, working on risk-based security vision and security strategy. He is also a contributing editor to TechNet Magazine. His work consists of ensuring security in some of the largest, most distributed systems in the world. He holds a Ph.D. in Management Information Systems, has more than 20 years experience in security, and is an MVP in Enterprise Security. His latest book is the Windows Server 2008 Security Resource Kit.

Page view tracker