Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Access Control Model
A fundamental principle of security is that only authorized entities should be capable of accessing a secured object. Each object in the Active Directory that participates in a security-related process requires a SID. Security-related processes include file or directory access, use of services or resources, or administrative tasks. When a Windows 2000 logon is successful, an access token is generated for the user. The access token includes the user's SID and the SIDs for the security groups the user is a member of. This access token is included in Kerberos session tickets (see the upcoming section "Kerberos Authentication") and used to determine permissions when an attempt is made to access a secured object or perform an administrative task.
In the header of each Windows 2000 security object is a list of security entries called the Discretionary Access Control List (DACL). The DACL contains access control entries (ACE) to identify the users or groups that have been granted access to the object. For example, permissions on a file can be set to exclude all users with the exception of the Accounting group. In this example, the Accounting group SID is included in the ACE with Full Control permissions. When a user attempts to access the file, the SIDs included in the user's access token are compared to the entries in the DACL. If the access token includes the Accounting group SID, full control access is granted for the file. If the Accounting group SID is not included in the user's access token, access to the file is denied.
To set file or folder ACLs in Windows 2000, the file must be located on an NTFS drive. Network shares are also assigned access control entries but are not limited to NTFS drives. For more information on setting access control, reference your Windows 2000 documentation.
Field-Level Security
Unlike earlier versions of Windows NT, the Windows 2000 DACL model extends beyond the object level and allows ACEs on object properties or fields. For example, members of the Telecom department can be granted the capability to edit the phone number field of user objects but have only read or denied access to other properties.
Access control within Exchange 2000 follows the same model as Windows 2000, providing a more comprehensive security solution than previous versions of Exchange. For example, Exchange 5.5 permission granularity was limited to the container level. Administrators responsible for maintaining user account properties in Exchange 5.5 required permissions to the entire Recipients container. By granting permissions at the container level, the administrator gained that level of control on all objects and properties of the Recipients container. Under Exchange 2000, the same Administrator can be granted rights to only specific users or specific properties of user accounts, without the capability to modify or even view other objects or properties.
The Exchange client experience is also enhanced by the extensions to the Access Control Model of Exchange 2000. If a user is denied access to properties in the Active Directory or the Web store, the user will not see those properties when performing a search. This built-in filtering applies to searches for users, groups, and resources located within the Web store such as messages, documents, or files. To further extend field-level security, developers can utilize the Access Control Model extensions for custom workflow and collaboration applications. Field-level security greatly enhances the workflow platform available for Web store application developers.
Inheritance
All objects within the Active Directory belong to a hierarchy and are considered either a parent or a child object, or, in many cases, both. When an object is created, it is assigned the same access control permissions as its parent, or the object directly above it in the hierarchy. This process is known as inheritance and can help simplify the administration of permissions. By using inheritance, permissions do not have to be manually applied for each new child object that is created. In addition, you can modify permissions at a higher level in the hierarchy and choose to have those changes filter down to all child objects.
Inheritance is not new with Windows 2000. In Windows NT, when a file (the child) was created in a directory (the parent), the file was assigned the same permissions as the directory. Windows 2000 inheritance goes beyond file systems resources and is used with objects in the Active Directory.
When viewing permissions in the Active Directory, you will notice that inherited permissions differ from direct permission assignments. Inherited permissions appear grayed out and cannot be removed from an object in Active Directory unless inheritance is disabled for that object.
CAUTION
Disable inheritance with caution! You might not realize why an inherited permission is necessary for the object. In addition, if inheritance is disabled for an object, later changes to the parent will not be adopted by the child.
You will utilize inherited permissions on virtually every aspect of Exchange-related security within the Active Directory and the Web store.