Design Considerations

This section contains additional information to consider before starting your centralized management deployment.

Security

It is vital that the services comprising centralized management are secured and managed in a systematic way because they are the core of the authentication and authorization mechanisms of the solution. There are many potential points of access for intentional or accidental security violations, and each needs to be addressed in order to maximize security and reliability of the overall hosting service. Security risks include:

• Access from the Internet when located on the perimeter network (single network interface card [NIC] scenario).

• Access from a dedicated server where the customer has local access.

• Access from a shared server through an exploit.

• Internal access from non-privileged users.

• Disgruntled employees.

• Physical exploit/theft.

• Access from a trusted/external domain.

Planning a Public Key Infrastructure for a Hosting Environment

A public key infrastructure (PKI) based on Microsoft Windows Server 2003 Certificate Services provides a means by which organizations can secure critical internal and external processes. Deploying a PKI allows you to perform tasks such as:

• Securing e-mail from unintended viewers.

• Enabling secure connections between computers, even if they are connected over the public Internet or through a wireless network.

• Enhancing user authentication through the use of smart cards.

• Digitally signing files such as documents and applications.

If your hosting environment does not currently have a PKI, begin the process of designing a new PKI by identifying the certificate requirements for your environment.

If your hosting environment already makes use of a public key infrastructure based on Microsoft Windows NT version 4.0, Microsoft Windows 2000, or third-party certificate services, you can improve your PKI capabilities by taking advantage of new and enhanced features in Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. When you have completed the PKI design process, you can deploy a public key infrastructure that provides solutions for all of your internal and external security requirements.

For more information about PKI deployment, see Deployment Planning (Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure).

For more information about planning to use the Rooted Trust Model, see Designing Your CA Infrastructure.

Storage Requirements

Active Directory can only be installed on local drives; system area network (SAN) and network attached storage (NAS) are not supported. The storage requirements depend on the number of objects that are stored in the directory. For performance reasons, we recommend that you have separate spindles (disk drives) for the operating system, for the Active Directory database, and for log files and Group Policy files (depending on the intended scale of your environment).

Reliability and Availability

For reliability and availability we recommend that you do the following:

• Configure Active Directory on at least two domain controllers.

• Use a regular backup and change and configuration management strategy.

Server Support for the Directory Design

The two basic design considerations for centralized management services provided by Active Directory are:

• Physical server support - The critical nature of the services supporting centralized management demand server redundancy. Thus, you must dedicate at least two servers as Active Directory domain controllers. The inherent replication services in Active Directory will ensure that the two servers stay in sync with each other. The use of two servers also distributes the service load, helping to ensure service availability.

• Basic hierarchical design of Active Directory - The centralized management implementation recommends a configuration of Active Directory that is simple and straightforward - it consists of a single shared domain and shared forest. This recommended configuration is considered sufficient to meet the vast majority of hosting requirements. This basic design of Active Directory, including forests, domains, and sites, should be as simple as possible.:
  There is a tendency to develop a more complicated directory design than is necessary for hosted services. Each additional forest in the design creates additional issues. These include replication traffic, how to prevent users from browsing the entire forest, and how to administer all of the forests. Such issues become increasingly difficult as the directory infrastructure becomes more complex.:
  In designing the Active Directory configuration for a hosting environment, you need to consider a number of fundamental issues such as:

  • Whether to partition forests into manageable OUs for separate subscribers or to dedicate entire forests to a single subscriber.

  • Whether a single administrative context is needed for all of the forests that are hosted.

  • How many organizations you expect to subscribe to the service, and how many individual users you expect to support.

  • The degree to which your customers require the ability to administer or manage their own Microsoft Exchange servers or Web sites.

There are two deployment models for creating a directory-enabled infrastructure:

• A shared domain, shared forest model where all customers live in the same domain and forest (recommended for a centralized management deployment).
  Note: The Solution assumes this implementation to be its centralized management infrastructure

• A dedicated forest of forests where each hosted customer receives its own forest. See Alternative Active Directory Design Options in this document for more information.

Network Requirements

The domain controllers do not need direct Internet access. All services using the directory service for authentication or authorization need access to the service, while the domain controllers need access to all domain member servers to deploy group policy and enable authorization traffic. To manage this in a secure fashion, the network comprises two segments; and internal network and an external network.

Servers hosting core Active Directory services should be located on the internal network and should be well-protected using firewalls from the perimeter network, and the network exposed to the Internet. The exposure must follow the "least privilege model," where all access that has not been configured on an as-needed basis is automatically blocked. This will require careful planning and documentation, as various services require certain types of access to Active Directory.

If the service provider has more than one physical site, other network considerations come into play. In particular, you may need multiple Active Directory sites to ensure that critical Active Directory services are available in each physical site. In this case, you must configure the network and firewalls to provide secure channels using IPSEC and L2TP for Active Directory replication.

Application-level directory services are hosted within the perimeter network to make these services available to the customer application code, which is also hosted there. The perimeter network firewall should protect such services through the principle of least privilege. There should be no reason to access these services directly. You should access them from other application code that is hosted on the perimeter network. Lightweight Directory Access Protocol (LDAP) traffic from the Internet should not access these services.

Application-level directory services are hosted within the perimeter network to make these services available to the customer application code, which is also hosted there. The perimeter network firewall should protect such services through the principle of least privilege. There should be no reason to access these services directly. You should access them from other application code that is hosted on the perimeter network. Lightweight Directory Access Protocol (LDAP) traffic from the Internet should not access these services.