What's New for Access Control in Windows Server 2008
Applies To: Windows Server 2008
Access control is the process of authorizing users, groups, and computers to access objects on the network by using permissions, user rights, and object auditing.
Access control user interface
To support User Access Control (UAC), the access control user interface (UI) now permits users to elevate permissions in order to edit access control lists (ACLs) on objects they might not have the required user rights to view or change. UAC will request the elevated credentials or consent to continue, and upon successful submission of credentials or consent, the access control UI will perform as in earlier versions of Windows.
Additional resources for the access control UI
TrustedInstaller SID
In the Windows Server® 2008 and Windows Vista® operating systems, most of the operating system files are owned by the TrustedInstaller security identifier (SID), which is the only SID that has full control over them. The purpose is to prevent a process that is running as an administrator or under the LocalSystem account from automatically replacing the operating system files. To delete an operating system file, you need to take ownership of the file and then add an access control entry (ACE) on the file that permits you to delete it. This helps protect against a process that is running as LocalSystem and has a System integrity label; a process that has lower integrity should not be able to elevate itself to change ownership. Some services, for instance, can run with medium integrity, even though they are running as LocalSystem. Such services cannot replace system files, thereby preventing an exploit that takes over a service from replacing operating system files.
Additional resources for protected processes
Restricted SIDs checks
The Restricted SID is not new in Windows Server 2008 and Windows Vista, but the access checks based on the token are more significant. A Restricted SID denotes any process that presents a restricted token. A restricted token has one or more restricting SIDs (SIDs that are used in a separate access check). When restricting SIDs are present, Windows performs two access checks: first is the normal access check, and then the second access check performs the same access check but only against the restricting SIDs in the token. Both access checks must pass to allow the process to access the object.
Additional resources for the Restricted SIDs checks
File system namespace modifications
The file system namespace has been significantly modified in Windows Server 2008 and Windows Vista. User data is now in C:\Users, and other files and folders in the C:\Documents and Settings\<Username>\ namespace have also moved. This helps to separate document files and data files. Rather than storing all data files in the My Documents folder, developers can now create their own folders under the user's profile, which will be available to the user. Application data files for all users are now in a hidden folder named %systemroot%\ProgramData instead of under Documents and Settings\All Users\Application Data.
Default permissions changes
The following table describes default permissions differences between Windows Server 2003 and Windows Server 2008.
| Access control entry | Permissions in Windows Server 2003 | Permissions in Windows Server 2008 |
|---|---|---|
BA (BUILTIN\Administrators) |
BA inherited by containers and objects Grants full access to the root Grants Generic All (GA) |
BA not inherited Grants full access to the root Grants GA Inherit-Only (IO) inherited by containers and objects and grants GA |
SY (LocalSystem) |
SY inherited by containers and objects Grants full access to the root Grants GA |
SY not inherited Grants full access to the root Grants GA IO inherited by containers and objects and grants GA |
WD (Everyone) |
Functionally identical to BU |
Removed |
AU (Authenticated Users) |
Guest account can create files in the root |
Guest account disabled by default This means the Guest account cannot create files in the root; to compensate, Create Files and Create Folders permissions are granted to AU |
BU (BUILTIN\Users) |
Guest account can create files in the root |
To allow the Guest account to read and execute files, the Read and Execute ACE remains granted to BU |
The permissions granted to subfolders created under the root by users, including Guests, are controlled solely by the (A;OICIIO;SDGXGWGR;;;AU) ACL. Rather than granting Full Control permission to the creator of subfolders, in Windows Server 2008 and Windows Vista, this ACL grants Modify permission to authenticated users.
The result of this new ACL is that the creator of an object no longer has any special rights and the Authenticated Users group has Modify permission even on subfolders that are created by administrators.
In Windows Server 2008 and Windows Vista, everyone—including the Guest user—can read and execute files in the root. Only authenticated users can create new files and folders, and when users do, they get Modify permissions on those files and folders.
Changes to tokens
When a user who is a member of the Administrators group in Windows® XP or Windows Server 2003 logs on to a computer, that user's token contains the Administrators group SID, and the user has the same permission as the Administrators group. In Windows Server 2008 and Windows Vista, if UAC is enabled, the Administrators SID is still present in the token but is set to Deny only. When performing access control, such an entry in the token is used only to deny access—in other words, to match Deny ACEs. Any Allow ACEs for that SID are ignored. That means that you are not truly an administrator all the time, even if you log on to the computer as one.
If UAC is disabled, then a user who is a member of the Administrators group has a token containing the Administrators group SID.
Note
The Built-in Administrator account is enabled by default in Windows Server 2008. The Admin Approval Mode that UAC uses is disabled for this account.
Integrity levels
Windows now supports the labeling of processes and objects with integrity levels. These integrity levels are represented as ACEs in the system access control list (SACL), with a few special flags. For example, the flag NW is used to denote the blocking of a process at a lower integrity level from writing to an object at a higher integrity level (SDDL_NO_WRITE_UP).
Additional resources for integrity levels
Icacls command-line tool
Icacls replaces Cacls as the ACL command-line tool. Icacls provides the following functionality on securable objects:
Saving and restoring ACLs
Replacing permissions for one user with permissions of a different user
Changing object ownership
Finding files for a particular user
Resetting and changing ACLs
Setting integrity levels
Additional resources for the Icacls command-line tool
OwnerRights SID
In earlier versions of Windows operating systems, the owner of a securable object (represented by the Owner SID field in the security descriptor) always had the READ_CONTROL and WRITE_DAC rights implicitly granted. WRITE_DAC is a powerful right that can be used to change the access control policy. In Windows Server 2008 and Windows Vista, a new SID called OwnerRights can be used in ACEs to control these rights on securable objects.