ADUwCampus outlines a proposed Active Directory forest structure that would conform to the security and management needs of the UW campus. Here in this document we seek to plan out the implementation of a small section of this forest as a proof on concept.
To begin with we intend to establish only three domains. The forest root (UW or uwaterloo.ca), one user domain (UW-GENERAL or general.uwaterloo.ca) and one CS domain (CS or cs.uwaterloo.ca).
As this is not intended to be a production forest, each domain could get away with just two domain controllers rather than three. Thus with three domains, we require six domain controllers to be in service for the establishment of this prototype forest. We could likely create them as a series of virtual servers housed on one piece of server hardware.
We already have a sysprep'ed image of a Windows Server 2008 Enterprise Edition OS. It has already been used as the basis for creating the following production terminal servers.
In principle, it should be a simple matter to take this sysprep'ed Windows Server image and place it onto a newly created virtual machine. Then by simply starting the virtual server the syspreped install process will be initiated for the Windows OS.
Once a stand alone server is created, the conversion to domain controller state is started using the dcpromo command from any command prompt on the new server.
As we did for CSCF's existing AD (see ADDnsConfiguration), we can establish dynamic DNS servers for the prototype forest. They would be installed on two of the domain controllers in the new forest and DCs within the new forest will be DNS clients of these servers and none others. This would create a private DNS space for the prototype forest which will not conflict with the existing CS or UW DNS space. Thus we could create domains with DNS names such as uwaterloo.ca and cs.uwaterloo.ca within the prototype forest that would be unnoticed outside this forest. Indeed, as these domain controllers are only temporary, we would not even need to give them names in Maintain.
If we are to populate the user domain using HR and Registrar information, we shall have to create a forest based certificate authority as we did for our production forest (see ADLdapS and ADLdapSPasswd). This will allow us to maintain on an administration server (like cscf.cs) secure authentication credentials for a service account in the user domain which has accounts maintenance authority.