Article ID: 884049 - View products that this article applies to.
When you are logged on to a Microsoft Windows Server 2003 computer, you view the access control list (ACL) for an object that is contained in the Active Directory directory service. You notice that user accounts that are members of the local Administrators group on the Windows Server 2003 computer appear to have permissions to Active Directory objects.
This problem occurs because the security identifier (SID) for the local Administrators group on a Windows Server 2003 is the same as the SID that is assigned to the Domain Administrators group.
To work around this problem, create a new security group, and then add the Domain Admins and Enterprise Admins groups to the security group. Then, use this new security group instead of the Domain Administrators group when you manage ACLs for Active Directory objects.
To create the new security group, follow these steps:
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
This is a problem with the way that effective permissions appear. There is no effect on how the permissions are applied.
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: April 18, 2008 - Revision: 4.0