UVM Active Directory
Forest Design

The UVM Active Directory infrastructure consists of a singe Active Directory forest.  This forest contains two Active Directory Domains: AD.UVM.EDU and CAMPUS.AD.UVM.EDU.  The AD.UVM.EDU domain allows for the partitioning top-level administrative functions (such as directory schema management and PKI management) from the CAMPUS domain. 

The forest is running at the "Windows 2003" functional level.  No domain controllers are running pre-Windows 2000 operating systems.  There are no Windows NT 4.0 systems in the forest.

The AD.UVM.EDU domain also serves as a connection point for trusts with other Active Directory domains that may be required in the future.  No services other than Active Directory are offered from within the top level AD.UVM.EDU domain.  The AD.UVM.EDU domain has two domain controllers: dc01.ad.uvm.edu, and dc02.ad.uvm.edu.  Both are running the Windows Server 2003 Standard Edition operating system.  One of these servers is located in the Waterman data center, and the other in the Mann Hall data center.  The physical separation of these servers will help to ensure the availability of core Active Directory services in the event of a disaster in one data center.

The CAMPUS.AD.UVM.EDU also has two domain controllers: cdc01.campus.ad.uvm.edu and cdc02.campus.ad.uvm.edu.  Both domain controllers are running the Windows Server 2003 Enterprise Edition operating system.  As is the case with the AD.UVM.EDU domain controllers, one server is located in the Waterman data center, and the second is located in Mann Hall.  All production Active Directory-integrated clients and servers are joined to the CAMPUS.AD.UVM.EDU domain.

Kerberos is the preferred authentication protocol for all services within the forest.  Kerberos provides a secure, password-based authentication system that is superior (in most ways) to the older authentication mechanisms available to Windows servers and clients.  All Kerberos authentication within the forest can be initiated from the "MIT Kerberos" realm "uvm.edu".  External Kerberos authentication is made possible though a one-way transitive trust between the CAMPUS.AD.UVM.EDU domain and the MIT Kerberos Realm.  This trust relationship allows Active Directory clients to use the same authentication service as most UNIX-based clients and applications.  The MIT Kerberos realm is the authoritative source for user identities and passwords.  All password changes are initiated from the MIT Kerberos realm and propagated to the CAMPUS.AD.UVM.EDU domain.  In the future, it may be possible for Windows desktop computers to sign-in to their computers once, then obtain access to applications and services running on both Windows and UNIX servers without having to enter another set of credentials.  Also, it is hoped that integration between Windows Active Directory and MIT Kerberos will continue to mature, and that all authentication in the domain will initiate from the MIT Kerberos realm.

The "uvm.edu" Kerberos realm consists of three servers running the Red Hat Enterprise Linux operating system: kerberos.uvm.edu, kerberos-2.uvm.edu, and kerberos-3.uvm.edu.  One of these server is located in the Mann Hall data center, and the others are located in the Waterman building.

A rather simplified representation of the client login process is represented below:


  1. The client computer (Windows 2000/XP, or Mac OS X) sends an initial authentication request (AS channel) to an available Kerberos server in the uvm.edu realm.
  2. The kerberos server returns a "Ticket Granting Ticket" (TGT) to the client.
  3. The client presents its uvm.edu TGT to an available domain controller in the CAMPUS domain
  4. The domain controller hands the TGT to a Kerberos server in the uvm.edu realm for verification.
  5. The Kerberos server verifies that the TGT is valid.
  6. The domain controller generates a TGT for the CAMPUS domain and presents it to the client.  The client can use this TGT to obtain access to other services within the CAMPUS domain.
  7. The client wishes to obtain access to a resource on a member server in the CAMPUS domain.  The client presents its CAMPUS TGT to the member server.
  8. The member server hands the TGT to an available domain controller for verification.
  9. The domain controller confirms that the TGT is valid.  A service ticket for the member server resource is granted.
  10. The service ticket is forwarded to the client computer.  This ticket is used for future authentication attempts against the same resource until the granting TGT expires.