Partager via

Access control in Active Directory

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Access control in Active Directory

Administrators can use access control to manage user access to shared resources for security purposes. In Active Directory, access control is administered at the object level by setting different levels of access, or permissions, to objects, such as Full Control, Write, Read, or No Access. Access control in Active Directory defines how different users can use Active Directory objects. By default, permissions on objects in Active Directory are set to the most secure setting.

The elements that define access control permissions on Active Directory objects include security descriptors, object inheritance, and user authentication.

Security descriptors

Access control permissions are assigned to shared objects and Active Directory objects to control how different users can use each object. A shared object, or shared resource, is an object that is intended to be used over a network by one or more users and includes files, printers, folders, and services. Both shared objects and Active Directory objects store access control permissions in security descriptors.

A security descriptor contains two access control lists (ACLs) used to assign and track security information for each object: the discretionary access control list (DACL) and the system access control list (SACL).

  • Discretionary access control lists (DACLs). DACLs identify the users and groups that are assigned or denied access permissions on an object. If a DACL does not explicitly identify a user, or any groups that a user is a member of, the user will be denied access to that object. By default, a DACL is controlled by the owner of an object or the person who created the object, and it contains access control entries (ACEs) that determine user access to the object.

  • System access control lists (SACLs). SACLs identify the users and groups that you want to audit when they successfully access or fail to access an object. Auditing is used to monitor events related to system or network security, to identify security breaches, and to determine the extent and location of any damage. By default, a SACL is controlled by the owner of an object or the person who created the object. A SACL contains access control entries (ACEs) that determine whether to record a successful or failed attempt by a user to access a object using a given permission, for example, Full Control and Read.

    For more information about auditing, see Auditing settings on objects.

To view DACLs and SACLs on Active Directory objects using Active Directory Users and Computers, on the View menu, click Advanced Features to access the Security tab for each object. For more information, see Assign, change, or remove permissions on Active Directory objects or attributes. You can also use the DSACLS support tool to manage access control lists in Active Directory. For more information, see Active Directory support tools.

By default, DACLs and SACLs are associated with every Active Directory object, which reduces attacks to your network by malicious users or any accidental mistakes made by domain users. However, if a malicious user obtains a user name and password of any account with administrative credentials to Active Directory, your forest will be vulnerable to attack. For this reason, consider renaming or disabling the default administrator account and following the best practices as described in Active Directory Best practices.

Object inheritance

By default, Active Directory objects inherit ACEs from the security descriptor located in their parent container object. Inheritance enables the access control information defined at a container object in Active Directory to apply to the security descriptors of any subordinate objects, including other containers and their objects. This eliminates the need to apply permissions each time a child object is created. If necessary, you can change the inherited permissions. However, as a best practice, avoid changing the default permissions or inheritance settings on Active Directory objects. For more information, see Best practices for assigning permissions on Active Directory objects and Changing inherited permissions.

User authentication

Active Directory also authenticates and authorizes users, groups, and computers to access objects on the network. The Local Security Authority (LSA) is the security subsystem responsible for all interactive user authentication and authorization services on a local computer. The LSA is also used to process authentication requests made through the Kerberos V5 protocol or NTLM protocol in Active Directory. For more information about Kerberos authentication, see Kerberos V5 authentication. For more information about NTLM authentication, see NTLM authentication.

Once the identity of a user has been confirmed in Active Directory, the LSA on the authenticating domain controller generates a user access token and associates a security ID (SID) with the user.

  • Access token. When a user is authenticated, LSA creates a security access token for that user. An access token contains the user's name, the groups to which that user belongs, a SID for the user, and all of the SIDs for the groups to which the user belongs. If you add a user to a group after the user access token has been issued, the user must log off and log on again before the access token will be updated.

  • Security ID (SID). Active Directory automatically assigns SIDs to security principal objects at the time they are created. Security principals are accounts in Active Directory that can be assigned permissions such as computer, group, or user accounts. Once a SID is issued to the authenticated user, it is attached to the access token of the user.

The information in the access token is used to determine a user's level of access to objects whenever the user attempts to access them. The SIDs in the access token are compared with the list of SIDs that make up the DACL for the object to ensure that the user has sufficient permission to access the object. This is because the access control process identifies user accounts by SID rather than by name.

Important

  • When a domain controller provides an access token to a user, the access token only contains information about membership in domain local groups if the domain local groups are local to the domain controller's domain. For domain directory objects replicated in the global catalog, this fact requires certain security considerations. For more information, see Global catalog replication.

For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site.

For more information about access control and permissions, see Access control overview. For more information about authorization and access control, see "Authorization and Access Control" at the Microsoft Windows Resource Kits Web site.

For information about additional security measures that can be implemented to protect Active Directory, see Securing Active Directory and Security information for Active Directory.