ADS Domain Comparison
The computing people at UW began deploying the two campus Active Directory domains “Nexus” and “ADS” about 3.5 years ago. At that time, there were significant differences in perceived requirements and decisions.
The following description explains how the systems differ, both by design, and in practice.
The points described here were recorded on or around October first, the same date as the Nexus values. They were collected using public information available to any member of the UW community with access to a computer.
ADS domain is the primary Windows domain for academic support units (the name can be confusing, these are essentially non-academic units), and the user directory for the campus business systems such as the financial system, the co-op system, etc.
Security is a primary design issue for the ADS domain. For example, the possibility of a departmental technical person being able to access a manager’s payroll data or financial details was deemed unacceptable. That risk is mitigated by channeling much of the security to IST personnel.
Growth and Size
The ADS domain is used by approximately by 1257 workstations and servers. ADS was ramped up more conservatively than Nexus at first, but then grew quite rapidly.
Many of the major academic support areas are now using ADS. The IST network management web space indicates that the total number of active computers in client networks of ‘Admin’ total about 1500 active workstations and the client areas in IST itself add less than 300 machines. Unless there is a change in direction, it is unlikely ADS will grow beyond 1500 to 1800 computers, which is certainly impressive. Growth presently appears to be tapering slightly.
Nexus is used by 2726 workstations and servers. Its growth had several spikes when major student computing labs were converted, moving several hundred computers into the domain in a matter of days.
Nexus appears to have essentially reached a steady state in student computing labs. Major growth is now in non-student areas, and is still quite rapid.
Management: Single Bangs
When we designed the campus AD structures, we used terms like single bang accounts (eg. !tim) to denote a person with elevated privileges who could perform operations at a departmental or faculty level as appropriate.
In ADS there are 129 single bang userids. User groups (such as the campus police and graphics) typically have one, two, and occasionally three or four single bang accounts. IST accounts for the remaining 35.
For security reasons, the ADS single bang accounts are quite restricted in what they are permitted to do. One example is that they are not privileged enough to change passwords. However, they are granted install access to the workstation (so are the users themselves), so single bang accounts, if compromised, could install keystroke loggers which would easily defeat this supposed security feature.
In Nexus, departments are free to create as many single bang accounts as they want. A Nexus single bang account usually has access to all the computers, OUs and users in the department or faculty. There are 90 single bang userids in Nexus.
Management: Double Bangs
During the initial design, we defined a class of super accounts, called bang bang userids. They would have most domain level administration privileges. In actuality, Active Directory has even more privileged special purpose accounts, but this was the one we felt would be sufficient to solve most difficult problems.
At that time, everyone was rightly concerned about the number of double bang accounts issued. Unfortunately, Active Directory OU level privileges were not always sufficient to perform certain common tasks, so in practice we found we needed more than initial estimates just to perform basic tasks.
In Nexus, we created an amended formula calling for 16 bang bang userids to be spread over all the faculties, IST and the academic departments in Engineering.
As Nexus grew, we found we needed more users to be privileged. There were many issues, including schools which operate separately from faculties, etc., and now we have 34 bang bang accounts, assigned to 26 individuals.
However, the Nexus group is now proposing that bang bangs be modified so that they have less wide-spread powers as we have found solutions to almost all problems previously requiring double bang privileges. Instead, we would modify the double bang accounts to have full access to student areas, but treat office and research areas as private rooms within our active directory, essentially accessible only to the local administrators. We will still need a few emergency accounts of the current bang bang level, but we think that approximately four Nexus-wide administrative users might suffice. Two people in Engineering do have to perform domain-wide operations as part of their jobs, the other (approximately) two individuals would likely be selected from other computing units.
In ADS, the number of double bang accounts is not easily seen, because they have used security features to obscure some details. There are definitely 9 individuals with double bang accounts, and three nameless accounts and groups: administrator, custodian, and ntmaint, for a total of 12.
The double bang accounts are only issued to people inside IST. This was a design decision right from the start.
Also, all academic support workstations are configured to treat members of the acsup-computer support group as local administrators. This list of 25 people have full access to every workstation. All of these individuals are in IST.
After this complicated description, the net results are:
- ADS allows approximately
o 9 individuals onto all server areas
o about 25 people onto all workstations
o about 129 people with administrative access to portions of 1257 computers
- Nexus currently allows
o 26 individuals onto MOST servers areas
o 26 individuals onto MOST workstations
o about 90 people with administrative access to portions of 2726 computers
- a Nexus proposal would allow
o 4 individuals onto most server areas
o 4 individuals onto all workstations
o 26 people with access to student user data
o about 90 people with administrative access to portions 2726 computers
o local control, where a faculty or department has total access to its own area, and very few outsiders have any access.
Active Directory Organization
In Nexus, the domain is divided into faculties (or similar units), and then subdivided into departments wherever desired. Computers, servers, users and groups are primarily managed by a local administrative unit.
Students are also assigned to their enrolled department, but they are created centrally (and automatically by Engineering Computing using Registrar data), and administrators of any faculty are free to assist the user with password issues, moving students to a new faculty for graduate studies, or many other problems.
In Engineering, management of the file space is also distributed. Departments can elect to use their own fileservers, or they are free to divvy up their proportion of the faculty-shared space however they deem appropriate.
The ADS structure is very different.
Computers are organized into organizational units, so that single bang users can
deploy software on them.
Local administrators on Nexus have been free to group their computers as desired, and to apply shared or local GPOs. Some units allow typical users to have full workstation privileges, others do not. Usually GPO software delivery is preferred for typical applications, and local installs are only performed in rare circumstances.
ADS users, unlike computers, are all grouped in a big pool. A local sys-admin cannot change a user’s password or perform certain other operations.
ADS makes extensive use of AD groups, 638 in total, whereas Nexus has only 393.
Nexus uses GPOs extensively for software
installation and management. There are
presently 1128 GPOs.
Approximately 500 of them were created by the core team in Engineering
Computing / IST (and shared with others).
Other faculties create their own too.
Science has 85,
Some of the Nexus GPOs are redundant, because they simply specify an alternate server for installation files. Software deployment in large Nexus labs may mean 120 or more workstations at a time, so load balancing the servers is important.
ADS has a total of 55 GPOs, and 39 of them are for login scripts (compared to only 15 login script GPOs in Nexus).
The ADS software base is much smaller Nexus. Other than a core set of common applications across the enterprise, the ADS software installations are often left up to the departmental administrator or the user.
Physical Network Design
The campus has a primary network backbone with two centrally managed
routers (one in M&C, one in ENG 2) to which most of the faculties connect
at 1 Gbps. The
exception is Arts, which connects to
This means that when the E2 router goes down, Arts and
All of the critical resources of ADS, including primary home directory servers and domain controllers are stored in the MC building. If the E2 core router goes down, much of campus cannot reach ADS. If the MC router goes down, nothing can reach ADS.
With Nexus, we have tried to distribute resources in anticipation of network outages. Domain controllers are located in both MC and CPH. If either core campus router goes down, Nexus “partitions” but continues to work – not as efficiently, and only for users working in their own faculty - but it will continue to work for the majority of users in the majority of cases.
Math/CS, Science and Engineering have a private redundant 1 Gbps connection between themselves. In the event of a catastrophic failure of core routers, traffic from those faculties resumes using an internal route… after an initial delay.
Nexus assumes the workstation has sufficient bandwidth (100 Mbps or better), and we use the network a lot. User files and profiles are copied over the network as needed, and the software installation GPOs are distributed among servers because it is common to saturate gigabit server links when deploying software en masse.
ADS users are typically connected using either 100 Mbps or 10 Mbps Ethernet. Some of the 10 Mbps hardware was 25% less expensive at the time than the 100 Mbps Ethernet deployed in the faculties, but the order of magnitude in performance severely limits the design of the ADS user experience.
Network files and profiles are not appealing at these speeds, and even network-based software distribution is much slower. But that may not be as much of an issue because ADS distributes far less software via GPO than does Nexus.
The Nexus administrators are considering changes to our security management model.
This document was prepared to assist us in our decisions by presenting a snapshot of two major campus systems which have both grown dramatically, and which have had to solve somewhat similar problems of workstation management.
It appears both systems have departed from the intended small nucleus of AD managers, and from the idealism of a directory-enabled, multi-level management structure.
It will be a worthwhile exercise to review these two directories again at a later date, especially if the Nexus group gain experience with a true multilevel directory model.