Every object under NT's purview has an Access Control List that determines which users or groups can access that object, and the specific actions on that object the operating system will allow. NT management utilities and documentation refer to these access controls as permissions. Examples of controlled objects are file system subdirectories, files, and printers. Examples of permitted actions are reading, executing, writing, and deleting for subdirectories and files; and submitting or removing print jobs from the queue for printers. In addition, these objects may or may not be containers. Container objects, such as subdirectories, hold other objects, such as files and subsidiary directories, and the held objects inherit the security attributes of the container objects. Thus, for example, NT allows the administrator to restrict a subdirectory and all the files and subdirectories within it to read-only access for a given group of users. However, file object security applies only for the NT File System (NTFS), not for the older MS-DOS and Windows File Access Table (FAT) file system. NT also supports FAT-based file systems, but can only apply security attributes to drive shares, not to individual files or directories. The Access Control Lists themselves contain three types of Access Control Entries: AccessDenied, AccessAllowed, and SystemAudit. Each Access Control Entry is actually a Security Identifier of a user or group, along with an associated access mask. The AccessDenied Access Control Entry denotes that the Security Identifier cannot access the object with specific rights defined in the access mask. The AccessAllowed Access Control Entry gives the Security Identifier the specific access rights. The SystemAudit Access Control Entry defines which security events will be logged (more on auditing later in this report). An object may have any number of Access Control Entries of each of these types. When a user requests access to a controlled object, NT's Security Reference Monitor checks the Security Identifiers in the user's Security Access Token against the Access Control Entries in the object's Access Control List. It starts with any AccessDenied Access Control Entries and then checks for any AccessAllowed Entries. If any of the Security Access Token Security Identifiers match any of the AccessDenied entries, the system immediately denies the user any access to the object. It then stops checking the Access Control Entries, although the user may also have full access to the object through an AccessAllowed entry. For example, if the administrator gives the group Everyone the No Access permission to a share, then even Domain Administrators can't access the share, even if they are listed on an AccessAllowed entry. All users, including all Domain Administrators, are members of the group Everyone, and the administrator has denied access to the group. Thus, the AccessDenied entry overrides any and all AccessAllowed entries. (However, the share owner still has the right to change permissions and thereby remove this AccessDenied entry.) If the user's Security Access Token hasn't encountered a matching AccessDenied entry, then the Security Reference Monitor checks as many of the AccessAllowed entries as necessary to assemble all the access rights the user (or more usually the application invoked by the user) has requested. In requesting access to an object, the user declares which specific rights he or she needs. Each AccessAllowed entry, through its included rights mask, may grant one or more of these requested rights. Once the Security Reference Monitor finds enough AccessAllowed entries to grant the user all the specific rights he or she requested, the user gains access to the object. If the Security Reference Monitor exhausts the list of AccessAllowed entries without finding one of the Security Access Token's Security Identifiers or without finding all the requested rights, the user doesn't get any access to the object. It's all or nothing. For example, user Fillmore, who is a member of the Everyone and Presidents groups, asks to open a file with read, write, and delete privileges. In checking the file's Access Control List, the Security Reference Monitor finds an AccessAllowed Access Control Entry with Fillmore's Security Identifier and with read and write in its access mask. It finds another AccessAllowed entry with the Presidents group Security Identifier and with read and delete in the access mask. Since Fillmore has both Security Identifiers in his login Security Access Token, and since the two Access Control Entries combined provided all the access rights Fillmore asked for, he gets access to the file. If Fillmore hadn't been a member of the Presidents group, he wouldn't have obtained any access. Administrators (and users with proper authority) can set and change Access Control Lists through the Permissions option in the Properties dialog box associated with each object displayed in NT Explorer. Users and applications can also change permissions though command line tools, and applications can alter permissions programmatically.
|
|
|
|
|
|
|
|