In this Chapter
The methods used to administer an IT organization can, in many ways, influence the success or failure of a company as a whole. Because the core of so many businesses relies heavily on IT resources, effective management of those resources through proper administration is of paramount importance. Windows Server 2003 provides the tools necessary to develop, deploy, and maintain administrative frameworks to meet the growing needs of IT organizations. Whether you have a small localized IT infrastructure or a large highly distributed environment, the administration of Windows Server 2003 can be easily customized to meet the specific needs of your organization.
This chapter will explore common administrative models and successful strategies developed to meet the needs of different IT organizations using Windows Server 2003. This chapter will guide the reader with tips and best practices on how to cost-effectively and securely distribute the administration of your IT resources.
Administrative models can help an IT organization begin to map out how IT resources and functions will be managed. Administrative models often follow a company’s network architecture in terms of whether they are centralized, distributed, or a combination of the two. Many companies will find exceptions to this rule. Because administration in Windows Server 2003 environments can be granularly distributed, each model can be easily supported. This section will discuss centralized, distributed, and mixed administrative models.
It’s a Lot Easier to Plan and Implement a Common Model in Early Active Directory Implementation Stages
The selection of the administrative model for an organization should be done early on in the design and planning phase of the Active Directory migration and implementation process. Although you can change administrative models, it’s a lot easier to plan and implement a common model in early Active Directory implementation stages.
With centralized administration, most if not all of the IT resources and functions are administered from a central location. This often means that all the critical servers and IT equipment are also located in one physical site. Having a completely centralized IT architecture provides the advantage of greater control of all the resources. There is also a cost savings when compared to distributed and mixed models in that operating costs are limited to maintaining a single site. This has become an increasingly attractive model to companies trying to save costs by consolidating their resources. The disadvantage to a completely centralized architecture may be the need to maintain an expensive wide area network (WAN) to provide high bandwidth to remote sites. If there are many users supported remotely, providing acceptable network performance characteristics might outweigh the cost of distributing the IT architecture. In such cases, IT resources will be located in the remote sites.
Centralized Administration Can Be Maintained in a Distributed IT Environment
In this case, network resources might be located at remote sites, but the administration and management of those systems are still administered at the local site. Even with distributed IT resources, you can still gain most of the benefits of a centralized architecture by localizing administration. As the need for hands-on administration grows at the remote sites, IT organizations begin adopting a distributed administration model.
In a distributed administration model, the administrative resources are physically located at both the local and remote site(s). In a Windows Server 2003 environment, there are varying levels of distributed administration. In a completely distributed administrative model, all administrative functions at the remote sites are managed and performed by IT staff in those same geographic locations. In this scenario, the company might gain better remote site performance by having onsite support for IT resources. Even in situations where all IT resources are kept in a central location, a distributed administration model might still apply. For organizations with a very large data center, various administrative roles can be distributed to different IT groups. For instance, one group might have administrative rights over DNS, but another group administers DHCP services. Obviously, with a completely distributed administration, an IT organization loses some of the benefits inherent to the central administration model.
To preserve those benefits, many companies adopt a centralized/delegated approach to distributing administration. In these scenarios, limited administrative functions are delegated to remote administrators, whereas the overall administration of the network is managed from the primary central site. When centralized and distributed administrative strategies are combined, the mixed model begins to emerge.
The mixed model of administration will leverage the benefits from both centralized and distributed administration models. The mixed administration model benefits those companies that require distributed network architecture, but also want to maintain some level of central administration. Through granting permissions and rights for specific administrative functions to specific groups or users, the distribution of IT administration can be managed centrally. One example might be to have network security policies managed for the whole organization from the central site, but to have the user and computer account management administered at each remote site.
For most large size distributed organizations, adapting to a purely centralized or distributed administrative model is not practical. Finding the right combination of administrative strategies will be key in deploying a successful IT infrastructure. In making your administrative choices, you should design a strategy that balances between lowering cost and optimizing control (the centralized model) while meeting the needs of users and service level agreements (as in the distributed model).
When administrative functions are distributed or delegated to different groups or users, it helps to map out this distribution by first identifying those key responsibilities, and then to organize them into principal roles. This section will outline high-level IT administrative roles based on industry best practices. The following sections will detail how Windows Server 2003 can be used to delegate administrative control over the various IT functions.
Some of the roles outlined in this section can be combined depending on the size, structure, and service level agreements of the given IT organization. Small companies might have only one individual responsible for all administrative roles, whereas large companies might have several individuals responsible for a single role.
The Operations Manager is responsible for the overall design of IT systems administration across the scope of the entire computing environment. Basically this is the top role that determines how administration will be distributed based on the size, architectural layout, geography, security requirements, and service level agreements of the company. The Operations Manager coordinates the efforts of all the other administrative roles.
Security administration is an important role in any company’s IT organization. An information system with a weak security foundation will inevitably experience a security breach. This administrative role covers many areas of IT administration. The key responsibility of the security administrator is to ensure the following:
Data confidentiality. Data internal to the company should only be accessible to users who have authorization.
Data integrity. The data available to authorized users should be accurate and free from tampering.
Data availability. Users authorized to view data should be able to view it when they need it.
The security administration role requires delegated rights and permissions in order to implement, manage, and audit security controls and policies. This role also requires the administrative control to respond to security events.
The network administration role is concerned with providing a reliable and consistent network infrastructure. The network infrastructure should meet or exceed service level agreements while at the same time optimize the company’s assets. In addition to being responsible for network hardware configurations and performance, this role is often also responsible for network services such as DNS and DHCP.
When Active Directory is installed, Windows Server 2003 allows the responsibilities of the network administrative role to be further distributed through the use of built-in user groups. Though you can create your own groups for delegating rights and permissions, the following built-in groups can expedite the delegation of administrative control over the some network administrator functions:
Network Configuration Operators. This group has the right to make TCP/IP setting changes on Domain Controllers within the domain.
DNSAdmins. Installed with the DNS service, members of this group have administrative access to the DNS Server service.
DCHP Administrators. This group is created when DHCP is installed on a server. Members of this group can administer all DCHP scopes configured on the server.
A directory service enables users and applications to find network resources such as users, computers, services, and other information on the network. The directory service administration role is primarily concerned with the operation, management, and support of the enterprise directory.
The directory service administrator must have rights and permissions to distribute and replicate a directory across a network to provide increased performance and redundancy. It must also be able to enforce security to keep information safe from intruders.
The delegation of administering the Active Directory service in Windows Server 2003 is best performed by using Organizational Units (OUs) and the Delegation of Control Wizard discussed in the next section of this chapter.
Delegating administration within Active Directory enables you to assign various levels of access and control to groups and users. Windows Server 2003 gives you the flexibility to grant control of a very focused access that might span the entire enterprise, or to grant entire control over a very limited scope of the directory. Delegating control also makes your network more secure by limiting the membership of the top level domain and enterprise administrator groups.
You can delegate control to any level of the domain tree by creating Organizational Units (OUs) and then delegating control of particular OUs to the groups or users that you have chosen. To determine what OUs to create, consider the structure of your organization.
For example, you might want to grant administrative control of all users and computers that are associated with a particular department, like Sales, to a particular group or individual. The best way to accomplish this is to create an OU for Sales, place all Sales users and computers in that OU, and then delegate control of the Sales OU to your chosen Sales department admin or administrative group.
You can delegate administration of your Sales department with more granularity by nesting OUs. For example you could delegate control of computer accounts to one group, and delegate control of user accounts to another group by creating nested OUs under the Sales OU as shown in Figure 4.1.
It Is Important to Keep in Mind...
that although you have the capability to create multiple OUs in your directory, it might not be advisable to do so. You should only add an OU to a domain if a group needs special administrative control to a set Active Directory objects. Group Policies are covered in detail in Chapter 6, “Implementing Group Policies.”
The Delegation of Control Wizard, as its name implies, enables you to delegate administrative control by using a wizard that guides you through the setup process. You can set varying levels of control using the wizard, even limiting the scope of the delegated control to a single operation.
For example, you might want to give a group the capability to do nothing more than reset passwords on user accounts in a particular OU. The process by which the wizard is used to accomplish this delegation is as follows:
In Active Directory Users and Computers, right-click the OU where you want to delegate permissions and choose Delegate Control.
Click Next at the Delegation of Control Wizard Welcome screen.
Click Add to select the group you want to grant access to.
Type in the name of the group and click OK.
Click Next to continue.
Under Delegate the Following Common Tasks, choose the appropriate permission; for this example choose Reset User Passwords and Force Password Change at Next Logon (see Figure 4.2). Then click Next.
In addition to enabling you to delegate common tasks like resetting user account passwords, the Delegation of Control Wizard provides an enormous variety of custom tasks for delegation. For example, you might want to grant the permission to create and remove computer accounts from a specific OU to a particular group. To perform this delegation, follow these steps to set the custom task:
In Active Directory Users and Computers, right-click the OU where you want to delegate permissions and choose Delegate Control.
Click Next at the Delegation of Control Wizard Welcome screen.
Click Add to select the group to which you want to give access.
Type in the name of the group and click OK.
Click Next to continue.
Select Create a Custom Task to Delegate and click Next.
Under Delegate Control Of, choose only the Following Objects in the Folder.
Check Computer Objects and then click Next.
Under Permissions, check Create All Child Objects and Delete All Child Objects as shown in Figure 4.3. Click Next.
The Ability to Delegate Tasks with This Level of Granularity Can Be Useful
The ability to delegate tasks with this level of granularity can be useful in an automated desktop deployment scenario where adding the new desktop computer accounts to the domain is a scripted function following an automated image process. The script can leverage a user account that has the previous example’s delegated permission, but with no other functional administrative access.
If you need to see the permissions granted at a specific OU level, do the following:
In Active Directory Users and Computers, right-click the OU for which you want to review permissions and choose Properties.
Click on the Security tab and then click Advanced.
Under Permission Entries, double-click the group or user to whom you granted permissions.
You can view and edit the special permissions in the Permissions section, as shown in Figure 4.4.
You are probably familiar with the mixed and native modes of Active Directory in Microsoft Windows 2000. Mixed mode provides backward-compatibility with NT 4.0 environments where Backup Domain Controllers can exist and authenticate user logons. Promoting a Windows 2000 domain to Native mode eliminates the use of backup Domain Controllers and, in turn, provides additional Active Directory features such as Universal Groups.
With Windows Server 2003, the concept of modes is augmented with the introduction of functional levels. Like Windows 2000 Active Directory modes, Functional levels provide levels of backward-compatibility for both Windows NT 4.0 and Windows 2000 domains. In Windows Server 2003, there are four domain functional levels and three forest functional levels. This section will provide an overview of the Windows functional levels and their implications on administrative design and management.
Common Misunderstanding
There is a common misunderstanding that a native mode forest in Windows 2000 requires that all servers and workstations in the network are Windows 2000 or higher configurations and that an organization could not have Windows NT 4 servers or workstations, or Windows 9x workstations. This is a misunderstanding because a native mode forest in Windows 2000 only required that all domain controllers were Windows 2000. A native mode forest in Windows 2000 could have Windows NT 4 member servers, Windows NT4 workstations, and Windows 9x workstations in the domain and still function properly.
The Windows 2000 Mixed Domain Functional level provides for backward-compatibility with a Windows 2000 Active Directory running in Mixed Mode. Installed at this level, Windows Server 2003 domain controllers will be able to communicate with both Windows NT 4.0 and Windows 2000 domain controllers throughout the forest. At this level, Windows Server 2003 shares the same limitations present in the Windows 2000 mixed mode domain. Usually, this is a temporary level for most companies that are in the process of migrating to a native mode Active Directory.
The Windows 2000 native functional level is the initial operating level of Windows Server 2003 domain controllers installed into a Windows 2000 native mode domain. At this level there are no NT 4.0 domain controllers. All authentication is performed by Windows 2000 and Windows Server 2003 domain controllers.
The Windows Server 2003 interim functional level is the initial operating level of Windows Server 2003 domain controllers installed into a Windows NT 4.0 domain. This level is provided primarily as a stepping stone during a migration from Windows NT 4.0 to Windows Server 2003. The interim functional level comes into play for those companies that have not upgraded to Windows 2000, but instead migrate directly to Windows Server 2003 Active Directory.
To gain the full functionality of a Windows Server 2003 Active Directory, the Windows Server 2003 functional level is the final goal for domain and forest functional levels. Functionality at this level enables many of the new features available to Windows Server 2003 such as renaming domains and domain controllers, schema deactivation, and cross-forest trusts. For you to promote your Active Directory to the full Windows Server 2003 Functional level, all domain controllers must be upgraded to Windows Server 2003. Individual domains can be promoted to the Windows Server 2003 functional level, but the forest can only be promoted to this functional level after all the domains in the forest are operating at this highest level.
You can use Active Directory Users and Computers or Active Directory Domains and Trusts to elevate domain functional levels. To raise the forest functional level, though, you must use the Active Directory Domains and Trusts tool. If you are ready to perform both operations, follow these steps:
Ensure that all domain controllers in the forest are upgraded to Windows Server 2003.
Open Active Directory Domains and Trusts from the Administrative Tools menu.
In the left scope pane, right-click on the domain name and then click the Raise Domain Functional Level.
In the box labeled Raise Domain Functional Level, shown in Figure 4.5, select Windows Server 2003 and then click Raise.
Click OK and then click OK again to complete the task.
Repeat steps 1 through 5 for all domains in the forest.
Perform the same steps on the forest root object, except this time choose Raise Forest Functional Level and follow the prompts.
There are new administrative capabilities at each domain functional level that you should be aware of. In part, understanding the new capabilities help in the decision to elevate functional levels. It is also important to keep these capabilities in mind when deciding whether to grant or prevent access to these functions within your IT organization.
Raising Functional Levels Is a One-way Operation
Be sure you will not need to add Windows 2000 domains to your forest before performing this process. When the forest is Windows Server 2003 functional, this applies to child domains as well.
When you elevate your domain from a Windows 2000 mixed to a Windows 2000 Native functional level, you add the following administrative capabilities:
SID History. This feature enables you to migrate security principles from one domain to another while preserving associated access control lists (ACLs).
Converting Groups. This feature gives you the capability to change distribution groups and security groups.
Nesting Groups. In mixed mode, you can nest distribution groups, but not security groups. Windows 2000 Native mode allows you full nesting of security groups.
Universal Groups. Universal groups can contain accounts, global groups, and universal groups from any domain in the forest.
Elevating your domain from Windows 2000 Native functional level to Windows Server 2003 functional level gives you the capability to rename domain controllers within that domain.
When you raise your forest functionality from Windows 2000 to Windows Server 2003, you enable the following administrative capabilities:
Deactivation of schema objects. Although you cannot delete classes or attributes, you can deactivate them if they are no longer needed or if there was an error in the original definition.
Forest trusts. With this functionality, you can link two disjoined Windows Server 2003 forests to form one-way or two-way transitive trust relationships. A two-way forest trust creates a transitive trust between every domain in both forests.
Domain rename. Within a Windows Server 2003 native level forest, you have the ability to rename domains. This functionality also permits the restructuring of domains within the forest.
The Senior Administrator Should Limit the Access of Who Can Raise the Functional Level of a Domain
Rather than leaving the privilege to all Domain Admins, the right should be blocked to all Domain Admins and assigned to specific administrators. Although it is unlikely an individual would maliciously raise the functional level of a domain and effectively cause non-compliant domain controllers to be dropped from the network, there is a very common possibility of an inexperienced administrator accidentally changing the functionality level, and thus creating authentication problems on the network.
Be Very Careful in Designing Your Administrative Framework...
so that only individuals who understand and are responsible for the implications of forestwide changes have access to make them.
The forestwide capabilities of Windows Server 2003 each have an enormous impact on the stability of your enterprise network.
Perhaps the two most important administrative groups in the Windows Server 2003 Active Directory are the Domain and Enterprise Admins groups. Because of their importance, membership in these groups should be very limited. As has been detailed earlier in the chapter, it is very easy to delegate permission to varying degrees of access within the Active Directory structure. By delegating control, you are able to limit the membership of the Domain and Enterprise Admins to only those individuals who are responsible for making changes that affect the entire domain or forest.
This section provides an overview of the management of the domain and enterprise admins groups.
Members of the Domain Admins group have full control of the domain. By default, this group is a member of the Administrators group on all domain controllers, all domain workstations, and all domain member servers at the time they are joined to the domain. By default, the Administrator account is a member of this group.
Clearly a secure IT infrastructure will have a very limited Domain Admins group for each domain in the forest. This is easily accomplished when setting up a new domain from scratch. You simply identify those individuals (or services) who will have domainwide responsibility, and limit the membership of this group to those individuals. Domain group membership can be enforced via Group Policies, which will be discussed later in this chapter.
If you are upgrading a Windows NT or Windows 2000 domain to Windows Server 2003, it is important to review and validate the Domain Admins group membership before proceeding with the upgrade. One can often find built-in NT 4.0 domain local groups added to the Domain Admins, such as Account Operators. Depending on the membership of Account Operators, the integrity of the Domain Admins group could be compromised after the upgrade.
The Run As feature enables a user logged in with a primary user account to run a particular application or command from the security context of a secondary user account. To execute an application using the Run As feature, for example Active Directory Users and Computers, simply do the following:
Browse to Active Directory Users and Computers in Administrative Tools.
While holding down the Ctrl key, right-click the Active Directory Users and Computers.
Choose Run As.
In the Run As dialog box shown in Figure 4.6, check The Following User and provide an administrative account and password.
Members of the Enterprise Admins group have full control of all domains in the forest. By default, this group is a member of the Administrators group on all domain controllers in the forest. By default, the Administrator account is a member of this group. The Enterprise Admins group only appears in the forest root domain.
All of the precautions that apply to the Domain Admins group also apply to the Enterprise Admins group. In a forest that contains multiple domains, members of the Enterprise Admins have administrative control over Active Directory in every domain; hence the membership of this group should be even more limited.
The Schema Is the Most Critical Component of Active Directory
Unauthorized access to the schema master domain controller for a forest can cause serious problems with the potential to corrupt the entire directory. Implementing a peer root domain segregates the keys to schema modification from the user base of the forest.
By placing these security principles in an empty root, membership of these groups will be protected from any other administrative accounts in the forest. For example, by default the only member of the Schema Admins group is the administrator account. Isolating the Schema Admins group in an otherwise empty root domain preserves and protects the membership of this group from domain level administrators.
As mentioned earlier in the chapter, Active Directory group policy objects (GPOs) can be leveraged to manage and maintain a company’s administration policies. This section will outline some industry best practices for controlling administrative delegation through GPOs. For more detailed information on using Group Policies, see Chapter 6.
If You Are Enforcing Administrative Policies...
that apply to member servers, computer accounts, or user accounts, create an OU structure to group these objects, and then link your GPOs to the appropriate OUs. If your policies are to apply domainwide, you should link the GPOs to the domain. More tips on linking GPOs to Active Directory containers can be found in Chapter 6.
Because policies that apply to administrative access within Active Directory are directly related to Domain Controllers, the scope of your group policy objects should be applied to the Domain Controllers container. You can edit the existing Default Domain Controllers policy or create additional GPOs and link them to the Domain Controllers container. You can also use the Default Domain Controller Security Settings snap-in.
Many of the policy settings available for managing administration can be found by navigating through the GPO Editor to Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options. For example, in Figure 4.7, a policy is set to rename the local administrator password, which could be a standard policy setting applied to all file servers in a particular domain.
To enforce group membership, like the static membership of the Domain Admins group, set a Restricted Groups policy. When a Restricted Groups policy is enforced, any current member of a restricted group that is not on the Members list is removed. Any user on the Members list who is not currently a member of the restricted group is added. To create a Restricted Groups policy, perform the following steps:
In the Group Policy Editor, navigate to Computer ConfigurationWindows SettingsSecurity SettingsRestricted Groups as shown in Figure 4.8.
Right-click Restricted Groups, and select Add Group. Type in the name of the group or click Browse for Group.
Click the Add button, and then type the names of the security principles that will belong to this group. Click OK.
You can also use group policies to delegate rights not available in the Delegation of Control Wizard but required for some administrative tasks. These settings are found in the GPO Editor by navigating to Computer ConfigurationWindows SettingsSecurity SettingsLocal Policies. For example, standard user accounts do not by default have the right to log on to a Domain Controller locally. Although most maintenance tasks on Domain Controllers can be accomplished without a local logon, if a particular maintenance task requires a local logon, you could grant the right to a group by performing the following configuration on the Default Domain Controller GPO:
In the Group Policy Object Editor, navigate to Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignments.
In the right-hand pane, double-click Allow Log On Locally.
Select the Define these Policy Settings box.
Click the Add User or Group button.
Type the Group name and click OK.
It is always a recommended best practice to test changes that will affect Active Directory. Because administration has direct implications for network security, it is paramount that delegations of administration changes are made to withstand rigorous test procedures. This section will highlight some methods by which to ensure such delegations are made in a secure manner.
It is commonly understood that testing is a necessary stage in any IT deployment scenario. The test lab is an investment that can pay for itself many times over in reduced support and redeployment costs that arise from poorly tested solutions. You should always be sure to test your proposed design in an environment that simulates, as well as protects, your production environment. You can verify your design by devising and conducting tests that reflect the conditions of your production IT resources. Although this truism is usually incorporated into the deployment plans of large migrations, it is just as important to keep your testing environment in service post-deployment for ongoing testing of changes that affect security and administration in Active Directory.
The prototype lab environment should resemble the production environment insofar as primary components such as a Windows Server 2003 domain controller, file server, network equipment, and test workstations are represented. Lab components of course will vary depending on services in use and the complexity of the production architecture. The lab network should be isolated from the production network so as not to cause potential naming conflicts, replication errors, or database corruption. Though isolated, good lab environments will contain real data and applications. Data can be copied from live production servers, or data from tape can be restored into the testing environment.
When Testing Delegation of Control and Group Policy Results...
it is helpful to have the same security principles in both the test and production directories. You will get better results if group names and group memberships from both environments match.
It is important to keep your lab environment up to date with the latest patches and changes that are deployed in the production environment. If your lab domain computers are at a different revision level in service pack from the production domain computers, your test results might be inconsistent with the real world.
When testing modifications to the default administrative settings in the lab environment, it is important to document the processes by which the tests were conducted. If problems result in the production domain that did not manifest in the lab domain, you can return to your test procedures documentation to verify whether the correct steps were followed. Documenting the procedures and maintaining a database of the tests that have been performed will help you when similar tests are required at a later date.
Carefully Documenting Test Procedures Is Extremely Important
Carefully documenting test procedures is extremely important if the testing is being carried out by a different group than the one responsible for implementing the changes. The documentation will serve as the step-by-step procedures used to replicate the test procedures in the production environment. If the documentation is not followed, the results of the production implementation might have different results than discovered in the test process.
As changes are implemented in the production environment, documentation should be maintained to precisely log when and what has been implemented. Although individual tests and directory modifications made at discreet times might prove successful, the combination of different changes made over time might have unexpected results. Also, the ramifications of some changes are not completely flushed out immediately. It might take days or weeks before a problem manifests itself. Keeping a log of the changes that have been made over time will expedite any troubleshooting should a conflict arise.
Windows Server 2003 provides tools for testing and troubleshooting your group policy changes. These are Group Policy Modeling (also referred to as Resultant Set of Policy Planning Mode) and Resultant Set of Policy. Although these tools are detailed in Chapter 6, it is important to highlight them here as tools to test and troubleshoot Delegation of Control and Group Policy settings.
Integrated into the Group Policy Management Console, Group Policy Modeling (also referred to as Resultant Set of Policy-Planning Mode) enables you to simulate a policy deployment that would be applied to users and computers before actually applying the policies. The Group Policy Modeling Wizard can be opened from the Group Policy Modeling container, the domain node, or from any OU. When the Group Policy Modeling Wizard is started from one of these containers, the wizard automatically passes the scope of management data to the wizard and pre-populates the User and Computer Selection page of the wizard.
After you run a simulation, an HTML report is generated that gives a summary that contains the GPOs and security group memberships. The simulation also generates a Settings report, shown in Figure 4.9, that shows the simulated Resultant Set of Policy given the policies that were chosen in the wizard. For more information on Group Policy modeling, turn to Chapter 6.
This feature enables you to determine the resultant set of policy that was applied to a given computer and (optionally) user that logged on to that computer. The data that is presented is similar to Group Policy Modeling data; however, unlike Group Policy Modeling, this data is not a simulation. It is the actual resultant set of policy data obtained from the target computer. Unlike Group Policy Modeling, the data from Group Policy Results is obtained from the client, and is not simulated on the DC. The client must be running Windows XP, Windows Server 2003 or later.
Group Policy Results Data
It is not possible to get Group Policy Results data for a Windows 2000 computer. However, with Group Policy Modeling, you can simulate the RSoP data.
Resultant Set of Policy is an ideal tool for documenting the Group Policy settings that affect administration in a Windows Server 2003 Active Directory as it generates easy-to-use HTML reports. The tool can also be used to troubleshoot access and permissions problems in environments where multiple GPOs and delegated permissions are assigned to various containers in the directory. For more information on RSoP, see Chapter 6.
A key function in managing a centralized/delegated administrative model is proper monitoring of administrative activities. Not only does this give the Network Administrator role the ability to identify security breaches, but also it can provide an essential troubleshooting tool for the Directory Services administrator when permissions and access do not work as expected. To complete this chapter on distributing administration, this section will highlight what should be monitored in a securely distributed administration model. A more detailed account of monitoring is covered in Chapter 21, “Proactive Monitoring and Alerting.”
Because most administrative delegation occurs in Active Directory, it is wise to monitor administrative activities on domain controllers. You can set the auditing policies for domain controllers by editing the Audit Policy component of the Domain Controller Security Settings as shown in Figure 4.10.
On domain controllers, auditing is turned off by default. By defining auditing settings for specific event categories, you can create an auditing policy that suits the security needs of your organization.
For each policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when the specified type of event succeeds. Failure audits generate an audit entry when the specified type of event fails. To set this value to No Auditing, in the Properties dialog box for a policy setting, select the Define These Policy Settings check box and clear the Success and Failure check boxes.
If You Decide to Audit Failure Events in the Account Logon Event Category...
you can see if unauthorized users or attackers are trying to log on to your network. Although this can be helpful for intrusion detection, the possibility of a denial-of-service attack increases with the auditing of failure events in the account logon event category. Users who are outside your organization can cause these events to be logged, and as a result they can shut down your network.
An audit trail can contain information about changes that are made to your domain controllers or to Active Directory. If intruders gain administrator rights and permissions, or if delegated administrators abuse their rights and permissions, they can clear the security log, leaving you without a trail of their actions. If you use a tool that regularly collects and saves security log entries across your organization, even if intruders or administrators clear the local security log, you are more likely to be able to trace the actions of intruders or administrators. Microsoft Operations Manager is an example of such a tool.
By auditing success events in the account management event category, you can verify changes that are made to account properties and group properties. Review these events with a keen eye to the administrative groups with the most control—the Domain and Enterprise Admins groups.
If you decide to audit failure events in the account management event category, you can see if unauthorized users or attackers are trying to change account properties or group properties. Although this can be helpful for intrusion detection, the increase in resources that is required and the possibility of a denial-of-service attack usually outweigh the benefits.
By delegating administration you can allow distributed groups and users within your organization to play a role in the administration of network resources while at the same time maintaining a level central control. Delegation of administrative tasks and granting administrative rights and permissions helps protect your network resources by limiting membership in the domain and forestwide administrative groups. Windows Server 2003 provides easy wizard-based tools to aid in the planning, implementation, and troubleshooting of administrative policies.