Identifying the Domain Administrative Structure


Once your forest is designed, your domain structure can be created. The same design criteria that went into the forest design also dictates how the domains are created. For ease of administration, you should always start with the most basic design, the single domain. The need for autonomy and isolation then dictates whether you will need to create additional domains.

Domain owners have to accept the fact that they share administrative control with the forest owners. They also have to accept that some elements of administrative control are out of their control unless they are also Enterprise Admins. Certain functions such as deleting their domain or adding in an Active Directory “enabled application that modifies the schema of the forest cannot be performed by the domain owners. They have to rely on the forest owners to provide that functionality.

True isolation cannot occur unless the domain resides in its own forest and the domain administrators are also the forest administrators. Domain/forest owners need to understand that their domain/forest could become compromised by a rogue or coerced administrator. A rogue administrator is an individual who abuses the power that they have been granted. This abuse could be as simple as an administrator who views the information within the domain in order to glean some information about users or resources, or as devious as an administrator who intentionally damages or manipulates information. Coerced administrators are those who may be forced into performing a security breach within the infrastructure.

Security breaches by these rogue or coerced administrators could occur within the domain, from other domains within the forest, or from external domains via explicit trusts. Because all domains in the forest share information, a rogue or coerced administrator could modify the contents of Active Directory to allow a security breach, such as modifying the members of high-level group accounts. Domain owners should make sure that they know who the administrators are within the domain at all times. They should monitor the membership of any administrative groups. Domain owners should validate the work that the forest owners are performing and monitor the actions the forest owner performs within the domain owner s domain.

Active Directory is designed to be flexible enough that you can create a single domain to support the organization, or a multiple domain design can be utilized if necessary. In the following sections, we are going to look at the differences between the domain designs and the criteria that forces a multiple domain design instead of a single domain. We will also look at the requirements for creating multiple trees within our forest, and identify the security considerations of having a single domain compared to multiple domains, as well as the options for creating domains.

Using a Single Domain

As we have mentioned before, the simpler the design, the easier and more cost effective it is to administer and maintain the infrastructure. Domains are no exception. If the forest administrators are also the domain administrators, you may be able to implement a single domain for your organization.

If you use this approach, all of the accounts within the domain will be required to use the same account policies. Password policies, lockout restrictions, and Kerberos policies are controlled at the domain level for domain accounts and cannot be overridden at any other level within the domain. As long as this is acceptable, the single domain design will work.

However, if any accounts need to have differing account policy requirements, you ll need an additional domain.

Warning  

Local accounts on a member server or workstation may not have the same password and lockout restrictions that will be enforced on domain accounts. These settings can be controlled at the local security policy on the computer or at the organizational unit (OU) that contains the computer account(s). Make sure that you are periodically checking the settings at these levels to ensure that your company s standards are met.

Note  

There are programmatic methods for enforcing differing settings on specific accounts. Using Active Directory Services Interface (ADSI) scripting, you could specify that certain accounts passwords need to be changed at a shorter interval than what the domain password policy is set for. For instance, you could enforce sensitive accounts to change their passwords at the end of a 30-day cycle while forcing other accounts into a 45-day cycle through the domain password policy.

A single domain design can accommodate any of the administrative models: centralized, decentralized, hybrid, or outsourced. In the following sections, we will look at how a single domain can support all of them.

Identifying Centralized Administration Support

As you recall from Chapter 1, Analyzing the Administrative Structure, the centralized administrative model was divided between two different approaches: centralized administration/centralized resources and centralized administration/decentralized resources.

For the centralized administration/centralized resources model, the domain administrators will have control over all of the services and objects within the domain. The objects can be organized within OUs so that the administrative staff can apply Group Policy Objects (GPOs). This reduces the administrative load by controlling how the resource acts within the domain and how access to the resource is allowed. Centralized administration with decentralized resources works in much the same way. The resources can be grouped by location, and then subdivided based upon the GPOs that are applied to the resource.

Figure 4.1 shows an example of a single domain used for centralized administration/ centralized resources, whereas Figure 4.2 shows an example of a single domain used for centralized administration/decentralized resources. The domain that is structured for centralized administration/centralized resources takes advantage of having all of the resources centrally located. In Figure 4.1, the administrative staff can have the proper permissions applied at the domain level. Whereas all of the objects within Active Directory are located within the same OU hierarchy, the permissions for the administrative staff will pass down to each object.

click to expand
Figure 4.1: Single domain used for centralized administration/centralized resources
click to expand
Figure 4.2: Single domain used for centralized administration/decentralized resources
Note  

For more information on using OUs for administrative control, see Chapter 5, Designing an Organizational Unit Structure for Administrative Purposes. For more information on using OU for the application of Group Policy objects, see Chapter 6, Designing a Group Policy Infrastructure.

In Figure 4.2, the resources are not centrally located, so the OU structure has been designed to take advantage of the location of the objects. The domain owners will have permissions assigned to them at the domain level so that they can have control over all of the objects within the domain. The administrative staff at each location can then be granted the proper permissions to manage the objects for which they are responsible. These permissions are set at the OU that represents their location.

Identifying Decentralized Administration Support

You could create additional domains to allow a separation of service or data administration. This would allow different service administrators to have control over their own domain controllers and the servers that support them. Data administrators could then have a level of autonomy over the data that they manage. Decentralized administration is also supported through OUs.

You can group resources by location and delegate the administrators of each resource administrative control. This allows access to only those administrators who need to control the resource. If Group Policy objects are to be used, the OUs can be created for administrative control and child OUs can be created to organize the objects and to assign GPOs to.

Note  

For more information on using OUs for administrative purposes, see Chapter 5.

Figure 4.3 shows a single domain design employing OUs for decentralized administration.

click to expand
Figure 4.3: Single domain using OUs for decentralized administration

Identifying Hybrid Administration Support

Hybrid administration takes on the best of both the centralized and decentralized models. Objects are still organized and controlled as though they were part of the decentralized model, but those administrators who need to maintain standards and policies will have rights to the OUs within the domain.

For example, if a group of administrators are responsible for creating the GPOs that will be applied to computers within the domain, they are delegated the right to create GPOs but not to assign them anywhere within the domain. This keeps them from having the power to modify the behavior of a server. The administrators responsible for the servers are then granted the right to apply GPOs to the OUs they control. They are able to read the settings on the GPO to verify that the policy is configured to work correctly but are not able to modify the policy setting. This keeps them from overriding corporate standards.

Of course there has to be a level of trust between the groups. Once applied, the GPO can still be modified, and once the policy has been created the administrator doesn t have to apply it. In a situation where policy administrators have the backing of upper management to control the resources with the policies they create, the administrators who manage the objects within Active Directory will have to abide by their rules. That does not mean that they have to blindly follow the criteria defined at the policy level. They can always question the effects of the policy if they think that the settings are incorrect.

Note  

For more information on how to control the rights users have to perform actions with or against GPOs, see Chapter 6.

Figure 4.4 shows a single domain using OUs for hybrid administration.

click to expand
Figure 4.4: Single domain using OUs for hybrid administration

Identifying Outsourced Administration Support

Finally, the outsourced model takes on the same basic design as the decentralized model. OUs can be created to allow the outsourced administrators to have access to only those objects that they need to work with.

When making the decision to use outsourced staff, determine which of the objects they need. Separating these objects into their own OUs is a good idea because you can set permissions on the remaining OUs that will keep them out. Remember, the rule of thumb is to allow as few rights and permissions as possible. Security is of the highest concern. When you have individuals from outside companies accessing your systems, you need to make sure that they are restricted as much as possible.

Figure 4.5 shows a single domain using OUs to control outsourced administration. To control access to the resources that the outsourced administrators will manage, an additional OU has been created. The outsourced administrators can be delegated the permissions they need to perform their job functions whereas the OU owners will have permissions that are inherited from the parent OU.

click to expand
Figure 4.5: Single domain using OUs for outsourced administration
start sidebar
Real World Scenario ”Choosing a domain structure

Memorial Hospitals has five hospitals in two states that are supported by a single IT staff. This staff is divided into teams based upon each of the hospitals . Administrators from each team are responsible for their own hospital. The decision to move from Windows NT 4 to Windows Server 2003 was finally made and approved by the board of directors. The primary reason for the change stemmed from imminent loss of support, but the company also understood the need for lowering the total cost of ownership (TCO); moving from the Windows NT directory service to Active Directory was seen as a way of saving administrative costs. To reduce the administrative overhead, the design team decided that the existing domain structure needed to be collapsed .

Under Windows NT, the hospital had built several domains. Master user domains were created for each of the hospital units, and these were controlled by each of the administrators for the individual domains. Resources were split up into domains based on the hospital units also. The administrators administered these resources from the hospitals, but accounts had rights to perform tasks such as backing up the systems and performing routine maintenance on them.

After deciding that each of the hospitals could still control its own resources and user accounts, the board of directors dictated that a central Information Technology team would be the forest owner and would have complete service administration control. A single domain environment was envisioned with the hospital units broken into OUs ”each having an administrative staff with only the appropriate rights delegated out to them.

In order to accomplish the migration, the domains were all identified and the administrative staff assigned. OUs were created based on the organizational needs, and the Windows NT domains were migrated to the new OUs. Once the administrators had rights delegated to them, they were able to perform the tasks they were responsible for just as they had when they owned their own domains. Because they were able to contain everything in a single domain forest, they were able to save administrative costs by controlling everything centrally with Active Directory.

end sidebar
 

Using Multiple Domains

You should have a compelling reason to move to a multiple domain model. Some design decisions, such as security policy requirements, force the issue. You may also need to reduce the amount of replication between office locations. Note that any time a design becomes more complex, the administrative costs increase. Although this increase is not be as drastic as maintaining multiple forests, the administrative staff needs to understand the complexities of the domain design and know how to administer the infrastructure.

Although security policy considerations force the multiple domain issue, other design criteria also dictate the move to multiple domains. If you need data or service autonomy, you can create a domain so that the domain administrators can control the data or service. When using the default administrative group memberships, administrators from other domains are not able to control resources outside of their domains.

The concept of using multiple domains for data autonomy is generally implemented to allow the organization to use decentralized administration. Because the administrators are allowed to have free run of their domains, they are able to provide all of the management of the domain and the resources within. This multiple model is often referred to as the regional domain model because it is most widely used in conjunction with geographically dispersed divisions of the organization. The regional domain model is more widely used when it is necessary to reduce the replication between locations than it is when the design is based on administrative needs, but both are valid concerns. Figure 4.6 shows an example of a multiple domain model that is based on regions .

click to expand
Figure 4.6: Regional domain model

You should base the upper-level domains within your design on static structures within the organization. The regional domain model works very well because the geographic locations will not change. Basing the structure on business divisions, departments, or projects may be too volatile and may cause too many changes within the infrastructure. As you bring new projects or departments online, you can merge them into the locations using OUs, or if you have an administrative or security need, you can create a child domain within the tree for the appropriate location.

Having domains based on locations can also add additional benefits to your design. Active Directory replication is reduced between domains because the domain partition is not replicated to domain controllers outside of the domain. In a forest design where a single domain exists within the forest, every domain controller receives a copy of every object and has to replicate every change to all of the domain controllers in the domain. When multiple domains are used, by default, only the schema and configuration container are replicated to every domain controller. Although regional domains eliminate the need to replicate the domain container across wide area network (WAN) links, your design may have to account for authentication traffic across those same WAN links.

However, there are implications to the regional domain model: you probably need additional administrative staff; security principles may need to move between domains, which is not a simple task; additional GPOs need to be maintained ; you need more domain controllers to support efficient authentication; and you must have more authentication paths for authentication than what you need with a single domain model. When trying to determine if this approach is the best, weigh the tradeoffs between the implications and the replication requirements to see which is more cost effective for the organization. You only create a new domain and build the trust relationship at the time the domain is put into place. Replication is an ongoing cost that will consume your network resources.

Using Multiple Trees

If an organization needs to have service autonomy and complete isolation of the directory service and data is not required, a multiple tree forest may suffice. Instead of creating a new forest to separate the divisions of a company, you can create an additional tree within the existing forest. This additional tree will have its own namespace to use, and at the same time can have its own set of service administrators who can be responsible for every domain in the tree. The administrators from the top-level domain within the tree could be added to the administrative groups in each of the lower domains to give them the ability to manage the entire tree. This will result in longer authentication paths because users need to use resources in domains from other trees. If users need to access these objects on a regular basis, you may need to create shortcut trust relationships (see the discussion on trusts later in this chapter within the Using Trusts Between Domains section). Figure 4.7 shows an example of a multiple tree forest.

click to expand
Figure 4.7: Using multiple trees within the forest

One of the most important benefits of this design is the integrated schema. All of the trees and every domain within will share the same schema, and all of the objects will become available within the Global Catalog. Users will be able to easily search for those items they need to work with, and administrators will have control over their own resources. This model also affords administrative collaboration if necessary.

Of course, the drawback to using multiple trees within a single forest instead of using separate forests for each tree stems from the fact that complete isolation is not achieved. Administrative accounts from the root domain will be able to control resources throughout every tree within the forest because any member of the Domain Admins group from the forest root domain could add itself as a member of the Enterprise Admins group.

No matter which of the designs is chosen , you will have to address security considerations. You will be most concerned with securing the Active Directory databases and communication, but you ll also want to deal with other considerations, such as the physical security of the domain controllers and supporting hardware.

start sidebar
Design Scenario ”Choosing a Domain Design

Jerry is trying to determine the best domain design for his company. Currently, only one business location is used within his organization. He knows that he wants Active Directory to be controlled by a single set of administrators. In addition, the Information Technology (IT) group consists of tech support staff who are responsible for maintaining Active Directory, and operations staff who are responsible for the daily backups and help desk functions.

The problem that Jerry is running into is the group down the hall. This division works with military projects and keeps their projects to themselves . The current network infrastructure has their division completely isolated from the rest of the organization.

  1. Question: How many domains should Jerry plan on having in his design, and why? Answer: Due to the isolation required for the military projects division, Jerry s company will need two domains. Each domain will reside in its own forest to maintain complete isolation.

end sidebar
 

Identifying Security Concerns

When we are discussing security, the physical access to the domain controllers is of primary concern. Anyone who has direct access to domain controller hardware could perform attacks on the devices that make up the domain controller. Something as simple as powering off the system will keep users and applications from accessing Active Directory. Service outages could cost companies downtime and lost productivity. Once the system has been powered down, an attacker could restart the system under another operating system. Once the operating system is started, the object permissions will no longer restrict access to the objects, and the attacker can gain access to information that might be deemed confidential.

If an attacker has physical access to a domain controller, she could remove the physical media on which the Active Directory database resides. Once removed from the system, the media could be introduced to another system on which attacks could be performed against the database. With the correct tools and enough time, an attacker could discover account information including the account password and properties.

Another consideration that needs to be addressed is the storage of backup media. If someone were to take the media, especially the media on which the system state had been saved, she could restore the files to another system. Once this information was restored to the new system, someone could attack the data in order to glean information about Active Directory accounts. A very talented attacker could potentially modify information within the system state for the domain controller and then use the modified information to gain access to other areas of Active Directory.

Placing the domain controllers and any other vital servers within a locked room is one of the best ways to protect the physical server. You could then grant access to the server room to administrators who need access to the servers. You could secure this room with a simple lock and key mechanism, an electronic passkey, or biometric entry devices. It is not uncommon to find hand or retina scanners controlling entry to data centers in large companies.

No matter what level of security you apply, you may still run into rogue or coerced administrators. Because the service and data administrators need to have the tools necessary for the job, your best line of defense is to hire and assign responsibilities to administrators whom you can trust. As a proactive measure, you can monitor services for abnormalities. Server monitoring programs, such as Microsoft Operations Manager or Hewlett-Packard s HP OpenView and Insight Manager, will notify administrative staff if a server is shut down, or if exceptions are noted within event logs. Auditing object access will allow you to discover if someone is accessing Active Directory objects and show what sort of access was made or attempted.

As with any monitoring, remember to be judicial. Monitoring consumes resources. The more monitoring your system performs, the more contention there will be for the resources as the services try to use them. Find an adequate trade-off level that will allow you to monitor the resources while limiting the degradation of service.

Identifying Domain Creation Considerations

At this point in your domain design, you should have the information you need to determine the number of domains your organization requires. Remember, always start with the single domain design and then create additional domains based on service and data isolation or autonomy. Because a single domain will support all of the administration models, starting with this design will allow you to base your decisions on whether additional domains are required and why they are required.

Of course, multiple domains allow for a better security model, especially if you have service administrators who need autonomy over the resources for which they are responsible. You can then add OUs to allow data administrators to have autonomy over the resources they are managing. Before adding additional domains to the design, make sure to validate the reasons for creating them.

You should document the following information:

  • Domain model

  • Number of domains

  • Domain functional level for each domain

  • Domain used as the forest root

When deciding upon the domain functional level for each domain, you need to determine the functional level required for the domain roll-out and then a functional-level upgrade plan. Several functional levels are available, and the level that the domain can be set for will be dictated by the domain controllers within the domain.

Identifying Domain Functional Levels

Four domain functional levels can be used when configuring the domain:

Windows 2000 Mixed     A domain at this functional level supports the following: Windows NT 4 Backup Domain Controllers (BDCs), Windows 2000 domain controllers, and Windows Server 2003 domain controllers.

Windows 2000 Native Mode     A domain at this functional level supports the following: Windows 2000 domain controller and Windows Server 2003 domain controller.

Windows Server 2003 Interim     A domain at this functional level supports the following: Windows NT 4 BDC and Windows Server 2003 domain controller. Such a domain is used to facilitate upgrades from Windows NT 4 directly to Windows Server 2003.

Windows Server 2003     This functional level can only be attained when all of the domain controllers in the domain are Windows Server 2003 “based.

Each domain within the forest can be set to its own functional level, regardless of the level of the other domains.




MCSE
MCSE: Windows Server 2003 Active Directory and Network Infrastructure Design Study Guide (70-297)
ISBN: 0782143210
EAN: 2147483647
Year: 2004
Pages: 159
Authors: Brad Price, Sybex

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net