Windows Accounts, Logon & Authorization Fundamentals

The Basics of Windows Access Control

It can be tedious to navigate the big vast world of Windows access control. There is a ton of helpful material available out there in the Internet to help with the journey. Here, we try to provide a simplified introduction of Windows principals, accounts, and logons, as well as authorization, permissions, and user rights. Hopefully, your journey becomes a tad easier with this.

The Background

Let’s first get some background out of the way.

At a very fundamental level, you have subjects and objects.

Objects are things you protect, like files, registry keys, ports, and so on. Some people call them protected resources. Others call them securable objects. In this article, we’ll use the term securable objects.

Subjects are entities (such as user or program) that you protect the objects against.

In authentication, we verify whether the subject (user, for example) is what it says it is. In authorization, we grant the subject access to perform an action (read, etc.) on an object (file, etc.).

Principals, Accounts & Logons

Principals

In Windows, a subject can refer to several different things: a user, a group, a service, a computer, or a process, etc. Windows represents subjects (of authentication/authorization) as principals.

Each principal is identified by a unique and immutable SID (Security ID). If I logon to windows and start a process, the process will run under my SID.

Accounts

Now, principals have accounts, which are also known as log-on accounts or user accounts.

As this article sums up nicely:

“Accounts enables a user to sign in to computers, networks, and domains with an identity that can be authenticated by the computer, network, or domain”.

When you log in to Windows, you do so using a user account. The username identifies you, and the password is proof that you own the identity. The identity is associated with a principal that represents you (the subject).

Accounts can be either local or domain-based.

• A local account — as the name suggests — is maintained locally on a computer. It can be used to secure objects on the host computer only. Local accounts are defined/maintained in the local Security Accounts Manager (SAM) database. Every Windows-based computer, including the domain controller, has a local SAM.
• A domain account, on the other hand, is maintained in Active Directory (AD) on the domain controller (DC). A domain account can be used on any computer in the domain that the DC controls.

Accounts are used for logons. More about logons in the next section.

Logons

Logons are of various types, some of which are: interactive logon, network logon, service logon, batch logon, unlock logon and so on.

The authentication mechanisms or methods available depends on the logon type. For instance, while you can use password-based authentication for interactive logon, you cannot use them for network logon.

What is an interactive logon? When you login to your laptop with direct physical access, you are using interactive logon. You can perform an interactive logon using either local user account or domain account. If I login to the same computer through RDP, the logon is qualified as a remote interactive logon.

A Windows service is also a subject. Accordingly, it has a principal. And, it performs a logon using an account of type service account. Service accounts are typically Windows user accounts created expressly for services. Unlike user logons that are performed interactively, services logon to the system non-interactively using their service accounts.

Services are assigned either a built-in service account or a custom service account. Local System, Local Service, and Network Service are all built-in service accounts.

Authorization

If I am logged in to Windows and start a process, typically that process as well its threads runs under the SID of my principal. Authorization in that scenario then is about making sure that each object that my process (or its threads) attempts to access is accessible only if my SID is authorized to access those objects.

How does that work?

Suppose, you try to read a file. The operating system (OS) checks whether read (the action) permissions have been set on the file (the object) for your SID. If yes, your access request succeeds. Else, you are denied access.

Well, how does it really work? There are a bunch of details that I’ve glossed over, but you can find some of those details in this document.

Securable objects have permissions applied to them via security descriptors/SDs. In our file example above, the securable object was a file. There are other types of securable objects: directories, services, processes, threads, registry keys, AD objects, firewall ports and so on. Among other things, the SD has a Discretionary Access Control List (DACL). A DACL is discretionary because it can be managed at will by the administrator and any other user with appropriate permissions as well as the object owner. For example, an admin can assign other users’ permissions on that object at her discretion.

Permissions vs. User Rights

Permissions define the type of access a principal has on a securable object. For instance, you can grant a particular user read and modify permissions to a file. To generalize, by setting permissions for a principal on an object, you can grant that principal access to perform the corresponding actions on that object. By default, the principal that creates an object is the owner of that object and can assign any permissions on that object to anyone at her discretion.

It’s important to note that permissions are attached to an object (and not the principal). What permissions you can attach to an object depends on the type of object (securable object). Files, registry keys, AD objects, etc. — all have different sets of permissions. Most objects have some common permissions like ‘Read’, ‘Modify’, ‘Delete’ and ‘Change Owner’.

There is another vehicle for assigning privileges — User Rights. While permissions are attached to objects, user rights apply to an account — user or group accounts, and are attached to access tokens.

User rights authorize users to perform per-computer operations such as signing in to a computer interactively, shutting down the computer, backing up files, auditing user’s successful/failed access to objects, log-on as a service, etc. — all actions that affect the entire computer, rather than a particular object [2]. If you have the right to backup files, you can backup any file on the computer, including OS files and other users’ and administrator’s files, regardless of the permissions set on the individual files (the objects).

User rights can be assigned to users or groups as part of security settings for the computer. User rights can also be managed centrally via group policy or through security settings for the computer. In either case, they are applied locally [2]: they apply to a given computer.

So, when the installation guide says allow read and write permissions for network share to the domain-based service account, you know it’s asking the IT admin to set permissions for the network share. On the other hand, when it says prevent interactive login for the service account, it’s talking about user rights (and not permissions).

References & Further Reading

1. J. M. Johansson, et. al., Windows Server 2008 Security: Resource Kit, Microsoft Press, 2008
2. Security Principals Technical Overview, https://technet.microsoft.com/en-us/library/dn486814(v=ws.11).aspx
3. Access Control Overview, https://technet.microsoft.com/en-us/library/dn408189(v=ws.11).aspx
4. J. Scambray & S. McClure, Hacking Exposed Windows: Windows Security Secrets & Solutions, 3rd Edition, McGraw-Hill, 2008
5. Andrew S. Tanenbaum & Herebert Bos, Modern Operating Systems, 4th edition, Pearson, 2015
6. Robert Broeckelmann, Kerberos and Windows Security: Kerberos on Windows, 2018