Windows Security

We will look at what comprises an SID in a bit but first let us look at how one maps a name to its SID and vice versa using lookup_account_name and lookup_account_sid respectively.

Both will optionally retrieve some additional information about the account.

We can use the command to map groups as well.

There are two things you may notice in this last example.

First, the type of the account is listed as alias. The type alias is nothing but an, uhm, alias for local group.

Second, the domain listed is called BUILTIN and is not the local system or a domain that the computer belongs to. This BUILTIN domain is present on all systems and contains accounts such as Users and Administrators that are created on every system when the operating system is installed.

We can use the -system option to map a name to an account on a different system.

Notice that

Let us look now at the structure of an SID. Although a SID is stored in internally in a binary form, its structure is also representable as a string which has the format

An SID string representation consists of a list of fields always starting with the letter S and separated by the - character.

The REVISION field determines the SID format and is always 1 as of this writing.

The AUTHORITY field partitions the space in which SIDs are defined. This is not to be confused with the term authority that we discussed earlier where the reference was to an entity that is trusted to identify and authenticate security principals. The meaning of the term will generally be obvious from context.

The values of this field are shown in SID Authorities.

The authority field is followed by one or more subauthority values, also known as relative identifier (RID). These form a hierarchy that collectively identify a trustee within the authority’s scope.

Here are a couple of examples:

Both these are defined under the NT authority as indicated by the S-1-5 prefix. The subauthorities differ in that in the first case the RID 32 indicates the built-in system domain while 544 identifies the local Administrators group no matter the system. In the second case, the last RID, 500, is a special RID indicating the local Administrator account and is the same across all systems. However, the parent RID components are specific to a particular system. Thus the SID for the Administrator account will be different on every system.

New SIDs are generated when user accounts and groups are created within an authority. In addition there are predefined well-known SIDs and RIDs that generically identify trustees. For example, the SID S-1-1-0 is the well-known SID representing the group Everyone which includes all trustees defined under any authority. Simlarly, the SID S-1-5-21-604578671-2071180537-1579705201-500 which is the well known RID 500 prefixed by the system’s SID always identifies the Administrator account on that system.

Well known SID’s are useful for creating generic access control rules. For example, you may want to allow access to certain resources only when the requesting user is logged on to the local console. This can be accomplished through an access control rule that only permits access to the SID S-1-2-1 which only includes trustees that are locally logged on to the console.

The full list of well-known SID’s is available in the MSDN documentation. Here we only describe some frequently used ones and how they might be used.

The table Well-known SID’s shows some very frequently used ones.

There are several commands available for working with SID’s. We have already seen a couple of these earlier, lookup_account_name and lookup_account_sid to convert back and forth between SIDs and account names. In addition, there are two commands map_account_to_name and map_account_to_sid which can take either a name or an SID as input. These are useful writing commands that may be passed either form.

There are separate commands, get_system_sid and get_primary_domain_info to retrieve the SID for the computer or the domain to which is belongs. For example,

Finally, well-known SID’s are constructed with the well_known_sid command.

See the TWAPI documentation for the list of well-known SID identifiers that can be passed to the well_known_sid command.

In many cases, you can also pass the name of the account as it would be called on a US English system. This can be easier to remember.

A user account represents a security principal, and as we never tire of repeating, a security principal is always defined within the scope of a trusted authority. In a Windows environment, this trusted authority may be the local system, in which case the account is stored in the local system’s SAM database, or the domain controller in which case the account is stored in the Active Directory repository for the domain.

Local account names have the general form

where SYSTEMNAME is the name of the system in whose SAM database USERNAME is defined. In many cases, just USERNAME suffices as SYSTEMNAME defaults to the local system if unspecified.

Domain names are specified using a format known as the User Principal Name (UPN) which has the form

This form is similar to that used for email though note that the similarity is purely syntactic. The name does not have to correspond to an email address at all.

Groups provide a mechanism for identifying collections of security principals and are discussed in detail in the [chap_adsi] chapter. Here we provide a much simplified description that suffices for the purposes of this chapter.

A global group is a collection of security principals each of whom is contained within the domain defining the group. Global groups can be nested so that a principal may indirectly be a member of a global group. A global group can be used within the domain definining it or within any trusting domain.

A local group, or an alias, can be used only within its domain but can contain user accounts and global groups from multiple domains. On a system that is not a domain controller, only local groups defined on that system can be used, not those defined on other systems. Note that local groups cannot be nested.

The primary purpose of groups is to assign privileges and resource access permissions to multiple security principals without having to manage them individually.

TWAPI provides a comprehensive set of commands for managing both user accounts and groups. Here we only illustrate basic usage through some examples. For details and a full list of command options, refer to the TWAPI documentation.

The commands and their purpose are shown in Commands for user and group management.

We now illustrate basic operations for managing user accounts including

The commands pertaining to groups are very similar to those for user accounts including options and return formats. We therefore do not explicitly illustrate them here.

Security principals, and consequently user accounts as well, are defined in the context of a trusted authority as we discussed earlier. This trusted authority is by default the local system and consequently the commands described here operate on the system where the command is invoked. For example, the get_users command will by default retrieve the list of local user accounts.

However, for most commands, the -system option can be used to target remote systems (and equivalently, a different trusted authority) as well. In particular, when the target system specified is the domain controller, the commands work at the domain level.

We will use domain level accounts for our illustration so we start off by retrieving the name of the domain and the domain controller.

Let us see what accounts are already present in the domain.

Notice the returned accounts include accounts for computers belonging to the domain (just two in our test environment).

When enumerating accounts as above, we could have also retrieved more detailed information about each by specifying the -level option.

Let us now look at creating new user accounts.

We can use the read_credentials command, described later in this chapter, to prompt the user for the name of the new account and the password to be assigned.

A new user account is then created using the submitted name and password. We verify that the new account is indeed included when we enumerate domain accounts.

Additional configuration for the account can be done through the various options to the set_user_account_info command.

We can use the get_user_account_info command to retrieve all fields stored in the account record (except credentials for obvious reasons) and verify the settings are as desired.

Our illustration is done, so we can get rid of the account as we really don’t want it hanging around.

The commands for enumerating group members, get_local_group_members and get_global_group_members are very similar to to the previously discussed enumeration commands for users and groups.

Notice how a global group Domain Admins can be a member of the local group Administrators.

Conversely, we can list the groups that contain a specified account. For example, to list the global groups that an account belongs to

Note that the account vm2admin is an account on the domain controller (and hence contained in the VMAPN domain), and not an account locally defined. Let us try to query for the local system for what local groups it belongs to.

In the first case, we get an error because we have not qualified it with the name of the domain. In the second case, we do not get an error because we have qualified the account name with the name of the domain VMAPN but the returned list is empty. This is because VMAPN\vm2admin is not a direct member of any local group. In the third case, we ask that indirect membership also be checked. Because vm2admin is a member of the global groups Domain Admins and Domain Users which in turn are members of local groups Administrators and Users respectively, these local groups are returned by the third command.

Just to verify the above,

Adding to a local or global group is easily accomplished with add_member_to_local_group and add_user_to_global_group.

Conversely, membership can be cancelled with remove_member_from_local_group and remove_user_from_global_group respectively.

The get_account_rights command will list the privileges and rights assigned to a trustee.

Notice that the Administrator account does not have any privileges or rights assigned. It is however a member of the Administrators group from which it inherits the privileges that allow system administrative tasks to be carried out.

Conversely, we can find out which trustees hold a specific privilege. So to find out which trustees are permitted to impersonate other users,

Assigning and removing privileges from trustees is straightforward with the add_account_rights and remove_account_rights command. We illustrate this on our test domain controller.

You can map privilege names to the internally stored LUID’s and back using the commands map_privilege_to_luid and map_luid_to_privilege

When programming in Tcl, you rarely need to use LUID’s directly. They are described here in case you run across them in other documentation or programs that deal with privileges.

That is all we will discuss about privileges for now. We will have more to say about their use after we introduce security contexts and process tokens later in this chapter.

We start off by examining some basic information stored in a token. A token is a kernel object and cannot be accessed directly. Rather, to do anything with a token, we first need to obtain a handle to it with the open_process_token call.

This gives us a handle to the primary token for the process running our Tcl shell. We could have also opened a token for some other process or thread to which we have access rights by providing its process or thread ID.

You can also create a new token and retrieve a handle to it. This is accomplished through the open_user_token call which we will work with in the [chap_processes] chapter.

The capabilities of a token are based primarily on the security principal and groups it represents so we begin by examining these.

The get_token_info and get_token_stats commands can be used to examine the token contents. In many cases, there are equivalent commands that will provide values of individual fields.

Listing the groups in the token is slightly more complicated because associated with each group are attributes that describe characteristics of the group and how it can be used.

The groups included in the token come from multiple sources.

The only group attribute we discuss here is use_for_deny_only id_security_deny_only_group attribute. This marks the group as a deny-only group which means it is only considered for access control rules that disallow access to resources. This is explained further in Discretionary Access Control. We shall also discuss why the Administrators group is specifically marked deny-only in [sect_security_uac].

Every token has a LUID that uniquely identifies it in the system. This is shown as the field ludi in the output below. Any time a token is created, including through duplication of an existing one, the newly created token gets a new LUID. In addition, a separate field modificationluid exists that allows us to track when a token has been modified. This field is changed by the system whenever any call is made that modifies the token.

Note how luid is unchanged but the modificationluid is different after every modification to the token. (We will look at enable_token_privileges in just a bit.)

The type of the token, primary or impersonation, is returned by the get_token_type command.

The logon session owning the token can be retrieved either with get_token_info or get_token_statistics. In the latter case, the authluid key holds this information.

This can be used to find if two processes belong to the same logon session or not.

The privileges assigned to a user account along with those assigned to any groups to which it belongs are stored as part of the token. This is one area where privileges are account rights differ. The token only stores the former, not the latter. This makes sense because account rights only deal with logons and by the time a token is created the logon has already taken place.

To prevent inadvertent use of privileges, they are stored in the token as enabled or disabled. If a Windows API call requires a privilege, that privilege must be present in the token of the caller and must be enabled.

The list of enabled privileges can be retrieved with get_token_privileges.

Specifying the -all option will return two lists - the first containing enabled privileges and the second containing privileges that are present in the token but disabled.

To make a Windows call that requires one or more privileges, the privileges must be enabled before the call is made. Moreover, recommended security practices require that the privileges be disabled afterward when no longer needed.

The commands enable_token_privileges and disable_token_privileges can be used for this purpose. However, for the usual case where a process is enabling its own privileges, it is more convenient to use the functions enable_privileges and disable_privileges as these take care of obtaining and releasing the required token.

Whichever you use, there are two finer points to be aware of when enabling and disabling privileges with the goal that the enabled privileges in the token after the enable/disable sequence must be exactly the same as before.

Both enable_privileges and disable_privileges help dealing with this latter point by returning a list of privileges that actually changed state as a result of the call. These can then be passed to the complementary call to return the token to its exact previous state (in terms of privileges).

The general recommended pattern is then similar to the following.

This pattern is common enough that there is a command — eval_with_privileges — specifically geared towards it. The above sequence would be replaced by

which is a more convenient interface.

Once you are done using a token, you must close its handle with close_token.

We are now ready to tackle the core of this chapter — controlling access to resources.

Access rights are associated with specific operations, or sets of operations, on a resource. When a thread requests a handle to a resource, it passes in a list of access rights that it desires based on the operations it wants to invoke. Conversely, the security descriptor associated with the resource stores the access rights that it is prepared to grant to different trustees. The operating system matches the two along with the requesting thread’s security context which holds the trustee on whose behalf it is executing and decides whether a handle with the desired access should be granted.

The system defines certain access rights that apply to all resource types. These are called standard rights. In addition, each resource type has its own set of access rights defined that only make sense for that type. These are called specific rights.

The standard rights applicable to all resource types are shown in Standard rights.

We will expand on some of the above descriptions as we go along but for now do not be mislead by the terminology. For example, the standard_rights_read right does not pertain to reading a file content; it refers to reading the file’s security descriptor.

Specific rights, which depend on the resource type, are shown in Specific access rights. The semantics are not described but for the most part should be obvious from the name. Otherwise, refer to the Windows SDK.

Now that we know all about trustees and access rights, we are ready to discuss the basic unit of access control - the Access Control Entry (ACE).

An ACE maps a single trustee (which may be a group) and a set of access rights to an allow or deny action. There are many other action types as well but we will just deal with these, which pertain to discretionary access control, for now. Two others, audit and mandatory_label, we discuss later in this chapter while the others pertain only to Active Directory objects and are therefore described in [chap_adsi].

An Access Control List is an ordered list of ACE’s each of which, as we saw above, maps a single trustee and a set of rights to an allow or deny action.

Protecting a resource generally involves setting rules for multiple combinations of trustees and rights. A single ACE is therefore insufficient for the purpose and therefore what is attached to a resource is an access control list (ACL) which is an ordered list of ACE’s each of which deals with a combination of trustee and access rights of interest.

As we shall see, ACL’s are involved in all three aspects of access control:

Both these ACL’s are attached to the security descriptor for a resource. As an example, here is the DACL attached to to our drive’s root directory.

Let us now look at how Discretionary Access Control (DAC) and its implementation in more detail. As we stated earlier, DAC refers to definition of a set of rules that control the specific types of access allowed to a resource by different security principals based on access rights. These rules are stored in the security descriptor in the form of a Discretionary Access Control List (DACL). When a request is made to access a resource on the behalf of a security principal, the system makes the following sequence of checks to determine whether access should be allowed.

In our example above, all ACE’s in the DACL are of type allow. When an access is attempted, if the requested rights are not covered by these ACE’s for the requesting security principal, the request will be denied though there is no explicit deny ACE in the ACL.

There are some special cases that are not dealt with in the above description of access checking. We describe these below.

Each resource is associated with an owner trustee. In Windows versions prior to Vista, if the requester is the owner or belongs to a group that is the owner, checks for the READ_CONTROL and WRITE_DAC rights are passed independent of the DACL contents. Again, other requested rights must be still passed by the DACL checks for the request to be granted.

This behaviour has changed starting with Windows Vista wherein it is now possible to control the resource owner’s ability to read the security information and modify the DACL by adding an appropriate ACE to the DACL. This ACE should use the new built-in OWNER RIGHTS SID S-1-3-4 in conjunction with the READ_CONTROL and/or WRITE_DAC access rights. For example,

Including the above ACE in the security descriptor DACL for the resource will prevent even the owner from modifying the DACL.

If the requester holds the SeTakeOwnershipPrivilege, a check for the WRITE_OWNER access right is always passed irrespective of the DACL. Of course, any other rights requested still go through the DACL access checks. Being able to change the ownership of a resource is important, for example if the original owner leaves the company.

Note the previous discussion of owner rights has no effect for this.

If the request includes the ACCESS_SYSTEM_SECURITY right, the requester must hold the SeAuditPrivilege. Otherwise, the request is denied even if the DACL contents allow it.

If the SID in an ACE of type allow is that for a deny-only group, that ACE is ignored. Deny-only groups are intended to be used only to restrict access and therefore should not be used in ACE’s to permit access. The system therefore ignores such ACE’s. We will see an example of their use in [sect_security_uac].

Windows Vista introduced support for Mandatory Integrity Control (MIC) which is an additional access control mechanism orthogonal to the discretionary access control we have discussed earlier with DACL’s. In a nutshell, this mechanism associates a levels of ''trust'' with each resource and process and prevents ''less trustworthy'' processes from accessing resources that are marked as to be accessed only from "more trusted" processes.

The access rules implementing MIC are checked before those for DAC. Only if the MIC checks allow access does the system go on to check DACL’s. Otherwise, access is denied.

MIC works as follows:

The rest is just details about how integrity levels and MIC rules are stored.

So far we have described how access control is implemented in terms of ACE’s and ACL’s ''attached'' to secured resources and objects through security descriptors. We now describe this in further detail.

A security descriptor is associated with a resource and ties together various information that controls access to the resource including

The subsystem or application implementing the resource is responsible for maintaining the association between the resource and its security descriptor. For example, the NTFS driver will maintain this for files and directories on NTFS systems.

We start off by looking at the contents of a security descriptor.