Export (0) Print
Expand All

What's New for Access Control in Windows Server 2008

Updated: March 16, 2011

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.

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.

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.

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.

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.

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.

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.

noteNote
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.

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).

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

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.

See Also

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft