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.
Premises
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.
GPOs
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.
Conclusions
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.