Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Overview of Active Directory Security

JustChapter 11, "Understanding Network Access Security and Kerberos," let's go over the key elements of authentication and authorization in Window Server 2003:

• A security principal is a user, computer, or group that needs to access a resource either on a local computer or on a server.




• The primary means of authenticating a security principal is Kerberos. Legacy NTLMv2 (NT LanMan version 2) and LM (LanMan) authentication is available for supporting downlevel clients.




• Authenticated security principals receive a Privilege Access Certificate (PAC) that contains their security information. The PAC includes the principal's Security ID (SID) along with the SIDs for any groups that have the security principal as a member, the SIDs for groups having those groups as members, a list of system privileges assigned to the user, and a list of account restrictions assigned to the security principal.




• The Local Security Authority (LSA) uses the PAC to construct an access token that is attached to any processes initiated by the security principal.




• Key operating system objects are protected by a special data structure called a security descriptor. The security descriptor contains a Discretionary Access Control List (DACL) that defines who can access the object and what can be done with the object.




• When a process attempts to access a secured object, the Security Reference Monitor (SRM) compares the contents of the DACL with the contents of the access token and the type of access requested by the process and determines the effective permissions to assign to the process.




• Access permissions are evaluated in a canonical manner with Deny permissions evaluated prior to Allow permissions and explicit permissions evaluated prior to inherited permissions.

With all this in mind, let's see how Active Directory makes use of the security subsystem to assign administrative permissions and control access to objects.

Viewing Security Descriptor Contents

You can view the security descriptor for an Active Directory object by opening its Properties window from the associated Active Directory management console. For example, open the AD Users and Groups console and expand the tree to the Users container. Right-click on an object, select P

ROPERTIES from the flyout menu, and then select the Security tab. This opens the ACL Editor to view the security descriptor.

The initial view of the ACL Editor is a generic one showing the security principals that have been placed on the DACL. This list is in alphabetical order. A particular security principal might have several entries in the DACL. A cumulative permissions list is displayed in the lower part of the window when you highlight an entry. Figure 13.1 shows the ACL Editor generic view for a user object.

If additional permissions have been assigned, a listing called Special Permissions has a checkmark. This is your indication that you must use the Advanced view of the ACL Editor to see the full permissions for that security principal. Figure 13.2 shows the ACL Editor Advanced view for the same user object.

The entries in the Advanced view are listed in the order that the SRM evaluates them when determining whether to permit access to a security object. Inherited permissions are identified to distinguish them from explicit permissions assigned directly to the security descriptor. The listing includes the identity of the source container for an inherited permission to aid in troubleshooting.

Effective Permissions Calculator

Windows Server 2003 has a new Effective Permissions calculator that displays the permissions a selected user would get when accessing an object. When you select the Effective Permissions tab and enter a name, the system performs a security evaluation and displays the result in a set of checkboxes. Figure 13.3 shows an example.

Types of Access Rights

In addition to the standard object permissions such as Read, Write, Modify permissions, and so forth, Windows Server 2003 has over 50 extended rights that can be assigned to Active Directory objects. Here are a few examples:

• ChangePDC .
  Gives permission to transfer the Flexible Single Master Operations (FSMO) role of the PDC Emulator.




• GenerateRSoPPlanning . Gives permission to initiate a Resultant Set of Policies (Planning) calculation.




• DomainPassword . Gives permission to reset the password of a user object.

In addition to extended rights, you can assign permissions to individual properties of an object. For instance, let's say you have a developer who has coded an application for the Facilities department that updates certain attributes in Active Directory such as TelephoneNumber and Location. You can use property permissions to give Facilities personnel read/write access to the affected properties in User objects without letting them modify any other property in any other object type.

You can view the permissions assigned to individual properties in the Edit view of the ACL Editor. Figure 13.4 shows an example.

Access Control Inheritance

Inheritance determines whether the Access Control Entry (ACE) affects any child objects and what objects are affected. Normally, an ACE is inherited by all child objects in all subcontainers.

The Edit view of the ACL Editor permits assigning special inheritance rules to an ACE. You have the option of controlling inheritance to an extremely granular level. For example, if you have a set of permissions that you only want inherited by Group objects in a specific container but not in any subcontainers, you can select an inheritance option that accomplishes that goal.

Needless to say, in normal day-to-day operations, you'll never drill down this deep into Active Directory permissions. But it is good to keep in mind that they are available to you if you need to resolve any sticky administrative problems.

Procedure 13.1 is an example that uses the Active Directory Users and Computers console to apply inheritable rights to a test Organizational Unit (OU).

Procedure 13.1 Applying Inheritable Rights to an Active Directory Container

1. Open the AD Users and Computers console.

2. From the menu, select V

   IEW | A

   DVANCED F

   EATURES . This exposes the Security tab for Active Directory objects.

3. Create a test OU to practice on. This prevents you from making an innocent mistake that mangles a production container. Create a couple of User objects under this OU. If this is a production server and your corporate policies prohibit creating user IDs, you can create contact objects. They act the same as User objects but they have no security rights.

4. Right-click the new OU and select P

   ROPERTIES from the flyout menu.

5. Select the Security tab (see Figure 13.5). You'll see a list of access control entries.

   Figure 13.5. Properties page for an example OU showing the Security tab with access control entries.

   

6. Deselect Allow Inheritable Permissions. You'll be prompted to either copy the currently inherited ACE entries as permanent entries in the security descriptor or remove them.

7. Click Remove. The inherited entries disappear. In production, you should always use the Copy Previously Inherited Permissions option. This prevents you from accidentally removing a critical ACE. Having no ACE is the same as having a Deny ACE.

8. Click Advanced. The Access Control Settings window opens.

   Figure 13.6 shows a set of ACE settings for the example OU. Rights associated with Access Allowed ACE entries are cumulative, so a security principal with multiple ACEs gets each right assigned by the ACE after evaluating any Access Denied ACEs.

   Figure 13.6. Access Control Settings window for OU showing the ACE type associated security principal, the type of permission, and the inheritance options.

   

9. Highlight one of the ACE listings and click View/Edit. The Permission Entry window opens. The Apply Onto drop-down box lists the inheritance options that can be associated with the ACE.

10. Close the windows you have open and return to the Active Directory Users and Groups console.

Access Rights Delegation

You can lose a good chunk of your youthful years trying to figure out exactly which set of granular permissions you need to apply to get a desired administrative result, not to mention all the inheritance options you'll have to consider when applying the new permissions.

Windows Server 2003 makes this process a lot simpler with a feature called

delegation . This permits you to select from a menu of administrative options, then let the system decide which permissions to change.

There's a subtle difference between

inheritance and

delegation . Inheritance defines a mechanism for applying changes to child security descriptors based on the contents of a parent's security descriptor. Delegation involves selecting the access permissions that will be inherited. It's something like setting up a beach umbrella. The umbrella casts a shadow (delegation) and you sit in its shade (inheritance).

Delegation can have unexpected consequences. For example, in the novel

Catch 22 , Milo Minderbinder was able to use his delegated authority as a supply officer for a small Air Corps detachment to effectively take over the war effort in Italy. You could have a similar experience if you delegate administrative privileges indiscriminately.

Rather than trying to pick through the nearly 200 different properties associated with users, groups, and computers trying to figure out which ones to assign, and maybe getting some Milo Minderbinder-type consequences, it's much simpler to use the

Delegation of Control Wizard . I'm not generally a fan of all the admin wizards in Windows Server 2003. For the most part, I think they complicate simple chores. But when it comes to assigning administrative rights in Active Directory, the Delegation of Control Wizard is my tool of choice. It consolidates the extensive range of object permissions, extended rights, and property permissions into a concise set of selection windows. You can also use the wizard to select granular permissions if you choose to use them.

Procedure 13.2 shows how the Delegation of Control Wizard works. The example uses an object in the AD Users and Groups console because this is where delegations are most commonly required, but you can delegate permissions on virtually any container in any console.

Procedure 13.2 Delegating Access Rights

1. In the AD Users and Groups console, right-click the test OU you created in the last procedure and select D

   ELEGATE C

   ONTROL from the flyout menu. The Delegation of Control Wizard starts.

2. Click Next. The Group or User Selection window opens.

3. Click Add. The Select Users, Computers, or Group window opens.

4. Enter the first few letters of the name of the security principal you want to add and then click OK. If more than one security principal meets the search criteria, select the desired name from the list.

5. Click Next. The Tasks to Delegate window opens (see Figure 13.7).

   Figure 13.7. Delegation of Control WizardTasks to Delegate window

   

6. You can select any or all of the options under Predefined Tasks or build a Custom Task. If you select a predefined task and click Next, you'll be presented with a summary window. Click Finish and the rights will be applied. Select Custom Task just to see what this option looks like.

7. Click Next. The Active Directory Object Type window opens (see Figure 13.8).

   Figure 13.8. Delegation of Control WizardActive Directory Object Type window.

   

8. If you select Entire Folder, the rights you select in the next window will be assigned to all subordinate objects regardless of their type. If you select Only the Following Objects in the Folder, you can select one or more object types that will inherit the rights you assign.

   The Create and Delete checkbox options are handy if you want to give permission to add and remove instances of the selected object type.

9. Scroll down the list under Object Types and select User Objects.

10. Click Next. The Permissions window opens (see Figure 13.9). You can choose from the following:

    
    

    • The General option includes standard object permissions along with any extended rights applicable to the object class.

    
    

    • The Property-Specific option displays the properties associated with the object class with the option to permit or deny reading or writing to each property.

    
    

    • The Creation/Deletion of Specific Child Objects option displays a list of object types so you can assign permission to add or remove instances of that class.

    
    
    
    

    Figure 13.9. Delegation of Control WizardPermissions window.

    

11. Select the permissions you want to grant and then click Next. The wizard displays a summary window. Click Finish to apply the changes. The update will be applied to every object of the type you selected.

[user]
aCSPolicyName=7
adminCount=7
allowedAttributes=7
allowedAttributesEffective=7
allowedChildClasses=7
allowedChildClassesEffective=7
badPasswordTime=7
badPwdCount=7
bridgeheadServerListBL=7
c=7
canonicalName=7
cn=7
co=7
codePage=7

Managing Access Lists with DSACLS

Up to now, I've used the AD Users and Computers console to manage permissions. If you prefer a command-line tool, the Support Tools includes a utility called DSACLS for managing Active Directory permissions.

The DSACLS syntax to view the contents of a security descriptor for an object called cn=Average User in the Company.com domain would be:

dscacls cn=average user,cn=users,dc=company,dc=com

Here is a sample DSACLS listing truncated for brevity to show a single ACE entry:

C:\>dsacls "cn=average user,cn=users,dc=company,dc=com"
Displaying ACTRL_ACCESS list: AccessList
Entries: 1
Flags: 1
cEntries: 3
Entry 0:
Trustee.Name: COMPANY\Domain Admins
fAccessFlags: 1
Access: 0x780001ff
ProvSpecificAccess: 0
Inheritance: 0x2
lpInheritProperty:
Entry 1:
Trustee.Name: NT AUTHORITY\SELF
fAccessFlags: 1
Access: 0x780001ff
ProvSpecificAccess: 0
Inheritance: 0x0
lpInheritProperty:
Entry 2:
Trustee.Name: NT AUTHORITY\SYSTEM
fAccessFlags: 1
Access: 0x780001ff
ProvSpecificAccess: 0
Inheritance: 0x0
lpInheritProperty:
DSACLS succeeded

The Access entry in each of the listings holds an eight-digit hex number called an

access mask . Table 13.1 lists the standard access rights and their associated access mask. You may see these values in other command-line utilities and Event log entries.

When you assign permissions to a security principal, the ACE mask contains the sum of the various permissions. If you assign access permissions to a particular property, the DSACLS listing includes the property name and its ACE mask. Here is an example:

Property: Change Password
Flags: 1
cEntries: 1
Entry 0:
Trustee.Name: COMPANY\HelpDesk Admins
fAccessFlags: 1
Access: 0x100
ProvSpecificAccess: 0
Inheritance: 0x2
lpInheritProperty:

In this instance, the HelpDesk Admins have been given Control Access rights (0x100) to the Change Password property for the object. This permits a member of that group to reset a user's password.

You can use DSACLS to modify rights as well as read them. For example, if you want to assign Full Control access rights to a group called Daily Operations for all objects in an OU called Sales and all subcontainers under Sales, you can do so with the following command:

dsacls ou=Sales,dc=Company,dc=com /s:co /g "Daily Operations":780001ff

For normal workday activities, DSACLS is probably too clumsy to use directly. But it can function as part of a script or batch file to simplify rights assignments or to pull quick scans of permissions for later analysis.