Over the last few days, I’ve written a series of posts about design considerations for Microsoft Active Directory (AD), based on the MCS Talks: Enterprise Infrastructure series of webcasts. Just to summarise, the posts so far have been:

1. Introduction.
2. Forest and domain design.
3. Organisational Units.
4. Group policy objects.
5. Security groups.
6. Domain controller placement and site design.
7. Domain controller configuration and DNS.

Just to finish the series it’s worth noting that implementing Active Directory is an iterative process. As business and technical application requirements change, so might the optimum directory configuration, particularly after major infrastructure changes such as a network upgrade.

The MCS Talks series is still running (and there are additional resources to compliment the second session on core infrastructure). I also have some notes from the third and fourth sessions on messaging and security that are ready to share so, if you’re finding this information useful, make sure you have subscribed to the RSS feed!

Continuing the series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, this post discusses the design considerations for Active Directory domain controller configuration and DNS, which is critical to any Active Directory deployment.

Whilst the CPU specification for each server running as a domain controller will affect query performance, so can the disk configuration. Active Directory’s disk usage is mostly reads and the few writes are written to transaction logs before being committed to the database. For this reason, the separation of the logs (mostly written) from the database files (mostly read) can improve disk throughput.

Unlike for Exchange Server (where the decision to separate transaction logs from database files is mostly for resilience) with AD’s multi-master replication model providing resilience, the separation of logs and database files on a domain controller is about performance.

Having said that, in the same way that network improvements have allowed for domain controller consolidation, the move to a 64-bit version of Windows Server allows a larger addressable memory space and may even allow the entire AD database to be cached in RAM.

One critical piece of advice relating to domain controllers is when they are running in a virtualised environment. Microsoft recommends that DCs are never snapshotted (even RODCs), due to the potential to re-introduce out of date changes into AD if that snapshot is restored at a later date. Also, DCs should be configured to synchronise their time with the PDC emulator (the default) and not with the virtualisation host.

As I mentioned previously, DNS is critical to the correct operation of Active Directory and, which other DNS servers may be used, Microsoft recommends the use of AD-integrated DNS where possible as this provides a distributed, highly available DNS (effectively, DNS is as available as AD is). This can cause a political debate in some organisations, particularly where there is a heterogeneous network and the non-Windows computers do not use Active Directory. It is possible to configure Windows computers to use Windows DNS (AD integrated) and non-Windows computers to use another DNS implementation but this gets messy where shared subnets are involved (reverse lookup zones will be incomplete). For this reason, wherever possible, consolidation into a single organisational DNS should be considered.

Due to the overhead of managing root hints, Microsoft also recommends the use of the forwarding model and Windows Server 2003 introduced conditional forwarding, which is particularly useful where there are multiple forests, each of which is authoritative for its own zone. Windows Server 2008 improves conditional forwarding by storing conditional forwarding information in AD, rather than on each server (which created additional management overhead) although the standard forwarding is still defined on a per-server basis.

Continuing the series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, this post discusses the design considerations for placement of Active Directory domain controllers and the associated site links.

Domain controller (DC) placement can have a huge impact on user experience (e.g. the impact on logon times) but generally the choices are for placement on hub sites or at satellite (branch) locations and these should each be considered on a case-by-case basis, looking at the network and application requirements.

It’s worth mentioning that available network bandwidth has generally increased considerably since early Active Directory deployments were designed and this will allow for consolidation of the overall number of domain controllers in many cases.

With regards to global catalog (GC) servers, there are very few reasons not to make all domain controllers global catalog servers. Indeed, in a single-domain forest, all domain controllers are effectively GCs. In particular, multi-domain forests using user principle names (UPNs) for logon should consider making each DC a GC.

Read-only domain controllers (RODCs) are new in Windows Server 2008 and provide read-only access to Active Directory. Many people (myself included) have compared this functionality with Windows NT backup domain controllers (BDCs) but that’s not a true comparison as no passwords are stored locally and an RODC cannot be promoted to a full DC. The introduction of RODC functionality is really a security feature to mitigate against the theft of a DC on a high-risk site (e.g. a branch location without a physically secure computer room) and is not really intended for DMZ access to AD. RODCs can reduce replication, as they only replicate inbound traffic; however where users travel between several remote sites they can increase logon traffic as the users details may not be available on the RODC.

The decision as to whether to deploy an RODC or a full DC will depend on:

• Application requirements (e.g. does the application need to write to the directory).
• Site topology (e.g. site link bridging turned off – see below).
• Password replication policy (no account caching will lead to increased WAN/hub DC traffic).

Further details may be found in Microsoft’s RODC planning and deployment guide.

AD site design is closely linked to DC placement and there are two basic models:

1. A logical site for every physical location, assigning subnets for each physical location to the corresponding site.
2. A logical site for every physical location that has one or more DCs, assigning subnets for physical locations to the most appropriate site (based on the underlying network).

Both approaches work well; however with the first option, DNS site coverage must be considered (i.e. ensure that that appropriate name server records are in place). With the second option, clients are automatically referred. It’s also worth considering other applications (e.g. DFSR) and if there is no DC on site then option 1 may make more sense.

Site links should map to the underlying physical network with appropriate costs and replication schedules applied. According to Microsoft, one common mistake is to assign all sites to the DEFAULTIPSITELINK – effectively using a single link for replication and preventing the application of appropriate costs for least-cost routing.

Also, the option to bridge all site links is on my default and, although this is appropriate on a fully routable network (i.e. one where all DCs can communicate freely) it is not recommended for branch offices (due to the overheads associated with the intersite messaging transport and calculating site links) and can be disabled using repadmin /siteoptions (which still allows DFSR to calculate site link costs).

Custom site link bridges may be used where a network is not fully routable (e.g. if firewalls restrict communication between DCs).

The AD replication topology is automatically managed by the knowledge consistency checker (KCC) based on the site link design, automatically creating the connection objects that are required for replication. The KCC-generated topology is used for AD and sysvol replication using the file replication service (FRS); however in Windows Server 2008 sysvol is replicated using DFSR, once the domain functional level is at Windows Server 2008. This increases scalability (removing inefficiencies around FRS version vector joins). For new Windows Server 2008 native domains, replication of sysvol via DFSR is automatic but for upgraded domains there is a migration process to follow.

In the next post in this series, I’ll take a look at the design considerations for domain controller configuration.

Continuing the series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, this post discusses the design considerations for the creation and use of security groups within Active Directory.

First of all, let’s recap on the various group scopes.

Account groups are used to group users and computers. There are two types:

• Global groups may contain members from their own domain (only).
• Universal groups may contain members from any domain in the same forest and their membership is included in the global catalog in order to support mail-enabled groups.

Permissions may be assigned to either type of group (as long as they are in the same or a trusted domain).

Resource groups are used to assign rights and permissions and, again, there are two types:

• Domain Local groups may contain members from any trusted domain in any forest (so are required if there is to be a cross-forest group membership).
• Built-in local groups.

Permissions may be assigned to either type of group but only in their own domain.

Some organisations will ignore the differences in group scope if they are using a single domain environment, as the various types of group will function in a similar manner; however it’s worth considering that the forest/domain design may change over time (e.g. as a result of business changes) and so it is always good practice to use the appropriate group type.

The recommended approach is to add users to account groups, then add account groups to resource groups and use the resource groups to assign permissions on objects.

One consideration is nesting – whilst nested groups help to keep the size of the kerberos token down (Microsoft knowledge base article 263693 is old now, but explains why this this may be an issue), it can also make auditing difficult. Nesting is not to be totally avoided; however the complexity of the nested groups should be carefully considered. In particular, nesting groups into the built-in Administrator group should be avoided as it creates a potential “back door” into a system – anyone with the ability to add users to one of the nested groups can effectively make themself an administrator!

Adding users directly to a domain local group is not good practice but there are situations where it can be useful. For example, if there are two forests with a trust relationship, adding user accounts from one forest into a domain local group in the other may be preferable to adding a global group from the trusted domain to the domain local group, which effectively delegates control over the domain local group to the administrator in the trusted forest – almost certainly undesirable.

Basically, add users to account groups, account groups to resource groups and assign permissions to resource groups where possible but sometimes a little flexibility may be required.

In the next post in this series, I’ll take a look at the design considerations for domain controller placement and the associated site links.

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.