Active Directory Service Implementation Project
Status Report 12 June 2003
Project Objectives:
To implement an Active Directory Service (ADS) to address the business needs of the University in
the short term and long term.
Products of the Projects
 Implementation of an ADS to address the requirements specified in Appendix 1.
 Development and implementation of adequate working procedures and production of supporting
documentation for the delivered service (including those required for a join-up process enabling
a new faculty/department to join the central ADS).
 Specification of the financial responsibilities of existing stakeholders and any potential new
faculty/department proposing to join the central ADS.
 Propose an appropriate organisational structure for support of the provided service.
Project Organisational Structure
The crucial factor for the success of this project is the involvement and commitment of all
stakeholders. Initial stakeholders are CA and IS, but in due course all faculties and departments
will, potentially, become involved in this project or services that will be delivered by this project.
To ensure proactive and positive participation of all involved, a flat organisational structure has been
adopted. This structure comprises of one team only, the Implementation Team (i.e. the force behind
the project that will make things happen) and one external consultant from Microsoft who will
technically guide the Implementation Team and will act as the Quality Assurance Reviewer. The
Implementation Team members are: Dave Anderson (CS), Barry Crozier (MIS), Mark Denham
(Library), David Fildes (CARU, IT), Khosrow Hejazian (MIS), Roger Mackenzie (CS), Frank
Mechan (MIS), Pete Mitchell (CS), Mark Partridge (CS), Gavin Watt (Library)
Approach
Prior to the initiation of the project, the Implementation Team met and discussed the way forward.
It was agreed that factors such as the complexity of the task, the short timescale and the lack of
substantial practical experience meant that external expertise would be required. Accordingly the
services of Microsoft were enlisted.
Subsequently, the Implementation Team produced a consolidated list of requirements which were
discussed with the Microsoft Consultant (Nick Lennox). It was agreed that an incremental
development approach should be adopted to ensure that business critical products are delivered at
the earliest opportunities without compromising the overall objectives of the project.
Risks
This section will only concentrate on risks specific to this project.
Completion date: The initial required completion date, end of June, is not achievable. However,
there will be an adequate framework for the Finance System’s application server to operate during
the testing phase of Agresso’s latest release. Detailed planning of the next phases of this project will
ensure that adequate components of the ADS are in place prior to Agresso’s latest release going live.
Collapse of the Project: There are a number of conflicting requirements identified by current and
future stakeholders. This situation could easily result in the collapse of the project. To manage this
risk, the Implementation Team has agreed that all conflicts will be resolved by accepting either the
majority’s view or an external expert’s view.
Lack of uptake by Faculties: Based on current plans, Faculties and Departments will get involved at
the earliest opportunity. The Implementation Team believes that it could encourage Faculty
stakeholders to join by demonstrating a flexible ADS environment that could be adapted to address a
variety of needs; has tried and tested development plans; has a set of high quality documentation
ADS Implementation Project Status Report
Page: 1
describing the technical aspects of the delivered system as well as working procedures governing the
delivered service; and has an appropriate organisational structure for support of the provided service.
In addition there is an absolute need for Information Services to demonstrate its commitment to this
project and the services delivered after the closure of this project. Failure to do so will prohibit new
faculties joining and potentially force participant faculties to leave. As a result a great opportunity
to provide a uniform and unified service to the University Community will be missed.
Interface with other systems:
The delivered service will have to interface with a number of existing systems including Standard
Desktop, Exchange, NDS and the Finance System. These systems’ needs are described in the
requirement list and will be addressed. There are two other interfaces that should be mentioned:
 Common Directory: The Authentication and Authorisation W/G of the Information Strategy
has recommended the implementation of a common directory. Four members of this W/G are
also members of the Implementation Team. Discussions so far have not identified any area of
conflict and in fact the Implementation Team believes that the ADS implementation will
facilitate many issues to be addressed by the CDP.
 Faculty and department systems: Adoption of a flexible solution will facilitate these.
It is anticipated that other interfaces will become apparent as the Project progresses.
Resource Requirements
Item
Servers (3 servers) to be located in CS, Library and MIS
Exchange Server
Back-up software and hardware
Network upgrade to 1GB for all locations
Consultancy (10 days @ £1600 per day + VAT + Exp)
Total
Amount
£12K
£7K
£10K
£5K
£20K
£54K
Required by
Now
Next financial year
Next financial year
Next financial year
Next financial year
It is proposed that the cost be shared by the Central Administration and Information Services.
Progress to date and future Plans
The Implementation Team has completed a list of initial requirements for CS, Library, MIS and
CARU.
The hardware requirements have been identified and servers have been ordered; they are due to be
delivered w/c 9 June.
Requirements have been discussed with the Microsoft consultant and the framework for the initial
technical plans have been agreed.
The Test environment is being set-up.
The next meeting with the Microsoft consultant is arranged for the 17th June. The overall plan will
be discussed and agreed at this meeting.
Based on our current plan and considering the various constraints, including summer holidays, the
project will be completed by the end of August 2003.
Khosrow Hejazian
ADS Implementation Project Status Report
Page: 2
Appendix 1
Active Directory Service Implementation – Requirements
The following list of requirements has been consolidated from the specific requirements of the various groups
represented in the ADS implementation project team. Once finalised, this list will be delivered to a consultant who will
advise on the feasibility and practicality of the implementation. The requirements are:


















The ADS must provide the authentication mechanism for the Microsoft Exchange service under Windows
2000. The current CENTRE domain must migrate into the ADS as part of the migration from Exchange 5.5 to
2000/2003. In the interim, the current Exchange 5.5 facilities must still function as expected, although it is
recognised that an additional authentication challenge may be encountered to facilitate authentication against
the ADS and the NDS in the current SSD model. If a conflict arises, the current model should take priority. As
an addendum to this requirement, various members of the Finance Office must be able to use this same route of
authentication to validate access to certain MIS resources for Agresso.
The ADS must provide domain-like authentication for the Library and MIS. At the least, this should mirror
what is already in place in these units for NT domains.
The ADS must support the use of unit-specific (i.e. not of interest to the campus as a whole) objects and
authentication without changes to the initial structure. That is, the structure must be flexible enough for
campus-wide and unit-specific objects and requirements to co-exist.
The design of the ADS implementation must be flexible enough to support the inclusion of other units (e.g.
Computing Sciences, Physics, Medical Faculty) into the structure post-implementation without compromising
the initial structure. The ultimate goal is to provide a campus-wide ADS implementation, functioning as a
single point of authentication in conjunction with Novell and the common directory (LDAP) project. The team
must understand how best to introduce other units into the ADS structure (i.e. should multiple forests be used,
or should additional forests be merged into the campus structure?).
The ADS must provide a superset of the data required for the common directory, and the common directory
must be able to interrogate the appropriate subset.
The ADS implementation team must adopt a DNS model, and must understand the implications of the model
selected. Dynamic DNS services should be provided with pass-through from the current Unix DNS for nonMicrosoft classes.
The implementation team must understand the situations in which a mixed-mode environment will be required,
including the benefits and drawbacks of these situations. Advice is required on the long-term implications of
using a mixed-mode environment.
The implementation team must appreciate the complexities of adopting an ADS structure where larger
departments will support local domain controllers (for non-campus objects and authentication), but where
smaller departments may share domain controllers. IS should be able to provide advice regarding the pros and
cons of each approach.
Advice is required on the best monitoring tools to use, whether these are Microsoft or third-party tools. A list
of the most widely used tools with pros and cons would be useful. In addition, the appropriate metrics against
which to monitor must be identified early in the implementation project’s lifecycle.
Several Microsoft server products are already in use across IS (e.g. SQL Server, IIS, … in addition to
Exchange). The ADS must be able to provide authentication for these products in the same way that NT
domain authentication is currently used.
The ADS should be able to support several other services that could be of use across campus and locally within
each unit. Examples are Group Policy, Distributed File System, and Remote Installation Services.
Appropriate disaster recovery procedures must be put in place at a campus level.
The appropriate parts of the ADS must be replicated to various locations across campus.
Suitable management tools must be available to administer the various parts of the ADS remotely, including
change control, statistic generation/reporting, capacity planning, etc. In conjunction with this requirement, a
management plan should be constructed.
There must minimal impact on the current SSD3 environment (e.g. the user should not be required to enter an
additional username/password for access to Exchange, Agresso, remote filestores).
There should be a roadmap for the rollout of the ADS for the next 3 or 4 years.
Information (costs, benefits, disadvantages, impact analysis, etc.) should be collected to allow an intelligent
decision to be made regarding whether or not CARU should switch from NDS authentication to ADS
authentication in the long term.
Security implications of the use of ADS should be listed and addressed as appropriate.
ADS Implementation Project Status Report
Page: 3