Designing Development Support Infrastructures (Part 3 of 5): Using Active Directory to Support Internal Development
Active Directory (AD)
Active Directory (AD) creates a "secure virtual boundary where people can interact with each other or IT components, all according to their organization's business rules." While the Windows NT boundary was the domain, in Active Directory the boundary becomes the forest. A forest is a series of interconnected domains linked together with automatic transitive trusts. Figure 1 displays a group of Windows NT domains linked with trusts. Since Windows NT trusts are not transitive, every domain must be linked manually if you want to link them all together, whereas in Active Directory all domains within a single forest are automatically linked together, providing common communications and supporting inter-domain data exchange.
Figure 1 Windows NT trusts compared to Windows 2000 trusts.
Active Directory is in fact a distributed database that's designed to manage people and IT components in secure environments. The forest provides the global boundary for the directory. Domains within the forest provide security policy and replication boundaries. Organizational units further segregate data by providing administrative or delegation boundaries. Few organizations today have opted for the one forest / one domain AD design because it rarely meets the needs of large organizations.
First and foremost is the forest root domain. This domain is the first domain created when installing a new AD forest. Since the domain is a replication boundary, it's the container that actually holds objects such as people and PCs. Given the fact that AD's global security boundary is the forest, however, storing every object within the forest root domain is not considered a best practice; there's no segregation between services and objects that have a forest-wide focus versus those that have a domain-centric focus.
For example, suppose you decide to place everything in a single forest root domain. Common user objects and domain management objects will be mixed in with forest management objects. In addition, by default, members of the forest root Domain Administrators group are automatically members of the Enterprise Administrators group, making it very difficult to segregate the roles. But if you create a protected forest root domain (PFRD), which contains very little data, and you then create a production domain as a child of the PFRD, you automatically segregate the roles, since child Domain Administrators are not part of the Enterprise Administrators group.
The notion of PFRD is taking root more and more within IT shops. There are several advantages:
The AD Schemathe structure of the distributed databaseis stored and protected within the PFRD, ensuring the proper operation of the forest.
Forest-wide services such as domain naming and database operation are also stored within the PFRD.
Universal administrative groups such as Enterprise Administrators are protected and segregated from other administrative groups in the forest. This assumes, of course, that every member of the forest is a fully trusted principal.