- Introduction
- Active Directory (AD)
- A Multiple AD Domain Structure
- The Future Gets Brighter with Windows .NET Server
- The Power of Active Directory
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A Multiple AD Domain Structure
Creating a PFRD automatically gives you options for development support. Who hasn't had several discussions with development staff when trying to define the Windows NT domain structure? Most developers wanted a domain that was separate from the production domain. Unfortunately for these developers, most organizations opted for a single Windows NT domain. Developers had to live with the same restrictions as everyone else. The single Master domain was the right choice for Windows NT, but it's not quite the same in the Windows 2000 environment.
In AD, it's proper to aim for a single, global child production domain. In fact, this domain replaces the single Windows NT domain. But Windows 2000 allows you to go much further. For example, you can decide that your production domain will no longer host "generic" accounts—accounts that represent a function rather than a specific user's name. This means that you can create additional function-based domains such as Training, Development, Staging, etc. that can be used to store accounts such as Student1, Student2, User1, User2, and so on. This also means that you can now constantly track user activities within your production domain, ensuring that tight audit policies are always in place for every object of this domain.
While most organizations will also require separate development forests, these are only required to support development that affects the very nature of the Active Directory itself—development that affects the AD Schema. In most organizations, this represents less than 10% of all internal development. Placing development and other functions in another forest limits its practicality, since there are few means of communications between forests in Windows 2000. In fact, the communications between AD forests looks a lot like the communications between Windows NT domains. Figure 2 represents a series of AD forests segregated by function, along with a production forest including multiple functional domains.
)
Figure 2 An example of a functional forest and functional domain
design.
Since a domain is a boundary for security policies, it's safe to place a development domain within the production forest so long as you ensure that none of these developers needs to work on the schema. The advantages are clear: Developers can work in a domain where they are given some administrative rights and more open security, and through the transitive trust structure of Windows 2000 they can access their production environment directly without having to log off or open a new session. Figure 3 illustrates this concept.
)
Figure 3 Developers are hosted within a development domain and use
Universal groups to access production data.
Depending on IT's system management policy, the developer PC can either be hosted within the development or the production domain, since both Windows 2000 and XP support the ability to store a computer account within one domain and a user account within another. In addition, developers can perform application stress testing using generic accounts while having little or no impact on the production domain because everything is contained within their own domain.
Giving administrative rights to developers doesn't mean compromising domain controller security. It's important to ensure that DCs remain secure at all times in every shared forest scenario.