Skip to the content of the web site.

Nexus: Policies, Standards and Procedures

Active Directory Management for the UWAD Forest

NOTE: This document needs to be revised for Nexus and applies currently only to ADS/UWAD

(It has been left here for reference purposes only)

Introduction

IST is responsible for the management and support of the UWAD forest and the Nexus domain.  IST proposes to implement the following set of procedures, policies and standards that will ensure the integrity, supportability and reliable operation of this environment. We propose the following set of guidelines for administrators.

 

IST will provide the following infrastructure and services for users of the environment:

  • Appropriate hardware to host the domain controllers required for an empty root domain, hosting the forest and a resource domain where objects are placed
  • Hardware for essential member servers, if required for university wide services
  • Definition and management of policies within the Nexus domain and enterprise level
  • An appropriate test environment similar to the production “uwad” forest for testing of all previously untried procedures

IST will not provide:

  • Hardware to host additional domains

  • Hardware to host special member server functions not required by Academic Support

See Appendix A  for additional infrastructure and service items not related to Active Directory.

 

Procedure for Making Changes within the UWAD Forest

The act of joining an existing W2K forest is not without risk either for those joining or for those already there. Similarly major changes must be treated just as seriously. We anticipate that extensive testing will be done before any changes are made, particularly with those for which we have little experience. In order to achieve this with minimal disruption IST will carry on with current practices.

  • IST will host a “testads” domain in a “testuwad” forest, which will mirror the environment that exists in the “Nexus” domain and “uwad” forest as closely as possible.
  • Any request that requires experience not already gained in the UWAD forest will be properly tested in this test forest before changes are implemented in production.
  • A subset of IST members will co-exist in this “testuwad” forest for the duration of the testing to verify Academic Support processes are not affected by proposed changes.
  • If additional “uwad” changes are implemented during this testing they will also be applied to the “testuwad” forest.
  • Once a mutually agreed-upon time has passed the changes will be made, and the client moved to the “uwad” production forest.
  • Every attempt will be made to treat the “testuwad” forest as production in the interim

Delegation of control

In April of 2001 the campus Active Directory Project visited the details of what it meant to be an OU, a domain and an enterprise administrator. For the details of what we understand the implications to be please see Appendix B within the Campus Active Directory Project’s final report.

Delegation of administrative privileges

Enterprise administrator

This responsibility will be assigned to a small number of IST staff.

Domain and OU Administration

IST is still developing the administrative procedures and processes for a production level UWAD forest and Nexus domain. Once suitable testing, as outlined above, has been accomplished the parties involved will jointly discuss the most appropriate level of joining the forest, whether as an OU or as a domain and how to best delegate control. We expect that most needs will be accommodated by OU level administration, but don't yet have enough experience to make such a determination. For more details on the details of joining UWAD as a domain or an OU see Appendix B below.

 

The following describes how IST will administer its Academic Support structure:

  • IST will only delegate control to OU’s named after existing UW departments or faculties.
  • Delegation of control will be limited to the individuals identified by department heads, as required. Training will be provided as appropriate. We do not anticipate that many departments will request this control.
  • Delegation of control is granted and controlled, by OU, to security groups rather than to individuals. The ability exists to grant or deny as much or as little control as necessary at the OU level.
  • Any further sub-level delegation of control within Academic Support must be approved by IST

Please see the “IST Concerns” section below for more information.

Policies, Standards and Procedures for Management

Administrative Accounts:
  • Administrators within the Active Directory will have recognizable userids for auditing purposes. Generic accounts will be limited, whenever possible, to automated services.
  • OU Administrator userids will be constructed using the uwdir userid with a prefix of a "!" character.
  • Domain and Enterprise Administrator accounts will follow the same conventions as OU Administrator accounts, but with a prefix of “!!”.  We have adopted this convention from Polaris management.
Organisational Units:
  • IST reserves the right to limit the number of all objects within the UWAD forest to a reasonable limit including OU’s.
  • IST high-level OU’s names will adhere to UW department names whenever possible.
  • We encourage the use of short OU names whenever possible.
  • OU administrators will be granted the right to build their own structures. It is assumed that reasonable limits will be adhered to, in order to minimize the affect on domain and forest performance.
  • IST will create OU’s only when required for AD management reasons.
Group Policy Objects (GPO’s):
  • GPO names should reflect the name of the owner and their function, whenever possible. Since they are advertised throughout the domain, confusion is minimized by the use of names like "IST-software deployment".
  • Storing GPO’s in a common OU makes them easier to locate. They can be linked wherever necessary and dependencies are more easily tracked.
  • Some careful planning is required in order to create a minimum number of GPO’s. This will limit any negative performance effects on the clients. Control is maintained through the relationship between the OU, the GPO, and a related Security Group.
  • IST anticipates that all future GPO changes will be reviewed by a representative committee before being implemented.
  • GPO’s must be handled with care and implemented by as few qualified individuals as possible in order to guarantee a secure environment
User Object Creation
  • Since a user object is unique within a domain, and is critical to the operation of the Academic and Academic Support parts of the university, IST will provide tools for the creation and modification of user objects within the Nexus domain.
  • These will include command line tools and easy to use web-based tools that allow all administrators to accomplish user object related tasks.
  • IST is committed to providing management for these objects in as efficient and timely a fashion as possible.
  • We have not yet finalized the delegation of control issues related to user attributes.
User Groups:
  • Security group names are unique domain wide. Therefore user group names should be prefixed by the name of the OU in which they exist. This eliminates problems with group names like “helpdesk”. A preferred alternative is “IST-Helpdesk”.
  • Academic Support groups will be grouped together in their own OU’s like Users and Computers, to make them easier to manage and find.
Resource Objects:
  • Resources include computers, contacts, printers and file shares.
  • Resource object name standards can be set at the OU level (i.e. not domain wide).
  • Domain level objects however, if they are to be accessible to the entire campus should use "UW" as the prefix.
Schema Management:
  • Requests for schema changes should be made early enough to allow for sufficient testing with existing and anticipated schema objects to verify that there are no conflicts or concerns.
  • Schema management occurs only on the root PDC for the forest, and can only be done by an enterprise administrator.
  • Modifications, when made, will be clearly documented and available to all administrators as required.
  • Once the schema change is complete, the ability to modify it will be disabled by the enterprise administrator.
  •  IST anticipates that all future Schema changes will need to be reviewed by a representative committee before being implemented.

IST Concerns

Active Directory
  • Excessive object creation anywhere in a W2K forest can adversely affect performance and stability of the entire forest. Since the Global Catalog, for instance, is shared by all within the forest and these objects, including OU’s, Security Groups, etc., are stored in this Global Catalog, extreme caution must be exercised when creating any new objects.
  • IST would prefer to be involved in the Active Directory design within the parts of “uwad” over which others have control. The intent is not to define but to advise with respect to the above concerns
  • Whenever possible most other concerns have been dealt with using Group Policy Objects at the domain level in “Nexus”.  These would have to be reapplied to any other domains in the “uwad” forest.

 

Delegation of Control

 Since delegation of control of any part of a W2K forest usually means further delegation of control can be granted by that administrator, extreme caution must be used in order that:

  • Further delegation does not happen without the approval of a representative committee and
  • Delegation capabilities are removed when the required task(s) are completed

 

Procedures for the Maintenance of the Active Directory

 

Change will be implemented in a way that will guarantee that the security of the Active Directory is maintained at all times and that the ability to remove a faulty change is maintained. Everything new will first be tested in another forest before being committed in uwad.

GPO's 
  • In general, GPO’s will not be applied automatically to either Domain Controllers or Domain Administrators. A mistake in applying a GPO at this level may make the removal of the GPO impossible. If a GPO must be applied at this level (for instance password complexity requirements), it must be applied with the understanding that everyone in the domain is affected and that a complete restore of all Domain Controllers from backup is a possible consequence of a mistake. If changes are made at this level they must be done infrequently, as well as tested, scheduled and applied with great care.
  • Whenever possible, the number of administrators that make GPO changes will be severely limited in order to reduce the risk of conflicts. This will also limit the size of the contact list when problems arise. 
  • GPO changes will be applied with caution since no mechanism exists in Windows 2000 to copy or backup a GPO.
  • The default domain and domain controller GPO will not be modified. Instead, new GPO’s will be applied afterwards that make the local changes required. This will create an audit trail.
 Backup and Restores

All critical data will be backed up and suitable restoration procedures documented and available to appropriate staff.

Management Tools

Whenever possible, the Active Directory tools supplied by Microsoft will be used. Additional tools for management of the Active Directory might include:

  • Policy management tools to keep track of what group policies do and to whom

  • Consistency checker to verify consistency of objects in the Active Directory

See Appendix A  below for other tools already implemented.

 

NOTE: No decision has yet been made as to when or how to host the university's UWDIR data within Active Directory. This will become the driving force for the user account-related management tools mentioned. Consistency and minimization of errors are the other reasons.

 

Appendix A

IST Windows 2000 Infrastructure

The Infrastructure and Services referred to in the Introduction are specific to the Active Directory. IST will provide other Windows 2000 services. Some of these include:

 

  • GPO distributable executables for primary corporate applications as required by Academic Support

  • GPO distributable executables for secondary applications as required within Academic Support

  • Software updates, as they become available, as required by Academic Support

  • Current workstation and server images, as required by Academic Support

  • IST already manages Norton Antivirus engine revisions and virus definition updates from a central set of servers. This management could be extended outside of Academic Support.

  • IST manages a set of WINS servers to allow a transition between the W2K environment and the legacy Windows environments

  • A set of Print Servers are fail-safed and managed within Academic Support with some central printer management

  • Active Directory monitoring tools that log changes

  • Error log management (already mostly in place) to remain proactive about problems

(Note: none of the above bullets refer to licenses for said software)

IST will not automatically provide:

  • Custom workstation images (it is assumed that additional software can be applied by GPO)
  • Custom server images
  • GPO distributable executables for applications not used by Academic Support

 

Appendix B

Domains versus Organisational Units

A Domain is a Security Unit. An Organisational Unit (or OU) is created purely for administrative reasons and is subject to policies defined at a level above the OU in the hierarchy within a domain.  The differences in some cases are subtle. Further details are provided later in this document.

The pros of joining the UWAD forest as an OU are:

  • Management of computer and user policies. IST has defined override-able and non override-able policies. See: http://windows.uwaterloo.ca/ADS/Policies.asp
  • New policies can be applied at your OU level and policies.
  • Full delegation of control can be granted to most resources defined within an OU. User objects are one exception. See below for more details.
  • No additional hardware must be purchased, although there may be advantages to individual units providing additional domain controllers. If hardware is provided for an additional controller, IST will build and manage it.

If joining the UWAD forest as an independent domain:

  • All policies are managed independently from any other domain, and must be recreated within each domain, if required.
  • All objects are unique to each domain. Objects from other domains can be referenced because of an inherent two-way transitive trust.
  • At least two server-class machines are required to host the domain controllers for the new domain. IST provides hardware and software specifications for these. A software image will be made available to expedite this build.
  • A unique DNS structure must be defined to host the new domain. Details of this will be documented when complete.

 Note: Member servers can be easily added to either of the above two models and managed by the department that owns them, in the same way for either model.

Document maintained by: Manfred Grisebach               Last modified: October 18th, 2001