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.