Once the user (or computer) is successfully authenticated, an
access token is created containing the user's security identifier (or SID), the groups they belong to, and the privileges they possess, among other security related items. You can see a particular listing of your access token by typing
Whoami /all at a command prompt (see
Figure 1).
When the user attempts to access a Windows resource or object, their effective access is determined by the common points between the values and memberships in their access token and the resource's access control permissions .
Share Versus NTFS Permissions
Windows file sharing has two types of permissions: Share and NTFS. If the user is connecting to a remote computer over an SMB share, Share permissions apply in addition to file system permissions, and the user must have the requisite access in both places for the access to succeed. Actually, Share permissions apply even if accessing the local computer using a SMB share (although that would be strange and unnecessary). Share permissions can be set on folders and printers (but cannot be set at the file level), and are available on both FAT and NTFS partitions.
NTFS permissions apply to every object on an NTFS partition (file, folder, printer, registry key, and so on), and apply whether the user is accessing a local or remote resource. NTFS permissions even apply to objects accessed using other methods besides SMB. For example, files and objects accessed through IIS are protected with NTFS permissions if stored on an NTFS-formatted partition. The remote user, accessing IIS using the WWW service or using FTP, is bound to the NTFS permissions set by the web administrator. In contrast, Share permissions do not apply on files accessed outside of SMB shares.
Impersonation Versus Delegation
Any time a user accesses an object that is protected by Windows security, it must do so through a Windows process, whether that is an application or a service. For instance, the user never directly accesses a file. File access is always through a program, such as Windows Explorer, Microsoft Office, or some other application or service-even the Command Prompt is an application. The process accessing the object on the user's behalf often acts as the user, and we say that its primary token is the same as that of the user.
Other programs-some servers, for instance-will receive credentials from the user, in the form of a password or an SSL certificate exchange, and use these credentials to impersonate the user. An impersonation token is different from a primary token and is not able to be used to create a new process as the impersonated user.
Since impersonation requires that the user present credentials to the process, which is generally a remote process, it is under the user's control as to which processes are trusted to impersonate that user.
Delegation, by comparison, is a method by which a process can claim to be a user without presenting any identifying credentials and without being initiated by the user. Delegation is often used by web servers in situations where the user can be recognized to the web server's satisfaction without providing entire Windows logon credentials.
Delegation is controlled by marking a system as Trusted for Delegation and should be carefully limited to servers that you trust to identify users and act on their behalf-a server trusted for delegation could claim to be a Domain Administrator, for instance.
There are some actions that positively require the use of a password-decrypting files protected by EFS, for instance, is governed by a private key that is encrypted using a key derived from the user's own password. If you do not know the user's password, you cannot use the user's private keys, and you cannot decrypt files on behalf of the user. (You are able to give the raw, encrypted bytes to the user's process, for that process to decrypt with the user's key-that may look as if the server is decrypting the EFS file without access, but the decryption is really done locally.)
Integrity Controls
Vista introduces the concept of mandatory integrity controls to Windows. Every user account, file, object, application, and process in Windows has an integrity level. Integrity levels are:
Most users and objects have a Medium integrity level. Even members of the Administrators group, who are not the true Administrator, only have Medium integrity when not elevated. The real Administrator has High integrity. Most Windows services and kernel mode programs run with System integrity. Internet Explorer in Protected mode runs with Low integrity. Any object without an integrity level is automatically treated as having Medium integrity.
Actually, there are at least two other integrity levels used by Vista, but rarely seen: Anonymous and Protected Process. The Anonymous integrity is assigned to anonymous null session connections. This makes unauthenticated connections less of a threat than they were in previous Windows versions. Protected Process integrity is used by the system for integrity needs beyond System.
Child processes or objects created by a parent process or object normally gets assigned the same integrity process of the parent. User or objects of lower integrity cannot write to objects of higher integrity, no matter what their NTFS or Share permissions are. Users or objects can write to objects or processes of the same or lower integrity, if their assigned NTFS permissions also allow it.
Integrity levels can be viewed by using the new Icacls.exe command-line program. Initially, Microsoft wants integrity levels to be used to prevent unauthorized writes, but mandatory integrity controls can also be used to prevent Reads and Executions programmatically.
The net result of integrity controls is that users, even Administrators, will have a harder time modifying system files and processes. Programs and malware arriving via Internet Explorer running in Protected mode (i.e. Low integrity) will have an even harder time manipulating everything else in Windows (not marked with Low integrity). This should reduce the number of malware programs that silently modify and infect Windows through Internet Explorer. Integrity controls are yet another defense-in-depth control that Microsoft has added to Windows.
Items of lower integrity cannot modify items of higher integrity, regardless of the Share or NTFS permissions.
