Having set the scene for this series of posts, the first area to examine is Active Directory forest and domain design.

Bearing in mind the key principle that requirements should dictate design, and that the solution should be as simple as possible, whenever possible, AD designers should look to consolidate and a single forest (with a single domain) should be the starting point, after which any requirements for scaling out can be considered.

Reasons for implementing multiple forests include:

• Multiple schemas (to avoid application conflicts).
• Resource forests (deliberate isolation).
• Distrust of forest administrators (autonomy).
• Legal regulations around application/data access.
• Requirements to be disconnected for long periods (e.g. on a ship).

Forest design models

Single organisational forest

The single organisational forest is the starting point. In this model, users, computers and applications are all in the same forest, providing a simple Active Directory. One major advantage of having a simple AD, is that many application designs will also be simplified (e.g. Exchange Server or MOSS) and delegation of administration is still possible; however it is absolutely essential that forest-level administrators are trusted.

To mitigate the risk of rogue administrators, many organisations rely on detection (auditing and monitoring security logs – flagging any events after the fact). In many cases the effort of implementing an extra forest outweighs the risk of an exploit from a rogue administrator. Other mitigation steps include keeping highly privileged groups (e.g. Enterprise Admins and Domain Admins) empty (or at least down to a minimal number of users) and closely monitoring membership as well as implementing two-factor authentication for highly privileged accounts.

Multiple organisation forest model

The multiple organisation forest model is applicable where there are distinct business groups that require limited sharing of resources whilst retaining autonomy and isolation. In this model users, computers and applications all exist within their respective forests and a trust (1 or 2 way, as appropriate) is established, with selective authentication to control the rights granted from one forest to the other.

This model can be costly and often causes additional complexity (e.g. if Exchange Server is used in the two organisations, then identity management tools may be required for calendar and contact information).

Shared resource forest model

According to Microsoft, the shared resource forest model is gaining in popularity as it provides flexibility as organisations are created and merge but require some sharing of resources. Users and computers exist in the appropriate account forests and trusts are created as necessary to access application(s) in a separate resource forest.

With this model, an application such as Exchange Server would be installed into the resource forest (as a single organisation) and the users in the account forests would see the global address list from the resource forest, avoiding the need for directory synchronisation tools.

Potential downsides of this approach are the extra servers that will be required and the corresponding management overhead; however it is flexible and is commonly deployed.

Shared account forest model

The shared account forest model is similar to the shared resource forest model except that a common account forest is used for all users and computers, with various resource forests deployed for restricted access to data and applications and corresponding trust relationships with the account forest. With this model, users can log on anywhere but some control is exercised over their access to applications and data.

This model might also be used in an extranet scenario – for example MOSS in an extranet forest but with access provided to internal accounts using a forest trust or through ADFS.

Considerations for domain design

Having decided on the overall forest structure, domain design needs to be considered and this is also simplified where a single domain exists within each forest (this is the most straightforward, and hence least expensive, option to implement, manage and recover). Multiple domains may need to be considered:

• Where there is a large number of frequently changing attributes.
• To reduce replication.
• To control replication over slow links.
• To present legacy Active Directory structures.

With Windows Server 2008, it is no longer necessary to implement a separate domain where an alternative password policy is required (e.g. PIN access for mobile users) as Active Directory Domain Services supports fine grained password policies. Note that these policies are not applied at an organizational unit (OU) level but through group membership or at an individual user level. To aid when troubleshooting application of multiple policies, Microsoft recommends that security groups are used for policy application and users added to groups accordingly.

A domain is a replication boundary but whereas with Windows 2000 network links were poor, these days bandwidth is more plentiful and controls may be exercised over replication. Microsoft considers that the only real hard limit is the maximum number of domain controllers, which was around 1200 under Windows Server 2003 due to the limitations of sysvol replication using the file replication service (FRS). With Windows Server 2008 this is no longer a concern, once the domain has been switched to use DFS-R for replication.

In short, there are very few technical reasons for separate domains; however this may be influenced by political concerns.

Forest and domain functional levels

Forest and domain functional levels can drive requirements for domain design, with consideration due to migration vs. an in-place upgrade. On the face of it, in-place upgrades seem simple, but the health of the existing AD needs to be considered. If the domain has been upgraded previously from Windows 2000 to 2003, there may be older groups in place which do not use linked value replication, or there may be issues around strict replication consistency.

The basic changes at each level are:

• Windows Server 2003 interim forest functional level:
  • Linked value replication.
  • Different replication compression ratios.
  • Improved knowledge consistency checker.
• Windows Server 2003 forest functional level:
  • Forest trusts (and selective authentication).
  • Deactivation of attributes within the schema.
  • Domain renaming.
  • Read only domain controllers (requires Windows Server 2008, plus schema updates).
• Windows Server 2008 domain functional level:
  • Fine-grained password policies.
  • DFS-R for sysvol.
  • Last interactive logon information.

Domain naming

Domain naming ought to be the simple part of the design; however it is often heavily influenced by politics. Whilst domain renames are possible, it’s generally not advised due to the potential impact on other applications.

For each domain, there are two names to consider – NetBIOS and DNS.

The NetBIOS name must not exceed a maximum length of 15 characters and must be unique on the network.

Meanwhile, Microsoft recommends that the DNS name does not replicate an existing Internet domain name, is registered with Internic (to prevent future conflicts – this also means that once-common naming conventions such as .local are no longer recommended).

In general, the NetBIOS and the domain portion of the DNS names should be made to match one another as many tools expect one to be derived from the other; however single label names should not be used as they cannot be registered and may cause issues with certain applications (Microsoft knowledge base article 300684 has more details). Also, the name should not represent a business unit or division (as this is likely to change over time).

Summary

After following the advice in this article, the forest and domain structure, level and naming should all be clear.

In the next post in this series, I’ll take a look at organizational unit design.