Professional Documents
Culture Documents
Active Directory Project Charter: Document Revision #: 1.05 Date of Issue: June 20, 2003 Project Lead: George Bryan
Active Directory Project Charter: Document Revision #: 1.05 Date of Issue: June 20, 2003 Project Lead: George Bryan
Document Revision #: 1.05 Date of Issue: June 20, 2003 Project Lead: George Bryan
MC, GRB, IPM Presentation, wording GRB Cross-Realm removed. MIIS added.
Page 2
TRANSITION .................................................................................................................................16 DEPLOY .......................................................................................................................................16 RISKS............................................................................................................................................16 ASSUMPTIONS...........................................................................................................................18 PROJECT DEPENDENCIES.....................................................................................................18 CRITICAL SUCCESS FACTORS.............................................................................................18 PROJECT BUDGET ...................................................................................................................19 GO FORWARD STRATEGY ....................................................................................................20 GLOSSARY..................................................................................................................................20
Page 3
PROJECT PURPOSE
The purpose of this project is to enable UF faculty, staff and students to: Have accounts attributed to identity Provide single sign-on to both local and university computing environments Use authoritative sources of directory information Use desktop computers in more than one unit Share resources, including files, printers, calendars Increase the security of systems at UF
Page 4
Managed Infrastructure UF Active Directory will be operated as a 24x7 production service, including Domain Name Service1, Directory Replication and Domain Controllers. Departments will avoid duplication of services. UF Active Directory will provide a highly-available, physically secure environment for its servers, with generator-backup, RAID storage, climate control, and multiple locations. This environment will be monitored 24 hours a day, ensuring that UF Active Directory infrastructure is always available.
These terms are defined in the Glossary at the end of this document.
Page 5
These policies are rules that are automatically enforced by the system. They typically reflect a units policies to provide or restrict computer and user access. By implementing unit policy using Active Directory policies, a consistent and compliant computing environment results.
Page 6
PROJECT GOALS
1. Identify requirements for Active Directory at the University of Florida. 2. Design UF Active Directory to meet requirements. 3. Establish UF Active Directory and provide services according to design. 4. Develop a migration method for attachment of existing Windows resources to UF Active Directory. 5. Execute the method by attaching the resources of two or three volunteer units to UF Active Directory. 6. Transfer knowledge throughout the project to UF staff enabling on-going operation, administration and adoption of UF Active Directory.
PROJECT OBJECTIVES
Identify requirements for the UF Active Directory by involving units and leadership. Develop Vision Statement Establish principles identity management, local management of resources, support for WAN operations, appropriate structure for related units such as Shands HealthCare, cost effective production-grade operations Work with unit administrators to develop requirements Review designs from peer institutions Working with Active Directory experts, develop a design to meet requirements
Create a centrally supported Active Directory infrastructure available to the entire University of Florida campus that supports a defined set of services. Those services are: Single Sign On via existing UF Kerberos Infrastructure DNS and WINS in support of Microsoft Name Resolution Automated synchronization with campus registry information Active Directory Service Exchange placeholder to facilitate global address lists across units. File services
Page 7
Populate Active Directory with a subset of mandatory and useful attributes from the existing authoritative Campus Registry and maintain flexibility in design to allow for migration to Campus Community (PeopleSoft). Populating Active Directory will be a key in adding value for UF to Active Directory. Requirements: Preserve privacy of Campus Registry data. Mandatory attributes are GatorLink ID and UFID and will be used to track entries in the update process. A subset of important attributes will be selected from the Campus Registry and synchronized into Active Directory. Any attributes synchronized from the Campus Registry will be read-only in Active Directory.
Provide an Active Directory infrastructure that supports the Windows environment and can be effectively managed Requirements The domain and OU structures of the infrastructure meets the needs of affected units UF Active Directory uptime will be at least 99.9% per year Selected user information in the UF registry will be available in UF Active Directory, while retaining visibility of data Provisions will be made to allow departments to install mission critical applications that add to the Active Directory schema
Provide an integrated security environment that is as simple and easy to use Requirements: Allow users to login with a GatorLink ID and password, and then acquire tickets that can be used to authenticate access to any Kerberized application. Allow use of Group Policy to control security Secure GatorLink usernames and passwords from Windows break-ins
Page 8
Provide Centralized WINS for Legacy NETBIOS applications. Requirements: Provide centralized WINS on separate production severs from Domain Controllers. Use two WINS servers to provide fault tolerance in a push-pull configuration.
Provide disaster recovery for centralized domain controllers, WINS, DNS, and Exchange Placeholder. Requirements: Centralized management of event logs. Tested disaster recovery procedures for different scenarios.
Allow for Automatic Software Installation. Requirements: Organizational Units will be able to publish applications through Group Policy. Make migration to UF Active Directory as straightforward as possible for existing Windows domains on campus Requirements: Provide a central team that assists each unit with Active Directory migration Allow Macintosh desktops to access files stored on Windows 2000 servers. Create UF Active Directory to enable migration from NetWare.
Provide a decentralized Exchange system that will allow for autonomous management of individual unit Exchange servers. Requirements: Install Exchange to extend the schema in preparation for departments with Exchange services. Create administrative groups to allocate appropriate permissions to each department unit to properly manage their Exchange server.
Map existing Windows NT 4 services to Windows 200X services without breaking existing departmental applications or procedures Requirements: Transition the pilot migration effort to an ongoing production environment
Page 9
SCOPE
Active Directory will be developed and deployed for the University of Florida. Future expansions may include Shands HealthCare and other UF affiliated organizations. UF Active Directory is intended to enhance existing information infrastructures at the University of Florida. This directory is being developed as an university service for the colleges and departments. Active Directory provides important new services to the university. It enables unit system administrators to provide additional services and reduces the effort required to provide some services. Each individual unit continues to responsible for the day to day support of their unit.
APPROACH
UF Active Directory is being developed by the Office of Information Technology in collaboration with the units of the university. The end product of the Active Directory Project will be a campus-wide Active Directory service integrated with the Campus Registry, Kerberos authentication service and other key systems. Unit participants in UF Active Directory are customers and their participation is of paramount importance. The ongoing effort to recruit units into UF Active Directory and provide outreach is mandatory in order to realize the value of Active Directory at UF. Units must have confidence that Active Directory at UF is stable and supported 7/24. It is our intent to provide this level of service and commitment. Automation of manual processes, improved security, and wider availability of resources will be of great benefit to units campus-wide.
ARCHITECTURE
IMPLENTATION DECISIONS The following decisions were made in regard to the design and implementation: Single forest, single domain model Delegated Domain Name Server zones Single Sign On accounts will be in the root Domain in People OU segregated by Managed By affiliation (including users and groups). Local accounts, used for service accounts, will be located in departmental OU. Centralized DNS and WINS will be provided.
Page 10
ACTIVE DIRECTORY AND THE CAMPUS REGISTRY The figure below illustrates the information flow between Active Directory and the UF Registry.
Page 11
OUTSTANDING ISSUES / CONSTRAINTS A broker service will be developed for account creation and management. This service will interface with the existing campus registry and provide for automatic account management. This must be done in a stable and secure fashion and must preserve the privacy settings that currently exist in the Campus Registry. A password synchronization mechanism will be added to the existing GatorLink website. This mechanism will allow users to synchronize their existing GatorLink password with Active Directory. This must be done using SSL and the channel path of the password must be protected. Passwords will not be clear-text for any reason and the socket layer between the GatorLink website and AD must be properly isolated.
Page 12
PROJECT TIMELINES
An additional FTE will be hired in June 2003 for operational support to begin a four to six month pilot. The pilot portion of this project will be followed by a limited production roll-out to last three months followed by a brief evaluation. After this limited production period documents will need to finalized including a Service Level Definition and other necessary instruments to ensure proper relationships with campus units. The entire process for establishing Active Directory as a production system should take between nine and twelve months. Milestones Analysis/Planning/Design/Prototype Mock Migrations Setup and Test Production Document Roadmaps / Finalize Policies and Procedures, ready Service Level Agreement Limited Production (2-3 groups) Campus Wide Production Scheduled Start/Completion Date 06/03-10/03 10/03-11/03 12/03-01/04 01/04-02/04 02/04-04/04 04/04
PROJECT PHASES
The implementation of UF Active Directory will be performed in the following phases: Planning
Page 13
Within these phases, we will measure the progress and milestones. PLANNING Analyze Macro Design Version 1.0. Meet with all interested Campus Units and assess needs. Maintain monthly large group meetings with UF systems units. Put together first year budget geared toward developing a production Active Directory. Meet with Microsoft, Aelita, Dimension Data to get overall picture of migration process and third party solutions. Interface with OSG to understand Campus Registry and to lay foundation for operations support of AD.
STRUCTURE Develop Initial Project Plan Evaluate Project Infrastructure Develop and submit budget. Create Policies and Procedures. Develop Organizational Communication Plan Develop User Communication Plan Define End User Training and Change Management Strategy Publish & Approve Final Project Charter & Detail Work Plan
PROTOTYPE / DEVELOPMENT Setup Active Directory Service o Establish Prototyping Environment: Active directory (Hardware, W2K3, FSMO, DNS, WINS), Exchange o Security Checklist o Setup initial OU structure. o Develop Broker application o Populate with data from Campus Registry
Page 14
Page 15
DEPLOY Perform Cut-over to Production Assess Business and System Operations Conduct Project Acceptance Review Migrate First Groups into production AD
RISKS
In any project, risk is the likelihood that the project will not satisfy one or more of the following criteria: Meet the business need Complete on time Complete within budget Yield the anticipated business benefits
Identifying the risks to the project allows the project team to address them by developing strategies for: Preventing the situation from developing in the first place through risk management strategies; and
Page 16
Ensures completeness and appropriateness of steps to be undertaken before the project commences. Allows an appropriate level of contingency to be built into a project timetable. Allows senior management the opportunity to understand the risks associated with the project, and how these will be addressed by project management.
The primary tool for Risk Management is the Risk Management Plan. A Risk Management Plan identifies each risk, its classification, management strategies and contingent actions. Each risk is classified according to two criteria: The severity of the risk which is a measure of the impact it may have on the project schedule, budget, timeframe or business benefit; and The probability of the risk occurring.
Management strategies are those actions that the project team is to take to reduce the probability of the risk occurring. Introducing greater lead time into certain activities, using external resources instead of a UF resource, or increasing work product review frequency are examples of management strategies for dealing with risk. Contingent actions are strategies that will be implemented in the event that the risk does take effect. The initial Risk Management Plan for this project is as follows: Risk IFAS may not join central Active Directory Service unless remote sites are allowed to participate. Probability 30% Management Strategy
Mitigation at higher level and proper presentation of viable alternatives to dropping DCs at remote sites. Several alternatives have been suggested.
Campus units may not join 25% AD unless they are assured that the project is properly funded and has adequate FTEs to provide 7/24 support Lack of centralized CALS funding may make joining UFAD less attractive and cause less participation 10%
It is important that 3 FTEs be on board when AD goes into the production mode. Quantity discounts could substantially reduce the cost of CALs. This would also induce departments to join that otherwise would be hesitant For large enterprise with lean staffing third party solutions such as
Lack of Object Level Backup 10% and Restore capabilities may require additional resources.
Page 17
ASSUMPTIONS
The following are core assumptions upon which the implementation plan and the approach for implementation have been based: This directory is being designed as a university service that individual colleges and departments will have the opportunity to participate in. The decision to participate in the university Active Directory will reside with each college or department. Certain areas of the design are customized to integrate with the existing infrastructure at the University of Florida. These areas will require testing to validate the design. Testing and validation of the design will occur during proof-of-concept prototyping. A minimum of 4 Active Directory trained and certified FTEs should be dedicated to managing the enterprise forest root. Initially, this will probably start as two FTEs that work with the college LAN administrators during the standard workday to begin prototyping and piloting the Active Directory. As more colleges join the forest, additional support will be required to provide 7x24 support.
PROJECT DEPENDENCIES
Addition of Managed By attribute in campus registry. Adequate access to DB2 files in campus registry. Adequate FTEs and budget to support each major phase of the project: Design 1 FTE Mock Migrations 2 FTEs Limited Production 3 FTEs Production AD 7/24 3-4 FTEs.
Object level backup (Aelita ERDISK) and restore must be present before Active Directory service is offered as a campus-wide service in order to provide an automated way to restore deleted object and relationships. All required materials must be ordered and arrive on time when required in the project timeline. Premier Support Contact with Microsoft (TAM) established.
PROJECT BUDGET
Development budget for year one has been submitted and accepted.
Production Budget for fiscal year 2 is currently being worked on and will be available at a later date.
Page 19
GLOSSARY
AD Credential Active Directory. A directory service from Microsoft that is a part of Windows 2000. Something that can be presented by a user to a computer system to enable an authentication process. Usernames and passwords are credentials as are biometric identifiers and smart cards. Database 2. A family of relational database products offered by IBM. DB2 provides an open database environment that runs on a wide variety of computing platforms. A DB2 database can grow from a small single-user application to a large multi-user system. Using SQL, users can obtain data simultaneously from DB2 and other databases. DB2 includes a range of application development and management tools. Domain Name Service. Internet standard for associating IP numbers with domain names. Client Access Licenses. The client part of client-server architecture. Typically, a client is an application that runs on a personal computer or workstation and relies on a server to perform some operations. For example, an e-mail client is an application that enables you to send and receive e-mail. Domain Controllers. A domain controller is a computer running Windows 2000 Server that has been configured using the Active Directory Installation wizard. The Active Directory Installation wizard installs and configures components that provide Active Directory directory service to network users and computers. Domain controllers store directory data and manage user-domain interactions, including user logon processes, authentication, and directory searches.3
DB2
DNS CALS
DC
Page 20
Kerberos
LAN
LDAP NETBIOS
Network Basic Input Output System. An API that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).
Network Time Protocol. a protocol built on top of TCP that assures accurate local time keeping with reference to radio and atomic clocks located on the Internet. This protocol is capable of synchronizing distributed clocks within milliseconds over long time periods Redundant Array of Independent Disks. A method of organizing multiple disk drives into a single storage system to provide improved protection for data. Security Account Manager. The Windows NT 4.0 directory service and account database. Another term for macro or batch file, a script is a list of commands that can be executed without user interaction. A script language is a simple programming language with which you can write scripts. Technical Account Management. Microsoft provides for 200 hours
NTP
RAID
SAM Script
TAM
Page 21
WINS
Page 22