University of Waterloo

Campus Active Directory Project

Final Report April 2001



The Campus Active Directory Project began in May of 2000 with a mandate to “develop a strategy for implementing Active Directory (AD) to support Windows 2000 migration”. Since then representatives from IST, the Library, Engineering, Math and Environmental Studies have evaluated a variety of strategies to achieve campus goals related to Windows 2000 Active Directory outlined in the project’s charter. This report provides an overview of the accomplishments of the project team and the recommendations made as result of their efforts.



The project team attempted to identify and evaluate options that would minimize University costs related to technical infrastructure and administration while satisfying its needs in terms of decentralized management. In order to achieve this, the team began by considering the simplest Active Directory designs and only moving to more complex ones when it was clear that the campus’s needs could not be satisfied.


Designs Considered

The design options described below accommodate the production needs of core academic and academic support groups only. While forests (see Glossary) for testing and other Windows 2000 environments incompatible with standard management and security processes will exist, they were not considered during the evaluations. The requirement to provide multiple level security is also not addressed directly in these designs but the team is confident that this can be accomplished by implementing a separate domain (see Glossary) that would provide identification and authentication for applications requiring a higher level of security. This domain could be located in a separate forest or within another, existing forest.

Single Forest / Single Domain

The team first evaluated a design in which all core student, academic and academic support Windows 2000 (W2K) computing would be supported in one domain in one forest. This model maximized the opportunities to share campus resources (human and computing) and still allowed significant local control of W2K resources such as computers, printers, software, etc.  Most of the team’s efforts were directed towards evaluating this option. In November of 2000 it was realized that differing domain management needs for the Polaris and academic-support groups made this option impractical. In December the project team produced a report comparing single and multiple domain implementations of Active Directory.

Single Forest / Multiple Domains

In January 2001 the IST Systems group prepared a proposal for an Active Directory environment consisting of multiple domains within a single forest. This proposal maintained most of the excellent resource sharing capabilities of the “one forest/one domain” design while providing the ability to manage domain configurations independently. Extra costs for server hardware and administrative staff seemed to be reasonable and justified. The major flaw in this design was that all user groups in a forest must agree upon a forest management process and there was disagreement regarding the controls required for forest schema changes. Since all domains in a forest share a common database schema, changes will apply to all domains within the forest. After much discussion differing needs related to schema change management caused the project team to reject this option.

Two Forests / Multiple Domains

The final option evaluated consisted of two forests, one that would initially be used to support Polaris users and one for general campus use including academic support. This design had the advantage of allowing each group to achieve their objectives related to change control, integrity and distributed administration. Resource sharing between domains in different forests is not as simple as sharing between same-forest domains. It requires time, effort and cooperation between administrators to set up and maintain inter-forest trust relationships whereas two-way trust relationships between domains are established automatically in a single forest. While inter-forest trusts were not tested as part of the project, the team is confident that they will meet the University’s requirements when the need is established. From the users’ perspective this design can result in resource sharing capabilities similar to a single forest environment. If the administrators decided that establishment of trust relationships between forests was not appropriate, a user could be given an account in both domains and he/she would sign on to either forest/domain as required. Costs to implement and administer this design will be higher than the other designs but it is difficult to estimate exactly how much.



The project team recommends that the University implement the Two Forest/Multiple Domains design for Active Directory. Based on the experience and knowledge gained during the project, this option best accommodates the University’s needs in terms of systems management, security and resource sharing. Establishment of trusts where appropriate to achieve institutional goals is recommended and anticipated. The team believes that most of the University’s core AD needs can be accommodated within these two forests with groups joining either forest depending on which managed forest can best support their individual needs. While much more design work is required before implementation, the following is a high level description of the environment suggested by the project team.

Polaris Forest

This forest will contain an empty domain to house the schema, and another domain to support users and computers of the Polaris environment. A group of faculty administrators will manage the environment in a cooperative manner. This decentralized management approach will achieve goals related to distributed administration and enable administrators to react very quickly to new requirements in the Polaris environment. It is anticipated that administration will be delegated extensively to administrators at various levels. A more detailed outline of Engineering Computing’s vision can be found in Appendix A. Distributed AD administration capabilities are outlined in the Appendix B.


UW Forest

This forest will serve the academic support areas of the University as well as academic areas that choose to utilize it. It will initially contain a dedicated forest root domain (used only for forest administration) and another domain used to support W2K services for academic support and academic computing. Since corporate administrative applications will be tightly linked to this environment, implementation of forest level changes (schema changes, new domains, etc) will be centrally managed by IST to assure their integrity, security and availability. While forest administration will be tightly controlled, it is anticipated that eventually administration of other domains (if required) and organizational units will be delegated to some other groups.


For each production forest, a test forest will be created that will allow developers and administrators to effectively test changes in an environment similar to production.

Future Cooperation

The team recommends that Windows 2000 Active Directory administrators continue the information sharing and cooperation that has made this project successful. The best forum for this has yet to be identified.

Appendix A

Proposed Polaris AD Procedures

These are some proposed Polaris AD procedures, WPAG will have to decide the final procedures.


The Polaris AD will be administered by the peer group of the faculty administrators.  Education, accepted practices and software will be used to keep things working.


There will be two forests; one for testing (including schema changes) and the other forest will hold an empty AD to house the scheme and the Polaris domain for user accounts, computers, etc.


All users will have unprivileged accounts.  Administrators will have multiple accounts with varying levels of privileges and are encouraged to use the lowest level privilege necessary to perform a given task.


Each faculty can decide to have as many OU administrators as they wish for changing passwords, installing clients, etc.


There will be a much smaller group of senior administrators who will optionally have system-wide privileges such as Schema admin.  Senior administrators are more likely to be cautious, and so they may individually opt to not have schema privileges if they are uncomfortable, but reserve the right to those privileges in the future if the need arises.


Composition and changes to the list of system-wide administrators should be ratified at WPAG.


To keep things running in a maintainable fashion, we will have additional education sessions and a mailing list to share accepted practices.


Furthermore, we will use AD crawling software to monitor the AD nightly for schema changes, system group (privileged group) composition, and to monitor other critical aspects of the AD.  Daily reports will be generated, and warnings sent to inform of changes.


Also, nightly snapshots will be taken of the AD, so that we can restore to a known state in the event of a disaster.  Also, we keep passwords in a secondary store, so we can repopulate them if needed to reduce user confusion after an AD restore.


We have found that peer management works well when software is written to nag compliance to accepted standards.


There will be some accepted practices concerning matters like physical security of AD controllers.

Appendix B

Permissions versus Control

Most of what a Windows 2000 administrator needs to do can be accomplished by an Organizational Unit (OU) Administrator within a domain, within a forest. This OU administrator can have full control over all resources within their OU. This includes the ability to add, modify and delete member servers, computers, users, printers, shares, contacts, group policy objects (GPO’s) and security groups within the organizational units they have been given permissions to modify. They also have the right to block domain-wide policies from their parent OU’s unless the parent administrator explicitly denied blockage.


More powerful than an OU Administrator is a Domain Administrator. Domain Administrator rights are required to set domain-wide policies. By default Domain Administrator privileges are required to set password and account lockout policies, log on locally to the domain controllers, and run and manage services like DNS and DHCP. Note: The Domain Administrator can delegate extended rights to OU administrators, or others, to change most things that normally require domain administrator rights.


The highest level administrator in Windows 2000 is the Enterprise Administrator. This administrator is in charge of the Active Directory structure, however very little functionality, beyond the Domain Administrator, has been granted to the Enterprise Administrator. Some of the things an enterprise administrator account is required for include: allowing a new domain to enter the forest, adding members to the Schema Administrators Group and defining what Windows 2000 role (ie. RID master, PDC, Global Catalogue server and Infrastructure master for example) each domain controller plays.