So far in this series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, I’ve looked at forest and domain design and organizational unit (OU) structure. This post discusses some practices for the application of group policy objects (GPOs).

Group policy is a powerful feature of Active Directory but it’s important to consider management at the design stage as GPO management can become problematic if not carefully controlled.

At present, Microsoft Consulting Services is advising the use of:

• Separate OUs for user and computer settings – this makes GPO application easier to troubleshoot, especially if complex features such as loopback (see Microsoft knowledge base article 231287) are in use.
• Small GPOs with fewer settings where possible – whilst this will increase the overall number of GPOs to process, it aids management (easy to keep track of which GPO is doing what) and if a policy change is detected by a client at startup or during a scheduled refresh downloading a smaller GPO will assist with performance.

Advanced Group Policy Management (AGPM) (formerly DesktopStandard GPOVault) is a feature of the Microsoft Desktop Optimisation Pack (MDOP) – a software assurance benefit for Microsoft customers with particular licensing agreements. It allows the creation of a change control and reporting workflow so that GPOs are not created at will by administrators but are implemented in a controlled manner (i.e. check out policy, offline edit, check in policy, gain approval, release new policy). AGPM v3.0 (which is due for imminent release) will provide new features including increased granularity, a role-based administration model and improved reporting.

Windows Server 2008 also implements a new feature called Group Policy Preferences (formerly DesktopStandard PolicyMaker Standard Edition and PolicyMaker Share Manager). Group Policy Preferences is included within the Group Policy Management Console in Windows Server 2008 but requires client side extensions to be installed on downlevel clients (see Microsoft knowledge base article 943729. The technology allows the configuration of items that are not normally possible in Group Policy (e.g. granular targeting of printer assignment) to avoid the use of login scripts (which increase login times and create additional management overhead).

In the next post in this series, I’ll take a look at the design considerations for creation and use of security groups within AD.

In the previous post in this series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, I looked at forest and domain design. This post continues with a look at organizational unit (OU) structure.

The OU structure is not exposed to users but can make a big difference to the management of Active Directory objects. It is very flexible and therefore easy to change but change costs money and has a potential to impact on production applications (so should be avoided where possible.

Consequently, there are a couple of guiding principles to be followed:

1. Design the OU structure for the delegation of administrative responsibility.
2. Design the OU structure for group policy object (GPO) application.

Delegation of administration should be given priority, because GPO application can also be filtered using security groups, but Microsoft does also recommend the following:

• Do not move domain controllers out of their own OU (some applications may rely on well-known GUIDs and default GPOs).
• Do not move built-in users and groups from the Users container (due to the potential impact on the monitoring of ACL changes using AdminSDHolder – see Microsoft knowledge based article 232199).
• If Windows Server 2008 is being used protect OUs from accidental deletion (this will be enabled for new OUs but not for legacy OUs from an in-place upgrade.

There is no “correct” way to design an OU structure – as the appropriate model varies from organisation to organisation but one approach to OU design is to base the top level OUs on the object type and then subdivide by role. Another approach is a geographic top level (countries do not change very often…) but the most important point is to follow an appropriate administrative model and where different objects are managed by different administrative teams, consider delegation. One thing that is almost universally agreed upon is not to replicate the organisational structure – security groups can be used for this (and are much easier to manage – e.g. for filtering GPO application).

In the next post in this series, I’ll take a look at design considerations for group policy objects.

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.

A few weeks back, I wrote a series of posts on the architectural considerations for designing a predominantly-Microsoft IT infrastructure, based on the MCS Talks: Enterprise Infrastructure series (Introduction, Remote offices, Controlling network access, Virtualisation, Security, High availability and data centre consolidation).

Session 2 of the MCS Talks series looked at Active Directory (AD), so I’m kicking off a new series of posts here based on the information from that webcast, supplemented where appropriate with my own experiences.

The original webcast on which this series was based was presented by Andrew Hill and Rob Lowe (who are both consultants with Microsoft Consulting Services in the UK) and they stressed that there are 6 tenets to AD design which are inextricably linked:

• Complexity.
• Cost.
• Fault tolerance.
• Performance.
• Scalability.
• Security.

The main point that they wanted to make was to let requirements dictate design (to avoid over-complicating the solution) and that is the focus in each of the posts that will make up this series.

The rest of this series will examine key design considerations for forest/domain design, organisational unit structure, group policy objects, security groups, domain controller placement, site topology, domain controller configuration and DNS. Two important areas that have not been included though are backup/recovery of AD (I’m reading a book on AD disaster recovery and will post my review soon) and delegation of administration. Also, some previous knowledge is assumed – this is not an introduction to Active Directory.

Microsoft has also provided a collection of AD design resources on the MCS Talks blog.