Active Directory Logical Structure |
Authentication of user accounts determines that a user who logs on to a Windows 2000 domain is who the user claims to be and that the user does indeed have an account either in the domain or in a domain that is trusted. After the user is authenticated, however, Active Directory must provide security (authorization) to determine what objects the authenticated user can view or change and what kinds of changes are allowed. This type of security is achieved through access control.
Note
The information presented here is provided as a security overview in the context of understanding basic Active Directory functionality. For more information about Active Directory security, see the chapters under "Distributed Security" in this book.
All Active Directory objects are protected by an ACL. ACLs determine who can see the object and what actions each user can perform on the object. The existence of an object is never revealed to a user who is not allowed to read it.
An ACL is a list of access control entries (ACEs) that are stored with the object that the ACL protects. In Windows 2000, an ACL is stored as a binary value within a security descriptor. Each ACE contains a security identifier that identifies the security principal (the user or group) to whom the access control entry applies and also information about what type of access the access control entry grants or denies.
ACLs on Active Directory objects contain ACEs that apply to the object as a whole and ACEs that apply to the individual properties of the object. This structure allows an administrator to control not only which users can see an object but also what properties the users can see. For example, all users might be granted read access to
For more information about access control, see "Access Control" in this book. For more information about built-in object security, see "Active Directory Data Storage" in this book. For information about anonymous read access, see "Name Resolution in Active Directory" in this book.
Delegation is one of the most important security features of Active Directory. Delegation allows a higher administrative authority to grant specific administrative user rights for containers and subtrees to individuals and groups. Delegation eliminates the need for domain administrators to have sweeping authority over large segments of the user population.
ACEs can grant specific administrative rights on the objects in a container to a user or group. Rights are granted for specific operations on specific object classes through ACEs in the container's ACL. For example, to allow the user James Smith to be an administrator of the Corporate Accounting organizational unit, you add ACEs to the ACL on Corporate Accounting as shown in Table 1.2.
Table 1.2 Example of ACL Contents on an Organizational Unit
ACE |
Security Principal |
Right |
Applied to These Objects |
---|---|---|---|
Allow | James Smith | Create, Delete User objects | This object only |
Allow | James Smith | Full control | User objects |
Allow | James Smith | Create, Delete Group objects | This object only |
Allow | James Smith | Full control | Group objects |
Allow | James Smith | Set Password | User objects |
Now James Smith can create new users and groups in Corporate Accounting and set the passwords on existing users, but he can neither create any other object classes nor affect users in any other containers (unless, of course, he is granted that access by ACEs in the other containers).
For more information about delegation of administration, see "Access Control" in this book. For information about how to apply delegation, see Windows 2000 Server Help.
You use inheritance to propagate a particular ACE from the container where it was applied to all objects within the container. Inheritance can be combined with delegation to grant administrative rights to a whole subtree of the directory in a single operation. For more information about inheritance, see "Access Control" in this book.