Access control lists may report incorrect information in Windows Server 2003
To create the new security group, follow these steps:
- Click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
- Expand DomainName, right-click Users, point to New, and then click Group.
- Type a name for your group in the Group name box, click to select either Domain local or Global in the Group scope box, click to select Security in the Group type box, and then click OK.
- In the right pane of the Active Directory Users and Computers snap-in, double-click the domain local security group that you just created.
- On the Members tab, click Add.
- Type the following in the Enter the object names to select (examples) box, and then click OK two times: domain admins;enterprise admins
The Administrators group in the domain is implemented as a BUILTIN\Administrators group on a domain controller and has a well-known SID of S-1-5-32-544. The local BUILTIN\Administrators group on any member server or workstation also has an SID of S-1-5-32-544.
When Windows Server 2003 calculates the effective permissions of an object, it matches the ACL of the object that is obtained from a domain controller with the SIDs of groups where the user is a member. These group SIDs are obtained locally. If the object ACL contains an SID of S-1-5-32-544 for Administrators group in the domain, and the user is a member of a local Administrators group, Windows Server 2003 cannot distinguish between the two accounts.
This problem is also true in reverse. If the user is a member of Administrators group in the domain and is not the member of local Administrators group, Windows Server 2003 does not show the correct list of permissions. This problem occurs because the group expansion is always performed locally. A computer that is not a domain controller or that is a workstation cannot expand a local group on the domain controller.
In Windows Server 2003 Forest Mode and later versions of the Windows operating system, the session implements the access check for users by using a Kerberos S4U request. This access check implementation makes the session work much faster because the SIDs are collected as if they were collected from an actual logon. But this access check implementation also makes the resultant list of SIDs relative to the computer and to the user who is running the session. If you now run the session remotely, the results are incorrect because built-in or local groups change the results.
Article ID: 884049 - Last Review: 04/18/2008 18:35:55 - Revision: 4.0
- kbnofix kbpermissions kbadmin kbaccounts kbtshoot kbbug kbprb KB884049