Analyzing Security Requirements for Active Directory Services

The security requirements of a business have a major effect on the design of Active Directory. The security plan that's developed by the design team should be based on the security requirements of the business. Security has become a hot issue when designing a network infrastructure. As the need for enterprise networks has increased and the need to distribute internal data among employees become a necessity, businesses have implemented strict security policies to secure their network resources. When assessing a business's security requirements, you need to consider user security needs and local (geographical) security requirements.

Analyzing Current Security Policies, Standards, and Procedures

Almost all businesses implement various forms of security to protect network resources and lower the total cost of ownership (TCO). When designing Active Directory, it's crucial that the current security practices of an organization be assessed so that they can be included in the new design. For example, an organization might require some of the following security requirements for its users:

• Preconfigured desktop for all users

• Limited capability for users to modify the configurations assigned to them

• Secure logon (Smart card or EAP, for example)

• Application restrictions

• Sensitive data available to select groups

• Encrypted data for mobile users

• PKI infrastructure implementation

• RADIUS for remote connection authentication

Those in charge of the Active Directory design need to be aware of these security needs so the Active Directory infrastructure can support them.

One of the reasons why a multiple-domain structure might be created is to meet the security requirements of a business. If the business implements decentralized administration and needs to maintain a distinct security boundary between its different business units, a multiple-domain structure has to be established. Creating a separate domain within the forest for each business unit will allow each unit to maintain its own administration.

If the different locations or departments within a business have different security needs (such as password requirements) or if a single security policy for the entire organization cannot be agreed upon, multiple domains might have to be created. That way, the administrators from each domain can establish security policies that meet their specific requirements.

It's always good practice for organizations to implement security standards and procedures. Doing so ensures that the required level of security is maintained. Make sure that you're familiar with the various standards and procedures implemented within an organization so they can also be incorporated into the Active Directory design.

Another point to consider when assessing the security practices within an organization is that the security requirements and needs might vary throughout. There could be instances in which one location within an organization has very different security needs than another location. If this is the case, the design of the Active Directory infrastructure should reflect this.

For example, assume that an organization has several locations throughout the world. After completing an assessment of the local security needs, it might be determined that the offices in the United States and the offices in Europe have different security requirements.

You might be wondering how this information would affect the Active Directory design. To meet the different security needs of two different geographical locations, the design team might decide to create separate domains. Doing so would allow each office to implement its own security. The point is that a company's security requirements will have a major effect on the creation of forests, trees, domains, and organizational units. Therefore, they comprise an aspect of planning that deserves attention.

A particularly critical aspect of domain design is understanding all the security requirements of an organization. Security policies are configured at the domain level, so if part of an organization requires specialized security, it might result in the creation of multiple domains.

Analyzing the Effect of Active Directory on the Current Security Infrastructure

The migration to Windows Server 2003 and Active Directory should affect the security infrastructure in a positive way and introduce many benefits. This is not to say that everything will remain the same because there will be expected changes.

Before you begin the implementation of Active Directory, you need to determine the effect that it will have on the existing environment. After you've assessed the security policies and procedures implemented by an organization, you know what the environment currently looks like. The next step is to take this information and determine what the environment will look like after Active Directory has been implemented. This enables you to determine how certain policies and procedures will be affected and changed with Active Directory. Some of these might remain unaffected and others might experience a complete overhaul.

Identifying the Existing Trust Relationships

After you've identified the type of domain model that is currently implemented, you need to assess the trust relationships that currently exist, if any. The trust relationships define the domain boundaries that users can cross for resource access. These boundaries will need to be maintained in the Active Directory infrastructure.

Windows NT 4.0 Trusts

For those of you who made the transition from Windows NT 4.0 to Windows 2000, one of the major differences was how trusts were implemented. In Windows NT 4.0, there was only one kind of trust relationship that could exist: one-way non-transitive trust.

In a Windows NT 4.0 environment, trusts are not automatically created. They must be established manually by an administrator. Trusts are also one way, meaning that they are not transitive like the trusts found in Windows Server 2003 and Windows 2000. For example, if A trusts B, B does not trust A. For users in two domains to share resources, two one-way trusts must be configured.

Windows Server 2003 Trusts

Three different types of trust relationships can be implemented in Windows Server 2003 to allow users to gain access to resources located in other domains: transitive, shortcut, and external trusts. Transitive trusts are automatically established, whereas shortcut and external trusts must be explicitly defined.

A transitive trust is a two-way trust that is automatically created between parent domains and child domains, as well as between the root domain of a forest and any new trees. The trust path created from a transitive trust makes resources throughout the forest accessible to all users (see Figure 2.5).

Figure 2.5. Windows Server 2003 two-way transitive trusts.

As already mentioned, when a user attempts to access a resource in another domain within the forest, the trust path must be followed. Depending on the structure of the Active Directory hierarchy, the trust path between two separate domains can be long.

In a case such as this, creating a shortcut trust can shorten the trust path. A shortcut trust is basically a transitive trust (a two-way trust); the difference is that it must be explicitly defined or created. Creating a shortcut trust between two separate domains within a forest can improve the authentication process discussed in the previous section.

The third type of trust that can be implemented is an external trust. An external trust is similar to a trust set up between Windows NT 4.0 domains. It is a one-way trust and must be manually created.

Within a forest, two-way trusts are established automatically. In Windows Server 2003, two separate forests can be linked together by creating a one-way trust or a two-way transitive trust. A two-way transitive trust is created between two forest root domains to establish a transitive trust relationship between all domains in each forest.

For the most part, trusts in Windows Server 2003 and Windows 2000 are the same. However there is one difference to be aware of. Windows Server 2003 now supports a forest trust. This allows two separate forests to be linked together with a one-way or two-way transitive trust. Doing so can form a transitive trust between every domain in each forest. In Windows Server 2000, when users located in one forest needed access to resources within another forest, a one-way nontransitive trust had to be explicitly defined. This could result in several one-way trusts being established between domains.