Create usable boundaries within Active Directory

This excerpt from "Administrator shortcut guide to Active Directory security" discusses the hard coded and manually created boundaries defined within AD.

Administrator shortcut guide to Active Directory The following excerpt is from Chapter 2 of the free eBook "Administrator shortcut guide to Active Directory security" written by Derek Melber and Dave Kearns and available at Realtimepublishers.com. Click for the complete book excerpt series.


Create usable boundaries

There are many boundaries that are defined within AD. Some of the boundaries are hard coded and others can be created manually. The boundaries are usually defined based on where the delegation of administration is established. There are three primary drivers for delegation of administration of AD: organizational, operational and legal. These delegation drivers must be included when the AD structure is created.

  • Organizational -- In this delegation model, parts of the organization share the infrastructure to save costs but must have the ability to operate independently from the rest of the organization.
  • Operational -- In this delegation model, a part of the organization or a specific application (or service) can create special constraints compared with the other components of AD. These constraints might include directory configurations, availability or security. Examples of this model include military, hosting, extranets and outward-facing AD environments.
  • Legal -- In this delegation model, a legal requirement forces a part of the organization to function in a more secure or specific way. This might require restricted access to AD services or data. Examples of this model include financial and government agencies.

AD can be structured with domains, trees and forests. The domains are standalone entities that can be associated with other domains. When domains share the same DNS extension, they are referred to as a tree of domains. An example of a DNS extension that meets this criterion is auditingwindows.com. Domains that can exist within this tree include root.auditingwindows.com and company.auditingwindows.com. When one or more trees are spliced together, they form a forest. The forest is a grouping of trees. Each tree will have a unique DNS namespace.

Once AD structural boundaries are established, consider the AD security boundaries that are associated with the structural boundaries. The following list highlights common boundaries that are associated with AD security:

  • Enterprise Admins group --A built-in group that has forest-wide scope, the Enterprise Admins group's capabilities include being able to administer any user, computer, service or object in any domain within the forest. There is no higher security group than the Enterprise Admins group.
  • Schema Admins group -- This group is very important because it also has forest-wide scope. However, the capabilities are only for the schema. The schema controls the creation of the objects within the forest and dictates the properties of each object.
  • Domain Admins group -- This group has been around Windows domains for a long time, and the scope remains the same. The Domain Admins group can only administer the domain for which it is created. (There are other important groups that only have domain scope. These groups are not as powerful as the Domain Admins group.)
  • Schema -- The schema is the core structure underlying every new object that is created. As I previously mentioned, the schema determines the properties for each object. If a change is made to the schema, every object in the forest can be affected.
  • Account policies -- The account policies control the passwords for domain user accounts. The account policies include password policy, account lockout policy and Kerberos policy. These settings do not pass the domain boundary. For example, if a password length of eight characters is set at the top-level domain in a tree, the other domains in the tree will not inherit the eight-character password. Instead, they have their own unique account policy that dictates this setting.
  • GPO scope -- GPOs are designed to control objects within their scope of influence. The different scopes of influence that a GPO can have include site, domain and OU.
  • Group scope -- There are different types of groups within AD. The groups have a wide variety of scope based on the configuration of the domain. The different groups include domain local, global and universal. Domain local groups are only available to computers in the domain in which the group is configured. (If the domain is still in mixed-functional level, the domain local groups will only be seen by the domain controllers, not any of the other domain members.) Global groups are designed to function within the same domain only. Universal groups are new to AD and are designed to cross domain boundaries.
  • Delegation of administration -- Delegation of administration is designed to have a boundary based on your needs of administration. Typically, delegation of administration is designed at the OU level, but that is not a strict rule. There are needs and reasons to design delegation of administration at different levels, including site, domain, and object.

When you are considering the boundaries and design of AD security, you need to have a clear understanding of what the delegation drivers are. Delegation drivers dictate how and why the AD structure is designed. Unfortunately, there is not an easy method of determining the delegation drivers and the final design of AD from those drivers. The benefit of the flexibility provided by this setup is that there is no wrong answer, simply degrees of effectiveness.

Thus, before AD is implemented, there needs to be a planning phase. This phase might take longer than you anticipate, with so many design considerations. Security is one of those considerations -- especially the delegation model and the GPO implementation plan. I have seen planning phases that take as long as six months, but the time required depends on the size and complexity of the company network.

After the planning phase is the testing phase. The testing phase can determine whether the results of the planning phase are effective or, as is often the case, are not. This phase gives ample time to develop a new plan that can then be tested. I have seen testing phases that also last six months or longer. The longer test phases usually result from additional planning phases to work out any kinks in the design.

As the security boundaries of AD are considered in the planning and testing phases, thought must be given to the level of autonomy, isolation or a combination of both:

  • Autonomy -- Provides administrators with the ability to independently manage all or part of the service management and/or the data stored in AD.
  • Isolation -- Provides the administrators with the ability to prevent other administrators from controlling or interfering with service management and/or the data stored in AD.

With delegation of administration, almost any level of autonomy can be accomplished within any one domain. Regarding isolation, there are some key questions to ask to determine the appropriate level:

  • If there is a department that is asking for isolation from the other departments, what would be sufficient for them?
  • Would a top-level OU in the domain be enough?
  • Do they require their own domain?
  • Is it required that they be a domain in their own forest?

These are decisions that must be made with consideration of all aspects of AD security. Autonomy is much easier to accomplish than isolation. The reason is that administrators who have autonomy understand that other, higher-level and ranking administrators have the ability to control the same information that they control.

Click for the next excerpt in this series: Select the proper directory structure.


Click for the book excerpt series or visit Realtimepublishers.com to obtain the complete book.

Dig deeper on Microsoft Active Directory Security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close