Get a glimpse inside Paul Cooke's e-book "The definitive guide to Windows 2000 security" with this series of book excerpts, courtesy of Realtimepublishers.com. This excerpt is from Chapter 5, "Configuring access control." Click for the book excerpt series or get the full e-book.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
When you look at Windows 2000, there is only one right that is universally true: The right to either allow or deny access to any resource that you own. This truth is the essence of DAC, as I explained in "Discretionary Access Control" earlier in this chapter. Although DAC makes sense, I haven't really addressed the basic issue of what a right is. For our purposes, a right is the authorization to perform some operation. If you'll recall from my initial discussion of access control in Windows 2000, authorization is an integral part of providing access control, so the concept of access rights is very important. In Windows 2000, two types of access rights are implemented: access permissions and user rights.
A permission is a specific right that gives a security principal the authorization to perform some operation on an object. You can set permissions on, for example, files, folders, and AD objects. One of the more important things to realize about permissions is that if access isn't explicitly granted, it's automatically denied. (From a security perspective, this arrangement is the way you want things to work. Think what would happen if the opposite was true, and access was automatically granted unless it was explicitly denied. You'd have to spend all your time modifying authorizations for your resources, trying to prevent certain people from accessing the resources you own!) Windows 2000 also lets you explicitly deny access to a resource.
Permissions are implemented in Windows 2000 as one or more ACEs. For each securable object, the ACEs are collected into what is known as an ACL. I'll describe both ACEs and ACLs in detail a little later in this chapter (see "ACLs"), but here, it's important to link the concept of permissions with the implementation of ACLs and ACEs.
Before talking in more detail about some of the different kinds of permissions, I want to talk briefly about the three types of permissions you'll encounter as you manipulate authorizations in Windows 2000:
- Inherited: Flow from higher-level objects to lower-level objects. Inherited permissions are so important that I'll cover them later in this chapter (see "ACE Inheritance").
- Explicit: Augment or replace inherited permissions on an object.
- Protected: Cannot be inherited by child objects; only explicit permissions exist. Child objects that have permissions that aren't consistent with permissions inherited from a parent are protected by explicit permissions, and the inherited permissions aren't applied.
One last generic point: The granularity of authorizations has been greatly extended in Windows 2000 to cover not only an object but also the attributes of an object. As a result, you can allow a group of administrators to do nothing but reset user passwords. This granularity works because each attribute of an AD object can have its own ACL; there isn't just a single ACL for the entire object.
Click for the next excerpt in this series: NTFS permissions
Click for the book excerpt series or get the full e-book.