Active Directory Project Charter. Document Revision #: 1.05 Date of Issue: June 20, 2003 Project Lead: George Bryan

Transcription

1 Active Directory Project Charter Document Revision #: 1.05 Date of Issue: June 20, 2003 Project Lead: George Bryan

2 Document Change Control Revision Number Active Directory Implementation Date of Issue Author(s) Brief Description of Change 1.0 June, 2, 2003 George Bryan Initial Project Charter Incomplete 1.01 June, 5, 2003 George Bryan Iain Moffat 1.01 June, 6, 2003 George Bryan Iain Moffat Reorganize and Complete Initial Charter First Draft Complete 1.02 June 8, 2003 Mike Conlon Presentation, wording June 20, 2003 MC, GRB, IPM Presentation, wording 1.06 Sept. 5, 2003 GRB Cross-Realm removed. MIIS added. Page 2

3 TABLE OF CONTENTS BACKGROUND...4 PROJECT PURPOSE...4 SERVICES...5 PROJECT GOALS...7 PROJECT OBJECTIVES...7 SCOPE...10 APPROACH...10 ARCHITECTURE...10 IMPLENTATION DECISIONS...10 ACTIVE DIRECTORY AND THE CAMPUS REGISTRY...11 OUTSTANDING ISSUES / CONSTRAINTS...12 PROJECT TIMELINES...13 PROJECT PHASES...13 PLANNING...14 STRUCTURE...14 PROTOTYPE / DEVELOPMENT...14 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

4 BACKGROUND Active Directory Implementation The current University of Florida computing environment includes a wide range of servers, desktop and laptop computers, printers and other computing resources, spread across many distributed computing systems. These systems typically do not share resources and enable work between systems. Computer accounts can be created that may not be attributed to people that is, it may be unclear who is responsible for a computer account. Conversely, we are unable to determine which accounts belong to any particular individual. When a person leaves UF, we are unable to assure that computer access to all systems has been transitioned appropriately. Faculty, staff and students using these environments are unable to easily share resources across unit boundaries files and folders, printers and calendars are locally defined and managed. A person can not move from one unit to another and continue to work without having their computer environment deconstructed and reconstructed in the new location. People who work across units are confronted with disparate systems and multiple usernames and passwords. System administrators in these environments replicate each others work on a regular basis, performing the same tasks repeatedly at a local level without an ability to distribute the results of their work more broadly. In 1999, Microsoft introduced Active Directory as a unifying technology for bringing distributed computing environments together for the purpose of sharing resources and information. Active Directory provides a means for storing information about people, computers, other computing resources, and computing policies. Computing policies are rules that determine how computing resources can be used. In 2001, a group of UF system administrators formed a working group to consider how Active Directory could be implemented at the university. By 2002, they had produced a vision statement. This project was initiated in November of Following its initial conception, a consulting firm, Dimension Data was commissioned to do an initial macro design and migration plan of a campus wide Active Directory. Active Directory will be fully integrated with other university directory activities. In March of 2003 an Active Directory project lead position was hired. 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

5 Simplify the management of local environments at UF The following material elaborates on the purpose of the project. SERVICES Single Identity Active Directory Implementation Computer accounts will be attributed to people via GatorLink identity. At UF, each person has a GatorLink identity that is managed as part of campus directory services. Accounts in Active Directory will be attributed to a GatorLink identity, insuring that the university can determine who the account belongs to and who is responsible for work done using the account. This improves security and accountability. Single Credential and Sign-on GatorLink usernames and passwords can be used to login to network workstations. This reduces the number of usernames and passwords users must remember and use. For some systems, additional credentials may be required for access. Reducing usernames and passwords simplifies system use and password management. User Account Management User account creation/deletion and password reset will be managed through the GatorLink account creation process. Local system administrators will have full autonomy over local resources but will be relieved of the repetitive task of account creation. Integration with Existing Services UF Active Directory will be designed and built to interoperate with other pieces of the University of Florida s IT environment. Services such as authentication, campus registry, and name resolution will be integrated with the existing UF infrastructure. This makes it simpler for systems to be managed with UF Active Directory and to take advantage of Windows functionality. Managed Infrastructure UF Active Directory will be operated as a 24x7 production service, including Domain Name Service 1, 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. Simple Distributed Resource sharing across all of UF 1 These terms are defined in the Glossary at the end of this document. Page 5

6 Sharing files, printers and other resources across campus units is easily accomplished. UF Active Directory will provide the means for local Exchange services to be coordinated leading to sharing of address lists and calendars. Software distribution Local administrators can publish applications automatically to users desktops. New software and updates to existing software can be provided in an automated fashion without having to visit each user s computer. Automatic File Synchronization Users can indicate that folders should be synchronized between their desktop computer and a server. People who regularly use laptops and/or more than one computer will find this feature useful because it makes their files easily accessible regardless of which computer they are currently using. Distributed File Systems File folders can be created whose contents exist on several file servers. No drive letters are used, enabling a simpler and more flexible access to files located on servers. People who work with people in other units will find it straightforward to participate in work groups and access files. Computer and User Policy Management Local system administrators can create policies 2 for users or computers, which automatically configure common settings for security, software, user interface, and document management. Automated Group Membership Groups of users that exist or are created in the Campus Registry can become Windows security groups. Changes to a person s departmental affiliation and other group memberships are automatically reflected in the Windows Infrastructure. Migration Assistance UF Active Directory staff will assist units with migration to the UF Active Directory. Many tools, procedures and templates have been created. UF Active Directory will work with units throughout the project. Login to machines across campus With UF Active Directory users will be able to use their account to login as permitted to computers participating in the infrastructure. Practically speaking, many units will 2 These policies are rules that are automatically enforced by the system. They typically reflect a unit s 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

7 restrict login rights, but public workstations such as those in the libraries, labs, and elsewhere can potentially be used. 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 Develop a macro design that meets the 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. As a result, local units will be able to provide enhanced services: File services Page 7

8 Dynamic Host Configuration Protocol (DHCP) Remote Access Services (RAS) Mail services, e.g. Exchange Terminal Services Software distribution Site licensing services, i.e., paying for individual licenses 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 Provide Windows DNS Page 8

9 Requirements: Use centralized DNS on root DC s only Use Windows DNS to locate domain controllers in all domains in UF Active Directory UF Active Directory will be delegated control of its DNS zone ad.ufl.edu 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

10 Requirements: Provide a central support infrastructure for providing migration assistance Active Directory services will operate in a production environment 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

11 Windows 2003 and Exchange 2003 will be factored into the design Kerberos secret key will not be propagated outside of root Domain Domain Controllers run only Infrastructure Services not file, print, or application services Physical access to Domain Controllers limited to Data Center and ERP staff. Enterprise administrators will only make changes to Departmental Organizational Units in emergencies after going through proper change control Roaming profiles will not be used. Enterprise administrative changes will be audited and published to authorized local departmental staff. There is a centralized backup and restore of Domain Controllers performed by Data Center. Password policies will be consistent with GatorLink policies. Passwords will be synchronized in a secure fashion from GatorLink to AD only to allow down-level client software to function correctly. ACTIVE DIRECTORY AND THE CAMPUS REGISTRY The figure below illustrates the information flow between Active Directory and the UF Registry. Page 11

12 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

13 User accounts will be created and changed under the security context of a secured service account. This account will not have interactive logon rights but will have the appropriate ability to manage accounts. No other user or group will be able to change any fields replicated from the campus registry. Service accounts will be allowed in a limited fashion for campus units where justified, but the UFID and GatorLink ID can t be modified. A Manage By relationship will be added to the Campus Registry to regulate administration of accounts. This field will initially be populated with the AuthCode of the user s department. For undergraduate students this would be CIRCA. The value can be managed through the UF Directory to reflect the unit that manages a user s account if that unit is not the user s department. An agreement must be reached between IFAS and UF regarding a method for remote site participation in UFAD before IFAS will agree to migrate to UFAD. Password synchronization is required for single sign-on. 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 Scheduled Start/Completion Date Analysis/Planning/Design/Prototype 06/03-10/03 Mock Migrations 10/03-11/03 Setup and Test Production 12/03-01/04 Document Roadmaps / Finalize Policies and Procedures, ready Service Level Agreement 01/04-02/04 Limited Production (2-3 groups) 02/04-04/04 Campus Wide Production 04/04 PROJECT PHASES The implementation of UF Active Directory will be performed in the following phases: Planning Page 13

14 Structure Prototype / Development Transition Deployment 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

15 Pilot Migrations o Setup test lab access for pilot units. o Schedule and ready pilot participants for mock migrations. o Perform mock migrations o Test, adjust and repeat process if necessary. o Develop roadmap for future migrations. Document Detailed Requirements o Install, configure and design MIIS including an algorithm for broker and password synchronization application. o Flow chart data flow from all outside sources into Active Directory include attribute mapping from Campus Registry into AD. Develop Customizations o Develop and test broker service application. o Develop secure password synchronization method from GatorLink website. Develop Interfaces o Interface is required between the Campus Registry and Active Directory. This interface will involve MIIS, SQL and some.net customization. The purpose of this interface will be for automatic account management. Develop Conversions o Communication channels between all pertinent entities will be of paramount importance. Develop Reports o Statistical Reports o Errors from Root Server Event Logs. o Unsuccessful logins per day including IP number. o Successful Logins per day. o Baseline CPU usage on each AD server. o Baseline Memory usage on each AD server. o Network Traffic report. o Broker Reports o Accounts created per day. o Accounts changed per day. o Accounts moved including from and to locations. Page 15

16 o Accounts deleted. o Passwords changed per day by account. o Active Directory o Number of Computer objects by OU/OS. o Number of User Objects by OU. o Number of OU s. o Number of Groups by OU. TRANSITION All pertinent test lab information learned during pilot will be transferred to production Active Directory environment. Complete Systems Tests Complete Stress Tests Complete Security Tests Complete Policies and Procedures Train System Units 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

17 Minimizing the impact of the situation if it does occur through contingent actions. A risk management plan is beneficial because it: 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 Probability Management Strategy IFAS may not join central Active Directory Service unless remote sites are allowed to participate. Campus units may not join 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 Lack of Object Level Backup and Restore capabilities may require additional resources. 30% Mitigation at higher level and proper presentation of viable alternatives to dropping DC s at remote sites. Several alternatives have been suggested. 25% It is important that 3 FTEs be on board when AD goes into the production mode. 10% Quantity discounts could substantially reduce the cost of CALs. This would also induce departments to join that otherwise would be hesitant 10% For large enterprise with lean staffing third party solutions such as Page 17

18 ASSUMPTIONS Active Directory Implementation Risk Probability Management Strategy ERDISK is recommended. 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/ 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. CRITICAL SUCCESS FACTORS AD must provide single sign-on and single identity and maintain current privacy settings. Page 18

19 AD must be able to create and populate user accounts correctly from campus registry. Campus units must be able to successfully operate and manage their resources. AD must be operational 99.9% of the time. Users must be able to share resources across units. 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

20 GO FORWARD STRATEGY Active Directory Implementation The Go Forward Strategy indicates those tasks expected to be completed within the next 6-12 months to ensure a successful project start and execution. These tasks are expected to be completed by April Approve and distribute initial Project Charter Complete detailed project plan Initial development budget approval. Development and testing lab environment established. All custom applications complete. These applications include broker service, password synchronization and migration script. Policies, procedures and structural design complete. Budget for production deployment approved. GLOSSARY AD Credential DB2 DNS CALS DC Active Directory. A directory service from Microsoft that is a part of Windows 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 client is an application that enables you to send and receive . 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 3 Definition quoted from Page 20