The Administrator Shortcut Guide to Active Directory Security Chapter 2

{LANG_NAVORIGIN} Operating System Microsoft
By: Derek Melber, Dave Kearns, and Beth Sheresh, 04/06/2005



[Editor’s Note: The following excerpt is from Chapter 2 of the free eBook The Administrator Shortcut Guide to Active Directory Security (Realtimepublishers.com) written by Derek Melber, Dave Kearns, and Beth Sheresh and available from a link at http://cc.realtimepublishers.com/portal.aspx?pubid=289.]

AD security is not a single setting; it is a compilation of settings that is multifaceted and can become very complex. The default AD security settings handle the basic control of objects such as user accounts, group accounts, and computer accounts. For small companies, this default configuration might be sufficient. For larger companies, the built-in security will be quickly outgrown quickly and additional security settings and design must be considered and implemented. Regardless of the size of the company, a firm grasp of AD security settings is necessary to ensure a secure and stable IT infrastructure.

If security is not established early in the AD environment, the entire environment can spiral out of control quickly. This spiraling is a result of the number of security settings that can be set, which grows almost exponentially as additional objects and features are added to AD—consider that a single OU has nearly 1000 permissions that can be set to control its contents. This complexity requires consideration as early as possible in the implementation of AD. During the design phase of AD, the security of AD objects should be considered and documented. The objects that need to be considered for security include:

• Domain controllers
• Servers
• Client computers
• User accounts
• Group accounts
• OUs
• GPOs

The security that you design for AD must be implemented properly to be effective. Failure to follow your design documents can leave AD vulnerable to attacks from both within and outside of the LAN. In addition, AD security is very difficult to audit and track if not set up properly. In some cases, it will be easier to start over rather than to attempt to secure the AD environment after it has been installed and configured with many objects, settings, and features.

Another key aspect of AD security is management. The management phase is critical because it is at this stage that ongoing AD security must be maintained. Whether it is giving users the ability to add members to groups or locking down computers that are located in the reception area, the management of the security for AD must be procedural and consistent.

In this chapter, we will explore delegation of administration within AD as well as the implications of AD structural design on security. Determining the best AD design for your environment is an important part of effective security. In addition, a key factor in AD security is directory administration.

Directory Administration

Directory administration for Windows AD spans well beyond the AD database. With AD, security needs to be considered for all aspects of object management, GPO management, DNS management, and general domain controller management.

If you are coming from a Windows NT background, AD management might seem foreign, as the management of objects, policies, DNS, and domain controllers could not be segregated in NT. With NT, the objects were only controlled at the domain level; not at any level below the domain. This setup did not allow for delegation of administration to any objects in the domain. There were groups, such as the Account Operators and Server Operators, which allowed for some users to have control over a subset of objects in the domain. However, these groups did not allow for control over a subset of these objects, just the set of these objects as defined by the domain.

This mindset is dramatically changed with AD. In AD, delegation of administration allows for the domain administrators to delegate tasks to junior-level administrators and power users within a department. The same options are available for Account Operators and Server Operators as were available in NT, but with AD, these groups are not a suggested means to give delegated privileges. Instead, delegation of administration is provided at the OU level (it is also provided at the domain level, but the OU level is most common). This delegation is accomplished by configuring the ACL on an OU. As there are almost 1000 permissions associated with a single OU, these permissions allow granular control over which task and function the domain administrator will delegate to the user.

As you can imagine, the options of what can be delegated are almost endless. Thus, delegation of administration must be designed into the AD security and implementation early on. As we will explore, the security related to delegation depends on the OU design and object placement in those OUs. If the AD implementation is allowed to progress without considering the security related to delegation of administration, the process to rearrange the objects to support a desired delegation model becomes very difficult. There are general guidelines that you need to keep in mind as you consider the security of the directory administration:

• The rules that applied to NT usually don’t apply to Win2K and WS2K3 AD. This idea is difficult for many companies and administrators to get past. Much of the failure to consider this reasoning is that the NT methods have been in place for years and seem to work well.
• The AD security design needs to take full advantage of the power of AD. It is a shame to have companies spend so much time, effort, and money moving from NT to Win2K and WS2K3 AD to then not take advantage of the power that AD provides. The power of AD is in the ability to reduce the number of domains, which in turn, reduces the number of domain controllers, administrators, and trusts (administrative overhead) and increases the ability to centrally administer the environment.
• The group design is essential for optimizing the security configuration of the directory. In some OSs, it is common to have built-in groups that provide widespread power over accounts, servers, and services. With AD, these groups can still be used, but it is better to also use other groups that will be delegated administrative control over specific aspects of AD. The reason this design is better is that the built-in groups many times have control over all user accounts or all servers. With the delegation model, groups have control over a subset of the user or computer accounts. In addition to the limitation of object scope, the delegated group usually has a limitation set on the capabilities over those objects as well.

As the security of AD is designed, it will be important to logically organize the administration model. These models are typically implemented through the OU design. There are numerous designs and considerations. The following list highlights common methods for breaking down the administration model in AD:

• Regional—It is common to have administration at the regional level (for example, West, East, Europe, Australia). Doing so provides administrators with the ability to control a larger group of accounts.
• Departmental—Like most companies, administration might be broken down into departments such as Human Resources, IT, Accounting, and Sales.
• Object function—Administration of the directory might also be broken down by object function. It makes sense that the administrator of the HR user accounts is not in charge of the Financial servers. Typical object categories include user accounts, employee computer accounts, IT user accounts, servers, domain controllers, and service accounts.

A poor decision that many administrators make is to duplicate the organizational chart for the company in an attempt to create the structure for security of the directory. Unfortunately, the organizational chart is not an effective AD security model because administration crosses too many boundaries that the organizational chart creates. This causes additional overhead in configuring and managing the directory security.

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 6 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 6 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.
















Your IP address will be sent with this e-mail

From e-mail to e-mail