Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)
Administrative delegation is the ability to delegate Windows AD infrastructure-related administrative tasks to a particular administrator account or group. Delegation is possible thanks to the changes to the Windows authorization model coming with AD. Administrative delegation is a must in large AD environments to assign administrative control over different AD objects (OUs, sites, domains, GPOs, and so on).
10.7.1 Organizational units
An important enabler for the administrative delegation of AD objects is the inclusion of a container object in AD, called an organizational unit (OU). You can use an OU to delegate the administrative control over the objects contained in it.
When dealing with OUs, we must always keep the following in mind:
-
An OU is an AD container object that is primarily used to organize AD objects in a hierarchical way and to delegate control over these objects to different administrators.
-
OUs are not security principals. They do not have a security identity (SID). This is why they cannot be used in ACLs. Also, you cannot delegate administrative tasks to an OU. This makes an OU very different from a group. This does not mean that you cannot use ACLs to set authorization settings on OU objects.
-
An object can only be contained in a single OU, although from a hierarchical point of view an object can have multiple parent OUs.
-
An OU is bound to a single domain. It cannot span multiple domains.
The example in Figure 10.31 illustrates the use of organizational units: It shows the OU structure of an AD infrastructure spanning several geographical locations. The top-level OUs reflect the geographical locations (Continent and City) of the infrastructure: Europe is the top OU and underneath there is an OU for Brussels (BRO), Dublin (DBO), Amsterdam (AMS), and London (LON). Per location, the OUs are then split into subOUs that are based on the object types that must be administered:
There is an OU for administrators, one for users, one for machines, and one for printers.
The nesting of OUs is reflected in an AD object’s Distinguished name— this is illustrated in the following example of an object that is part of the OU structure in Figure 10.32:
CN=FileServer1, OU=Member Servers, OU=Machines, OU=BRO, OU= EU, DC= hp, DC=com
10.7.2 Setting up administrative delegation
To set up administrative delegation, Microsoft provides a delegation wizard (illustrated in Figure 10.33). The wizard is accessible from the Windows GUI on the level of sites, domains, and OUs. The delegation wizard allows an administrator to choose among a set of predefined delegation tasks (listed in Table 10.19). An administrator can also create custom tasks to better reflect the organizational needs. Custom tasks can be defined from the delegation wizard or you can add them as predefined tasks to the wizard. How to add predefined tasks to the delegation wizard is explained in the following sidebar.
| Domain | Join a computer to the domain Manage group policy links |
| Site | Manage group policy links |
| OU | Create, delete, and manage user accounts Reset user passwords and force password change at next logon Read all user information Create, delete, and manage groups Modify the membership of a group Manage group policy links Generate Resultant Set of Policy (Planning) Generate Resultant Set of Policy (Logging) Create, delete and manage inetOrgPerson accounts Reset inetOrgPerson passwords and change password change at next logon Read all inetOrgPerson information |
Administrators that are familiar with the new ACL editor and the changes on the level of the ACL model in Windows 2000 and Windows Server 2003 can do without the delegation wizard, and set delegation through the ACL editor of a site, an OU, or any other object’s ACL editor.
A new management tool that is very convenient to delegate administrative control over group policy objects is the Group Policy Management Console (GPMC). The GPMC GUI contains a special delegation tab for every GPO (as illustrated in Figure 10.34). GPMC is a free add-on tool that can be downloaded from the Microsoft Web site at http:// www.microsoft.com/downloads/details.aspx?FamilyId=F39E9D60-7E41-4947-82F5-3330F37ADFEB&displaylang=en.
Undelegating administrative permissions can be done from the ACL editor or by using one of the command-line tools listed at the end of this chapter. A big problem in this area is how to easily remove all the permissions that are set for an account on child objects (e.g., in the case in which administration was delegated on the level of an OU), as the delegation wizard can only be used to add permissions, but not to remove them. You could write a script that iteratively runs through the ACLs of all child objects and removes all occurrences of a particular account. Microsoft is planning to provide a new command-line tool called dsrevoke.exe to ease and automate the removal of permissions on hierarchical object structures. The tool was first presented to the public at TechED 2003.
Customizing the Predefined Tasks in the Delegation Wizard The predefined tasks appearing in the delegation wizard can be modified using the delegwiz.inf file configuration file (illustrated in Figure 10.35), located in the %Windir%/inf directory. How to customize the task list is explained in the Microsoft Knowledge Base article Q308404 available from http://support.microsoft.com/default.aspx?scid=kb;en-us;308404.
To reflect the administrative delegation on the level of the administrator interface, Windows 2000 and Windows Server 2003 allow you to develop customized administration interfaces. Microsoft calls these interfaces task- pads. To create a taskpad, you use the Taskpad View Wizard. To get to the wizard, open a new MMC console and add a snap-in. Right-click the snap- in container and select New Taskpad View. Customized MMC consoles and taskpads can be saved as regular files. If you want, you can, for example, send them by mail to the administrators who need it.
10.7.3 Delegation guidelines
It is not recommended to use delegation on the level of AD domains and sites. Microsoft even recommends to only delegate on the OU level.
Delegation on the domain level cannot fully isolate the administrative authority of a particular administrator. As mentioned in Chapter 2 of this book, a Windows domain is only a boundary for AD replication. From Windows 2000 onward, the true security boundary is the forest. If you want to provide complete isolation between administrative entities, set up multiple AD forests.
It is not recommended to delegate administration tasks on the site level because sites are bound to the physical layout of the network used for your AD infrastructure. Sites are based on IP addresses and subnets. The fact that a single site can span different forests, domains, and OUs may make the ACL evaluation process too complex.
It is also not recommended to delegate the following AD infrastructure- related administrative tasks:
-
Management of AD security settings, including the management of the Default Domain and Domain Controller Group Policies
-
Backup and Restore of AD
-
Promotion and demotion of AD Domain Controllers
10.7.4 Administrative delegation examples
The following examples illustrate how you could use administrative delegation in a Windows Server 2003 domain.
Help-desk scenario
A typical scenario where AD administrative delegation is very helpful is a help-desk scenario. From a Windows account management point of view, organizations typically want to give the following abilities to their help-desk administrators:
-
Reset an account’s password.
-
Set the “User must change password at next logon” account property.
-
Unlock an account by unchecking the “Account is locked out” account property.
To delegate these administrative tasks to your help-desk administrators you must set the following permissions on the OU for which you want to delegate permissions:
-
Allow—Reset Password for user objects (grants permission to reset an account’s password).
-
Allow—Write lockoutTime for user objects (grants permission to unlock an account)
-
Allow—Write pwdLastSet for user objects (grants permission to set ser must change password at next logon”).
-
Allow—Read AccountRestrictions for user objects (grants permission to read all account options, for example allowing to determine if an account is enabled or not).
In order to display the pwdLastSet and lockoutTime user account attributes in the advanced view of the ACL editor of Windows 2000 machines, you must edit the dssec.dat configuration file. You must set the lockoutTime and pwdLastSet attributes to value 0 (default is 7). This process is illustrated in Figure 10.36.
User self-management scenario
By default, Active Directory allows specific user account attributes to be edited by the user. Examples are the user’s phone number, office location, and so forth. This feature can be leveraged to reduce workload on the help- desk administrators for simple and recurring user account property changes.
To enable user self-management, Microsoft provides a special security principal called self. By default, various permissions are set for the self security principal, enabling every user to edit attributes on his or her own user account in AD. To edit the attributes that can be self-managed, change the default authorization settings (default security descriptor) for the user class object in AD. The default AD security descriptor and its properties were explained earlier in this chapter. Figure 10.37 shows the permissions that are given by default to the self security principal for the user object class. Only newly created objects will have the updated permissions if you change the default security descriptor of its object class. In Windows Server 2003 you can re-apply the permissions to the default security settings via the new “Default” button in the advanced view of the ACL editor. You can also use the support tools utility DSACLS with the /S /T switches to reset the permissions on all accounts in an OU.
Networking service management delegation scenario
Table 10.20 gives some examples of network service management–related tasks that you may want to delegate to particular administrators in your organization and how you can set these delegations up.
| Management Task | How to Set Up Administrative Delegation |
|---|---|
| Authorize DHCP servers | Grant special permissions to DHCP administrators on the NetServices container in the AD configuration naming context:
|
| Stop, start DNS servers | Grant special permissions to DNS administrators on DNS service:
|
| Create DFS roots | Grant special permissions to DFS administrators on DFSConfiguration container in the AD domain naming context:
|
Third-party AD delegation tools
Table 10.21 lists a set of third-party software products[5] that can help facilitate AD administrative delegation. All of them provide a role-based abstraction layer that is implemented on top of AD. They all include logic that translates the roles and their associated AD administration tasks into native AD access permissions. In the future, Microsoft may provide similar capabilities using the Authorization Manager that is included with Windows Server 2003. For more information on role-based authorization and the Authorization Manager, refer to Chapter 12 of this book.
| Product | More Information at: |
|---|---|
| Quest FastLane ActiveRoles | http://www.quest.com/fastlane/activeroles |
| Aelita Enterprise Directory Manager | http://www.aelita.com/products/edm4.htm |
| BindView bv-Control for Active Directory | http://www.bindview.com/Products/DirAdminMig/ |
| NetIQ Directory Security Administrator (part of the Security Administration Suite) | http://www.netiq.com/products/admin/default.asp |
[5]A feature comparison between these products is available from http://mcpmag.com/features/article.asp?EditorialsID=359&whichpage=2&pagesize=10.
Категории