Twin Domains

The Two Present Campus Active Directories

By Erick Engelke
Engineering Computing
February 11, 2009

There are two major campus active directories (two ADs), ADS and Nexus.  In 2001, the decision was made for the six faculties to deploy Nexus and IST to deploy ADS, each in its own forest. 

The reason accepted at UCIST was that this offered users an everyday account (Nexus) and a high security account (ADS).  While it was true that our technical committee wished to have different levels of passwords, this outcome was not valid because people who work in ADS do not have two levels of password, and the application of ADS passwords for ACE defies the intent of a higher level password.  In my opinion, the real issue was that the two sides could not agree on a working relationship involving trust.

The IST members did not want the faculties to have privileges over faculty users (for changing passwords, etc.) and there were unending debates over how the AD schema would be managed and who could make changes.

AD was a new technological starting point, and for the foreseeable future IST did not want a free-for-all, and the faculties did not want to limit their ability to manage their environment. 

Every issue suffered problems because the technology was not proven.  For example, no one knew how often schema changes would be necessary, so no one wanted to lose the ability to do them.  And the immature nature of Widows 2000 AD was that schema changes could never be undone, introducing a risk in allowing these changes.  Eight years later, we know that schema changes are quite rare, and now they can be undone.

Even linking domains in a forest was unsure at the time.   Today, the forest is the security boundary against malicious attacks, and the domain is the boundary against domain administrative mistakes. 

(http://msmvps.com/blogs/ulfbsimonweidner/archive/2007/08/25/security-boundary-forest-vs-domain.aspx).

ADS is configured as typical MIS department might, with a slant toward a Unix infrastructure at a cost of PC flexibility, and a central body that controls all major technological issues.

Nexus has a mixture of Unix and Windows infrastructure.  It is designed for a federation of largely independent faculties (and independent departments within Engineering), but with a core infrastructure mostly managed by a group in Engineering Computing.

The federated model allows departments to make practical choices for their users.  For example, some applications (like multimedia and GIS systems) have very large data files.  Departments can vary the server technology or allocate greater resources for users as needed, and also make decisions about backups for those unusual files.

In late 2004, the Nexus administrators adopted a new management model with only four domain administrators spread across the faculties.  This was to limit exposure to security risks while maintaining some shared access.  We also created new technologies which improved the AD management abilities to eliminate the need for most administrators to have domain level privileges.  Furthermore, we reached a consensus that students were to be shared; at least one person in each faculty would have the ability to manage all students across all faculties – mostly a concern when one wished to move a student to a different faculty.   Faculty, staff and computers are not shared, so as to reduce security exposure.   This model continues today. (http://www.eng.uwaterloo.ca/~erick/nexus/manage/nexusii.htm)

IST has also softened its stance on password and user account management.  Now selected people in the faculties have some ability to manage passwords and some other limited account information in ADS.  The concessions have brought good will, but are insufficient to actually manage users as would be needed in a shared AD.

Along the way, the definition of being “in Nexus” started having more implications.  Agreements were made regarding common applications defined in shared GPOs, common services installed and shared ways of doing things.  Big systems with a great deal of functionality (including MyWaterloo and its file down/uploading, password management, etc.) were built on shared directory access.  (MyWaterloo now works with ADS too, but not with other campus ADs.)

And things grew.  Nexus now totals over 4,400 computers, and ADS has over 2,100.  More than half of Nexus is used for office computing; its reputation as primarily a student system is outdated.

Nexus administrators make extensive use of Group Policy Objects (GPOs) for automated software delivery.  There are thousands of GPOs for various purposes.  Most of those are duplicates to allow load balancing across multiple servers; they deliver 1,150 distinct MSI based applications.   There is a lot of sharing between the faculties to reduce duplicated effort. 

In ADS, GPOs are to deploy only 26 packages.  Most software installation is done during station imaging and manual user-based installs.

Most of the Nexus/Apex domain controllers are in Engineering with an additional two in Math.  Severing the Engineering connection for any reason would split the system into two functional systems.  Clients would be able to work, but there would be some delays as operations time out and fail over to the redundant systems.

The ADS/UWAD servers are split between the MC and Physics machine room to provide redundancy.

File system redundancy is limited on both systems, and indeed varies between faculties.  Downtime of a fileserver would negatively impact users of either system for period of time and require manual effort to resolve.   Downtimes can be due to some types of hardware failures (though RAID disks reduce that likelihood), network failures, software failures, and upgrades of hardware or software.  With modern server hardware and proven software, unscheduled downtimes are very rare.

Nexus is predominately used to deliver workstation computing (either though workstations or terminal servers), though it also provides password control for many Email systems and wireless access.   There were 34,000 users who used Nexus in 2008/2009. 

ADS provides password authentication for all university business systems, wireless access and ACE, resulting in 47,000 authenticated users in 2008/2009, but the number of people who log onto ADS for workstation computing was less than 2,000.

Vista adoption has not been particularly strong in either domain.  Nexus has 168 Vista machines or 3.8%, ADS has 141 or 6.5%.   Additional Vista benefits can be realized when the domain controllers are upgraded to Windows Server 2008, but this has not been done in either domain, and it will be costly as all the domain controllers would have to be upgraded with 64 bit server hardware.  The estimated costing would be approximately $25,000 to $35,000 for Nexus, the ADS domain controllers are already 64 bit capable, and may not need to be replaced.

The two domains serve very different niches.  ADS addresses the needs of centrally managed user computing, and is extensively used for authenticating all business systems.  Nexus offers the flexibility necessary for diverse computing needs in the faculties, but with strong automation that reduces the number of administrators required, and lessens the amount of time users spend managing their workstations, and addresses the large collection of student accessible machines.

Moving forward, there are several possible strategies for dealing with the two domains.

We could continue with the status quo, and possibly encourage others to join either domain depending on their needs.  This strategy would reflect the various strengths and objectives of the domains.  It has the highest cost, but also carries the benefit that there are more experts on campus that could be used in a crisis to solve a problem in either domain.

There are also possible intermediate methods of integration between the two domains.

Several types of trust relationships can be defined.  Trusts may seem like the least amount of work, but they could be problematic.  Users from one domain who would try to log into another could have difficulty because the environments are not fully compatible.  A mistake on the login panel could lead a user with accounts in both domains to use the wrong account.  This could create user frustration and support headaches.  And domain trusts require trust.

A shared forest would reduce the number of servers needed.  However, the forest root would require more servers to serve the combined population of the two directories and all their functionality.  There are presently two forest servers for UWAD/ADS and three for APEX/NEXUS.  Probably four would be needed for a shared forest.  Also, the schema is shared in a forest, so matters regarding the shared schema would need agreement.  Finally, a shared forest reduces the security boundaries between domains.  If one has any trust issues with the administration of a different domain, it should not be in the same forest.

A single domain is possible, but is not without problems.  There would be a great deal of work required, especially if the many GPOs of Nexus were to be moved.  The challenges are still present; the faculties would require a lot of concessions.  Also IST is under increased pressure for security from auditors and due to eCommerce.  Assuming these concerns could be worked out, a migration plan would be necessary with a cutover date.  Having all the workstations and servers transfer to a domain would require downtime, some of which could be reduced by using trusts.  But with thousands of desktop users on both systems, the downtime would not be appreciated. 

There are presently four domain controllers for ADS and four for Nexus, the savings in hardware would be small.  The greatest benefit would be that IST would gain access to expertise in automated software delivery, but this could also be realized by sharing MSIs as we have already done with the Raiser’s Edge and Emerge on the existing domains.