INFO: Limitations of the GetEffectiveRightsFromAcl API (262278)

MORE INFORMATION

Access Control in Windows 2000 and Windows NT depends on a logged on user who has an access token. An access token is created for a user when the user logs on. The user's access token contains the user's security identifier (SID), and a list of SIDs corresponding to groups the user is a member of. Some of the group SIDs do not correspond to an actual security group in Active Directory or a Security Accounts Manager (SAM) Database; instead they represent properties of the method of logon. The "groups" these SIDs represent are often called pseudo-groups because, similar to security groups, their SIDs are inserted into an access token, but no corresponding security group actually exists. For example, a pseudo-group SID may be present in an access token for a group called "INTERACTIVE" that does not exist in Active Directory or a SAM database. This SID is present in an access token when the user's logon type is INTERACTIVE. By inserting a SID for the interactive pseudo-group in an access token, Windows can support a finer-grained Access Control. Access to an object whose DACL contains this SID is different for a given user depending on how the user is logged in (whether or not the INTERACTIVE pseudo-group's SID is present in the user's access token.) Therefore, accurate access checks require an access token.

GetEffectiveRightsFromAcl tries to determine access for a given user without an access token by examining the specified DACL for the specified user's SID and for the SIDs of any group that the user account is a member of. Because pseudo-groups do not exist in Active Directory or a SAM Database, GetEffectiveRightsFromAcl must ignore ACEs that grant or deny access to pseudo-groups. This means that the access reported by GetEffectiveRightsFromAcl is incomplete compared to the access the user would have if they were actually logged on.

Furthermore, Access Control is subject to user rights and privileges. If a user does not have the "Log on locally" or "Access this computer from the network" user rights, then the user cannot log on, and cannot access any securable object on the system. In this situation, because no access token is used, GetEffectiveRightsFromAcl can still report that the user has access rights to the object. Additionally, certain privileges can override Access Control. For example, users who have the "Back up files and directories" privilege can open an object with READ_CONTROL access, even though the DACL on the object may not grant READ_CONTROL access to those users. GetEffectiveRightsFromAcl cannot account for a user who has such a privilege, and will not report these privileges based access rights when not present in the DACL.

Due to these limitations, the GetEffectiveRightsFromAcl API should not be used except for situations where you can be certain that the context is such that any overriding user rights or privileges are not pertinent, and the target object is not secured by granting or denying access to any pseudo-groups. Generally, accurate access information for a given user and securable object can only be retrieved through the AccessCheck function, which requires an access token for the user logon.