On the ActiveDir.org list there has been some good discussion about whether the multi-domain forest is still considered a valid design option. This article attempts to crystallise the discussion for use as a reference for those involved with the design or review of forest models.
The general consensus is that single domain forests are now the preferred design option for all but the most marginal cases. Note that this does not preclude the use of multiple forests within a single organisation. For example, the use of the Exchange Resource forest in environments that have a distributed NOS architecture but a centralised messaging architecture is common in larger organisations.
Background
When Active Directory was first launched along with Windows 2000, a number of well-known global IT consultancies adopted multi-domain models. In fact a single domain forest in the early days of AD was rare outside the lab environment. This may have partly been a hangover from the days of NT 4.0 when domains proliferated everywhere. Since then there have been a lot of changes to AD as well as a change in thinking about domains as security boundaries.
When Windows 2000 first arrived a popular forest model was the 1+1 domain approach. There would be the so-called dedicated or “empty forest root” domain, hosting a few protected groups and accounts, and a second domain (sometimes in a separate tree) containing all the users, groups, computers, etc. The rationale behind this model was to protect the keys to the kingdom (i.e. the Enterprise Admins, Schema Admins, root Domain Admins groups, as well as other accounts and groups considered sensitive). At that time the domain was thought to be a security boundary as well as an administrative and replication boundary.
A little while after Windows 2000 had been in place the realisation dawned that the domain was not a true security boundary. It is, for example, possible for someone with Domain Admins rights in a child domain to gain control of the forest. I won’t provide details of the mechanism here as a number of AD implementations are still susceptible to it.
A number of other reasons have been put forward for a multiple domain forest model. Are any of these still valid? Let’s take a closer look at the more popular reasons.
The multi-domain model allows for separate password policies to be defined
In Windows 2000 and 2003 Active Directory password and account lockout policies were defined at the domain level. These could not be overridden by policies defined at a more granular level (e.g. user, group, or OU). Windows Server 2008 introduces Fine-Grain Password Policies (FGPPs) to allow a granular definition of password policies. Once defined, a policy that takes precedence over the default domain password policy can be linked to users (not considered best practice) or groups.
The separation of password policies was often cited as another justification for the 1+1 model, with more restrictive policies being defined in the forest root to “protect” certain accounts. Given that Fine-Grained Password Policies are now available, there is no longer a need to have a separate domain simply to provide stronger policies for certain accounts.
Smaller replication scope for DNS zones.
There is an argument that specific DNS zones can be integrated in the root domain, and use replication in the domain scope only, thus reducing the replication overhead.
Since the introduction of application partitions in Windows Server 2003, Active Directory-integrated DNS zone data can be stored in an application directory partition. This allows administrators to manage replication traffic by controlling which DCs hold a copy of the DNS zone data.
An empty forest root offers naming flexibility
The empty forest root is often given a generic name (e.g. root.local). In a world where mergers, acquisitions and divestitures are frequent, the idea is that the generically named forest root allows for child domain changes to occur without having to change the forest name.
If your company changes name, does it really matter if your domain name stays the same? You can hide the name in most cases through the use of UPN logins where the UPN suffix can be different to the domain name. Similarly, company SMTP addresses don’t have to be tied to the domain name.
Despite requiring an unreasonable degree of effort and the fact that it cannot be done with Exchange 2007 in the forest, domain renames are possible since Windows 2003. The fact that you now have ability to rename a domain makes the argument for a generically named forest root less compelling.
While the naming flexibility argument still has some validity, bear in mind that the domain is not a security boundary. In other words are all the domains happy to trust the Domain Admins in other domains? Are they happy to trust the physical security of the DCs in other domains? If not, then separate forests are probably required anyway.
Also consider that despite providing some naming flexibility, the empty forest root approach can actually be more inflexible model than a single domain forest. In a divestiture scenario, for example, it is far more difficult to take out a child domain from an existing forest than it is to simply hand over a single domain forest.
Multiple Domains reduce replication traffic
A common approach for organisations distributed across a wide range of physical sites is to create domains based on region in order to reduce replication traffic between DCs. For example a global company with a forest named acme.com might have child domains named americas.acme.com, emea.acme.com and apac.acme.com. Domain naming contexts are only replicated to DCs within the same domain, which means the regional approach adopted by acme.com could significantly reduce overall replication traffic.
At first glance this appears to be a very sensible approach, especially in environments that have limited bandwidth between sites. This design is tempered with the downside that each additional domain in the forest increases the complexity of the infrastructure as well as administrative overhead and, likely, hardware requirements.
Also consider that Windows Server 2003 introduces the Linked Value Replication (LVR) feature, which improves the replication behaviour for linked attributes. A good example is the member attribute of a group object. Without LVR, the entire attribute value is replicated when a change is made, which can be quite large if you consider a group with 5000 members. With LVR only the item-level change is replicated, not the whole attribute value. The overall effect of LVR can be significant in reducing the replication overhead been DCs.
Windows Server 2003 brought in an improved compression algorithm, which is much faster than the Windows 2000 algorithm and reduces the performance overhead on DCs. Having said that, the compression ratio is not quite as good with the Windows Server 2003 version, so Microsoft recommends reverting back to 2000 behaviour for slow bandwidth links (e.g. 64Kbps or lower) by making a registry change. The point is that, for all but the worst inter-site links, overall replication performance has been improved since Windows 2000.
Conclusion
The majority of arguments for multiple domain forest models (including the 1+1 empty forest root model) can be called into question. Realisation that the domain is not a security boundary has led to a re-think about the viability of multiple domain forests. Technical improvements such as domain renaming and LVR in Windows Server 2003 and the introduction of FGPP in Windows Sever 2008 have further eroded arguments supporting a multiple domain approach. Multiple domain models also often incur higher capital and operating costs whilst delivering, at best, marginal benefit.
The single domain forest model should be considered the best practice standard, with a multi-domain model being reserved for marginal cases where political or environmental factors (such as extremely low bandwidth) come into play.
0 comments:
Post a Comment