Chapter 2: Envisioning Your Windows Security and Directory Services Solution

Article
12/05/2007

Introduction and Goals
Setting Up a Team
Gaining Commitment and Support of Sponsors and Stakeholders
Defining the Business Problem or Opportunity
Defining Business Goals
Creating the Vision Statement for Your Security and Directory Services Solution
Representative Business Scenarios
Assessing the Current Security and Directory Systems
Developing the Solution Concept
Defining the Project Scope
Defining the Project Structure
Assessing Project Risks
Estimating the Project Time Frame and Duration
Closing the Envisioning Phase

Introduction and Goals

This chapter provides the background and technical information required to complete the first phase—the Envisioning Phase—of the Windows Security and Directory Services for UNIX Guide project. The Envisioning Phase represents an early form of planning; its purpose is to get the project started by achieving a basic agreement between the business and the information technology (IT) organization on the goals for the project, its constraints, and the basic approaches that the project will use to meet the goals.

The guide makes the following basic assumptions about the state of the organization at the beginning of the Envisioning Phase:

A decision to investigate the project has been made by an IT manager who has sufficient budgetary authority to fund the investigation (Envisioning and Planning Phases) and who may or may not have sufficient budgetary authority to approve the entire project.
Initial estimates indicate that project benefits exceed related project costs, with the understanding that detailed return on investment (ROI) calculations cannot be made until the project scope is defined.
The work of the Envisioning and Planning Phases remains the same, regardless of whether the team that undertakes the projects is made up of in-house staff or consultants (whose involvement in IT for the organization can range from the undertaking of a single project to an ongoing advisory relationship).

Intended Audience

The Envisioning Phase chapter is intended for the listed audiences and fulfills the following objectives:

Business and technology decision makers. From their position outside the immediate project team, this group will learn about the business issues at stake to help them make, or participate in, the fundamental decisions that set the course for and define the limits of the project.
Consultants. Consultants who are responsible for planning, designing, and implementing solutions for security and directory services will get a high-level perspective that will help them to focus on critical issues for their customers in the initial decision-making process for the project.
Individuals filling lead roles on the project team. These team leads (typically the Product Management, Program Management, Development, Test, User Experience, and Release Management Roles) will be prepared not only to participate in the decision making but also to contribute to the deliverables that support and document the decisions. Going forward, the chapter's exploration of issues will equip team leads with the understanding required to guide the team in implementing the decisions.

Knowledge Prerequisites

This chapter assumes a high-level understanding of identity and access management technologies. (Basic concepts are discussed in Chapter 1, "Overview of Authentication and Authorization and Solution End States" to inform readers who are unfamiliar with the technologies.) In addition, project team leads should be familiar with Microsoft® Solutions Framework (MSF). The overview of MSF included in the UNIX Migration Project Guide will help team leads understand how the process tasks described in this chapter are designed to lead to the creation of a high-level view of the goals and constraints of the project that need to be agreed upon by the business (customer and project stakeholders) and the IT organization (IT management and the project team).

Major Envisioning Phase Tasks and Deliverables

Envisioning Phase tasks follow the basic sequence of identifying and defining the business problem, envisioning an ideal outcome in the context of larger organizational goals, and then developing a solution that the project will implement. In some cases, an organization might decide to restrict the scope of the project because of various constraints that apply, but it should be made clear how the project contributes to the realization of the vision.

The following table divides this approach into a list of major tasks and shows the deliverable that documents each task and the team role that bears primary (but not sole) responsibility for completing it. The timing of the tasks often overlaps and some tasks will span the entire phase. Many tasks require several iterations before a solution that is considered viable and agreeable by all interested parties and stakeholders is reached.

Table 2.1. Major Tasks , Deliverables , and Primary Owners

Task	Project Deliverable	Primary Owners
Set up a project team		Program Management Product Management
Identify stakeholders and gain their commitment		Product Management
Create the problem statement	Vision/scope document	Product Management
Clarify the business goals for the project	Vision/scope document	Product Management
Draft a vision statement	Vision/scope document	Product Management
Assess the current systems		Program Management
Define design goals	Vision/scope document	Product Management
Identify high-level requirements	Vision/scope document	Product Management
Define end-user profiles	Vision/scope document	User Experience
Define assumptions and constraints	Vision/scope document	Program Management
Define the project scope	Vision/scope document	Program Management
Define the solution concept	Vision/scope document	Program Management
Define the project structure	Project structure document	Program Management
Assess risk	Risk assessment document	Program Management

Note This chapter provides information about the essential tasks of the Envisioning Phase for a Microsoft Windows® security and directory services project. The chapter is not exhaustive in its discussion of processes. For a detailed description of all the activities and deliverables for the MSF Envisioning Phase, refer to the UNIX Migration Project Guide (UMPG), available at https://go.microsoft.com/fwlink/?LinkId=19832. The UMPG can be used to map MSF processes to the project management system used in your organization if this is necessary.

By the end of the Envisioning Phase, the team and all major stakeholders for the project should have agreed upon the following conceptual areas, documented their understanding in a vision/scope document, and formally approved it:

A vision for the solution
A solution concept
The scope of the project
An assessment of risks
A rough estimate of the project time frame and duration

Together, these conceptual areas comprise a high-level description of the project that forms the basis for further planning. The vision/scope document is a living document that represents a baseline; it might need to be revised as planning progresses and as dictated by new information. Refer to the UMPG for more detailed discussions on how to approach these tasks and deliverables and how to assign responsibility for them.

Job Aids

The job aids included with the Windows Security and Directory Services for UNIX Guide specific to the Envisioning Phase are designed to give the project team a jumpstart in creating the deliverables needed for this phase. These Microsoft Word templates and Excel® spreadsheets have been populated with information relevant to this project. Each job aid is mentioned throughout this chapter in the context of its specific use. Job aids are not part of the documentation; they are included as separate components of the solution in a Tools and Templates folder. The job aids relevant to the Envisioning Phase are:

Project Team Skills Template (Microsoft Word document)
End State Selection Tool (Excel workbook)
Vision/Scope Template (Word document)
Project Structure Template (Word document)
Risk Assessment Tool (Excel workbook)

Setting Up a Team

One of the first tasks in the Envisioning Phase is to set up a project team—that is, to establish who will do the work of the project and to assign specific responsibilities. The MSF approach is to structure a multidisciplinary project team around six core roles. The definition of each role begins with a focus on a fundamental goal that is generally considered essential for project success. The role is then assigned a "cluster" of responsibilities that will directly lead to the realization of this goal when they are carried out. Collectively, the responsibilities of a role often transcend the skill sets called for in traditional, specialized jobs. For example, the Program Management Role calls for both project management and architectural skills. A role may thus need more than one individual to fill it.

The MSF role names are referenced throughout this guidance to indicate who has responsibility for a particular task. If your team is structured differently, you might need to do a mapping to prevent confusion. The following table summarizes the MSF team structure, including core roles, associated responsibilities, and goals.

Table 2.2. Key Roles and Responsibilities of the Project Team

Role and Goal	Responsibilities
Product Management Goal: To satisfy customers	Ensures that the team addresses business goals and customer requirements. Manages customer expectations and communications. Plans launch.
Program Management Goal: To deliver solution within project constraints	Tracks and manages the budget and project schedule; drives risk management process; manages resource allocation; facilitates communication within the team; drives overall solution design; manages solution scope and critical trade-off decisions.
Development Goal: To build the solution according to specifications	Provides input on technical implication and feasibility of the solution; may prototype technology options; drives the development plan, infrastructure development, and configuration management. Develops the solution.
User Experience Goal: To enhance user effectiveness of the solution	Analyzes user performance and support requirements; may develop use cases and usage scenarios; defines user assistance documentation and training needs.
Test Goal: To approve solution for release only after all quality issues are identified and addressed	Articulates quality goals for the solution; defines test approach and acceptance criteria; creates test strategies to ensure quality of the solution; conducts tests; tracks all bugs; and communicates issues.
Release Management Goal: To achieve smooth deployment and ongoing operations	Defines deployment requirements and implications; creates rollout and pilot plans; manages deployment.

The Product Management and Program Management Roles are normally the earliest team assignments and carry the heaviest workload in the Envisioning Phase, including considerable interaction with IT senior management and other project stakeholders. Before the phase ends, however, persons need to be identified for each role, even if they are not yet fulltime participants. If the project is small, a six-person team (or an even smaller team, with one person filling two or more roles) might suffice for the entire project. For larger projects, roles such as Development are likely to require several persons, each with different specialized skills, to fill them. The MSF Team Model scales by having the core team member become the lead for that role and work with Program Management to bring on other individuals in the role as they are needed. For a more extensive discussion of the MSF Team Model, including team setup, communications, nonhierarchical structure, and scaling, see the UMPG.

The Project Team Skills Template Job Aid

The “Project Team Skills Template” job aid is designed to help you set up your team and identify skill and knowledge gaps (and thus the training needs) for the chosen team members. The job aid lists the roles and associated responsibilities at a more granular level than the preceding table. It also lists the specific skills and knowledge required to fill each role for this type of project and suggests the organizational job titles of persons who are likely to have the required skill/knowledge sets.

Special Considerations for Setting Up the Team for a Windows Security and Directory Services Project

This type of project can represent unique staffing issues for your project team. The solution(s) you choose to evaluate and implement will affect your staffing needs. For example, evaluating only packaged solutions will require fewer skills than those needed to evaluate open source solutions. Keep the following considerations in mind when selecting the project team:

Sourcing of expertise. Because of the broad range of skills required to successfully evaluate these solutions and deploy one of them, it may be difficult to build a team with all the required skills when drawing upon in-house resources. Therefore, it might be necessary to consider including outside resources.

It is relatively easy to find technical staff with a deep knowledge of UNIX or Microsoft Windows operating systems, but it is less easy to find technical staff that has a deep understanding of both of these areas. Implementation of the solution involves creating a bridge between the two environments. Make sure that the architect on the team has a sufficiently deep understanding of both UNIX and Windows to engineer the bridge's creation. If this skill is not available in-house, consider a consultant or a consulting organization with experience in implementing this type of solution. Consulting organizations often offer services to complete this type of project end-to-end, including implementation and data migration.
Timing of involvement. Ensure that the hardware and infrastructure experts from the Development and Test Roles are actively engaged during the Envisioning Phase. Experts in the Active Directory® directory service infrastructure need to be involved early in the process to ensure consideration is given to UNIX-related requirements, remote offices, and anything unique about the existing infrastructure. The UNIX administration experts need to be included early because they may have already addressed some of the challenges that the Active Directory infrastructure will need to address, such as remote offices, high-latency links, and administrative needs. Teams commonly overlook the hardware on which databases and applications are run until later than optimal in the project life cycle. Involving the experts early in the project helps inform more accurate estimates regarding budget, time, and resources.
Kerberos skill sets. Implementing End States 1, 2, or 5 requires Kerberos skills. Kerberos implementation differs between UNIX and Windows, and someone without experience with Kerberos in both environments might experience confusion. Ideally, your team includes members with significant experience using Kerberos in both environments. Differences in Kerberos implementation include: encryption types, key tables (for UNIX), Kerberos configuration (UNIX uses files, Windows uses DNS), and manual (UNIX) versus automatic (Windows) load balancing. (See the “Project Team Skills Template” job aid for more information about required Kerberos skill sets.)
UNIX skill sets. UNIX administrators are likely to be more familiar with command-line interfaces than with GUI-based tools and often make heavy use of scripting. You will need someone on the team to help these administrators access similar functions in Active Directory—scheduled jobs or at versus cron, general command-line tools, and remote access via ldapsearch-type tools. UNIX skill sets should also include knowledge of the differences between one UNIX distribution and the next (such as Solaris versus Red Hat). (See the “Project Team Skills Template” job aid for more information about UNIX skill sets.)
Windows skill sets. In general, existing Windows administrators may need a deeper understanding of the Active Directory structure—time synchronization, Kerberos, and LDAP—than they currently possess. You may need to involve team members who are highly skilled in Active Directory, and even then you might need additional training or outside help. The Active Directory team might not, for instance, have experience accessing the Active Directory database from the back end with ADSIEdit or similar tools or in adding computer accounts manually.

Windows administrators are likely to be more familiar with GUI-based administration tools than with command-line administration tools. They are also less likely to use scripting. These administrators may need additional training to make the translation. Acquiring these skill sets will help them to work compatibly with the UNIX administrators and to "talk the same language." Integrated security and directory services projects tend to expose Windows administrators to details and features not normally used in a Windows-only environment. (See the “Project Team Skills Template” job aid for more information about Windows skill sets.)
Other initiatives. If initiatives are underway in the enterprise related to identity management or with partners related to identity, gather input from these groups to gauge the impact of their work on this project.
Special requirements for administrative interfaces. It might be necessary or desirable to build new administrative interfaces or to integrate administration of this solution into your existing enterprise management tool. Solutions that are not packaged commercial solutions may require extending or building an administrative interface to incorporate the administration of computer accounts, Kerberos key tables, or UNIX user attributes. All the solutions include some tools for this; however, these tools may not be appropriate for deployment in your production environment or integration with your enterprise management system. You will need to evaluate the included tools and determine if they are suitable in your environment. If they are not, then you might need to develop a new interface or develop tools to integrate with your existing enterprise management system. You might need team members who can scope, design, test, and implement such a solution.
Career impacts. Because moving from authorization and authentication support on UNIX to Active Directory is a major paradigm shift, it may have an impact on the employment and careers of existing personnel. Take this issue into consideration when forming the team and carrying out the migration. Change is often inevitable, but it may also be met with resistance. Acceptance is more likely if the change is perceived as an opportunity to expand and develop skills.
Collaboration between UNIX and Windows personnel. Collaboration between UNIX and Windows personnel is essential for the success of the project but may present a challenge because of "historical" rivalries and cultural differences between the two groups. It is recommended that you openly acknowledge the differences in points of view while emphasizing the necessity to collaborate in building a viable solution.

Some approaches that can help promote collaboration include:
- Building a cultural bridge through education of both groups about each others’ platforms, capabilities, tools, and management methods to help overcome misconceptions.
- Positioning the required changes as containing career growth opportunities and following through with the opportunities.
- Involvement by all, especially UNIX administrators, in designing test and proofs of concept (POC). Invite UNIX administrators to design rigorous tests or a POC for Active Directory that would address any concerns they have about its performance, strength, or security.
- Encouraging UNIX administrators to help build a robust structure by voicing their concerns regarding the performance and security of Active Directory. Encourage Windows administrators to listen openly to these concerns and use the project as a learning opportunity to find ways to address them.
- Offering to have a third party do a security audit or architecture audit of the Active Directory infrastructure to show that it is sufficiently robust for the solution.

Gaining Commitment and Support of Sponsors and Stakeholders

Successfully fulfilling a major goal of the Envisioning Phase—to reach agreement on the high-level goals and requirements for the project—requires that business sponsors and key stakeholders outside of the project team be involved in major decisions concerning the project.

Securing stakeholder commitment means ensuring that the project's stakeholders agree with the need to solve the problem and that they are willing and able to commit resources. Discussions should lead to the resolution of potential conflicts and a formal endorsement of the project by all stakeholders at the end of the Envisioning Phase, including an approval of the vision/scope document at a milestone meeting.

Identify Key Stakeholders

The identities of all stakeholders might not be immediately apparent. Members of the core team need to call upon their technical and role-based expertise to identify organizational groups and individuals that the implementation activities, or outcome, of the project will affect. For example, Operations is considered a key stakeholder because they are the IT organization responsible for ongoing operation of the solution after it is delivered.

In fact, this solution can affect almost everyone in the organization at all levels. One way to make sure all affected people are represented in some way is to consider the impact of the project from several viewpoints:

Employees (including end users)
Application owners
Internal development groups
Corporate management (including finance, audit, risk management)
Operations management (including backup, help desk)
Other IT management (including provisioning, hardware acquisitions, UNIX IT administrators, Windows IT administrators)

It is important to not underestimate the amount of buy-in needed across the enterprise because a Windows security and directory services project affects everything in the IT infrastructure.

Facilitate Key Stakeholders' Involvement

Ongoing stakeholder participation is important to the success of the project. Major milestones at the end of each subsequent phase represent opportunities for the stakeholders to review the progress of the project. By definition, the stakeholders are invested parties and their role is to ensure that the project is on track to meet the agreed-upon goals. Additionally, they alert the team to circumstances that necessitate a change in some aspect of the project.

Stakeholders also contribute to project success by serving as its champions within the organization, helping to overcome possible resistance to change. Conversely, they sometimes derail a project by withdrawing support. Project teams need to be aware of the importance of stakeholders and keep in mind the need to maintain a positive relationship with them.

Defining the Business Problem or Opportunity

Defining the business problem or opportunity is the starting point for deciding what you want an integrated security and directory services project to accomplish. This leads to the formation of specific business goals, which are then examined within the context of broader and long-term business goals to ensure congruence. You can then capture the most important aspects of your goals by formulating a vision statement that helps guide the project to its completion. The discussion in this section of common triggers for security and directory services projects is intended to help you capture the most important drivers for your organization.

There are three basic reasons (or categories of reasons) why organizations decide to investigate and deploy an integrated security and directory services solution. These categories may be viewed as business drivers, or motivations, and each can apply to many specific situations:

Reduce cost
Increase effectiveness (including organization, staff, systems)
Increase compliance (internal or external)

Cost savings is normally the overriding goal when pursuing an integrated security and directory services solution. However, it is often an event or a situation (the result of a series of events) that finally tips the balance and causes an organization to seriously consider a security and directory services project. A merger or isolated security incident are examples of single events that could trigger this decision. Systems that are overly complex or that have a large number of users after years of growth are examples of situational triggers.

Both triggers cause a specific business problem, commonly referred to as a "pain point,” that becomes a priority for the organization to solve. Resolving the pain point becomes the primary business driver for undertaking the project.

The following is a list of 13 events and situations that commonly motivate organizations to investigate an integrated security and directory services solution. Identifying your situation on the list will help you formulate your business problem. Consulting with the stakeholders discussed earlier, each of whom can view any one business driver differently and assign it a different level of importance, can help in evaluating the relevance of these drivers to your organization. In a later section, six business scenarios illustrate some of these triggers.

Common Triggers Leading to Integrated Security and Directory Services Projects

Regulatory or policy changes (internal or external). Regulatory changes (such as HIPPA or SOX) may require changes to password policies, data encryption, and authorization procedures in order to satisfy new auditing, security, and time requirements. Internal policy changes may have other drivers that inspired them, including liability, goodwill, and consumer perception. An example of an external policy change is new policies adopted by a credit card company for applications that process credit cards. Therefore, the credit card company requires that you adhere to these policies in your applications to continue dealing with you.

See Scenario 2b: Northwind Traders in the “Representative Business Scenarios” section.
Merger or acquisition. Mergers and acquisitions can spawn a number of reasons to examine a security and directory services solution, including needs to:
- Merge, consolidate, and eliminate redundancy in the multiple data stores from the previously separate environments.
- Meet new requirements for access to systems (new group of users need access to a particular system).
- Satisfy new policies or regulations that now apply.
In general, a merger or acquisition means that the IT systems need to, at a minimum, work together. Typically the systems are also examined to see which ones make sense to keep and what major changes are reasonable to undertake.

Most mergers and acquisitions have cost savings as a fundamental goal, with the expectation that the combined entity will be more efficient. As a result, management often looks for cost-saving opportunities in the post-merger organization.

See Scenario 3: Fabrikam.
Overloaded administrators and help desk. If multiple directories exist in the organization, user provisioning, deprovisioning, changes to access, and password changes can start to overwhelm the IT and help desk staff. Maintaining the directory infrastructures (including backups and patches/updates) also becomes a large burden.

The problem may worsen because of organizational growth, introduction of new applications, or staff reductions. Also, the extra required administrative effort might prevent the IT department from completing other projects.

See Scenario 2a: Walnut University and Scenario 5: Maple University.
Aging software , operating systems , and hardware. Part of the infrastructure for your existing authentication or authorization system is aging or expiring. Any of the following situations may apply:
- Hardware has aged and is becoming unreliable.
- Hardware has reached the end of lease.
- The vendor is ceasing support for the specific hardware, software, or an operating system you are using (for example, Sun has discontinued support for NIS and NIS+).
- The vendor is changing license agreements or is undergoing other changes that make it impossible or undesirable to continue to use its products.
- The vendor itself is ceasing operations and there will no longer be support for a product you are using.
Significant effort may be required to move to newer models or versions and organizations may choose to pursue a different solution instead of an upgrade.

See Scenario 2a: Walnut University.
Deployment of new services. New applications or services that need to be accessed from both Windows and UNIX platforms are planned for deployment. Organizations must anticipate and plan for costs of development and deployment, manageability, and system flexibility.

See Scenario 1: Litware, Inc.
Occurrence of event related to security. A significant security event in the organization or in related organizations such as partners, competitors, suppliers, or customers results in the organization investigating ways to improve security. Security events include break-ins, leaked data, and other electronic or physical threats. Security events also include the inauguration of new regulations imposed by governmental legislation (such as HIPPA or SOX), new internal policies, and new policies adopted by partners, customers, or industry groups, which affect security. (See item #1 Regulatory or policy changes.) Each of these events drives the organization to strengthen security.
Recognition of the need to simplify (and typically standardize) the environment. The organization recognizes that the IT systems are too complex and need simplification for auditing and compliance purposes. This situation is really tied to cost reduction.

Note Simplifying can be seen as another way of stating other drivers in this list as well, or may be a major component of other drivers in this list.
A new requirement for various applications to work together or be available to a wider audience. This requirement includes the need to extend functionality to new platforms or to cross-platform users (for example, Windows users needing access to UNIX applications). It sometimes manifests itself as the decision to use a new enterprise application in the organization, resulting in the need for various existing applications to now interact with the new application. Examples of this type of scalability issue include PeopleSoft, SAP, and identity management applications.
Organizational growth. The organization is growing because of the introduction of remote offices or other special challenges and could benefit from a new approach. Challenges might include adding support for access over satellite links, supporting increasing numbers of telecommuters, supporting contractors who come and go frequently, integrating outsourcing partners, and interacting with or providing accounts to partners, customers, or suppliers. Projected future growth requires that the solution meet not only the current growth needs, but be scalable into the future.

See Scenario 4: Humongous Insurance.
Personnel changes. Staff growth, staff reduction, and outsourcing means that different people are now using or administering the systems. This situation typically involves an organization that uses complex, homegrown tools and has a set of new users who were not the original developers of the tools but who now need to use and maintain them. Without significant learning time, the new team will not have the same level of expertise with the tools as the original developers. Therefore, the organization needs to reduce the skill sets required for use of the tools.

This item is closely related to item #5, Deployment of new services, which is often associated with personnel changes.
Need to increase environment stability and uptime. Each separate infrastructure in an enterprise adds to the complexity of the environment, and complex environments are more challenging to keep stable and available. The challenge is even greater if one infrastructure is using an older or obsolete technology. This situation is most likely to occur in an older organization that has developed a complex environment over time.

A system downtime event is the most likely trigger for an organization to recognize the need to improve stability and uptime and look for ways to accomplish it.
Desire to implement integrated identity management and single sign-on (SSO). SSO and identity management are often on the radar for organizations and can become a priority as productivity, cost, and security issues increase. In this case, SSO and identity management are perceived as obvious goals in themselves because they provide answers to many problems and have demonstrated their benefits so well.
Desire or need for cost reduction. Organizations are sometimes just looking for ways to reduce costs.

Defining Business Goals

Business goals are implicit in the business problem or opportunity, and articulating them may be as simple as stating what is necessary to solve the problem that is the primary impetus for the project. When articulating your goals, however, keep in mind the entire range of problems that can be addressed with an integrated security and directory services project. It should be clear from the preceding list that the types of problems that can be addressed with this solution are likely interconnected. Fortunately, this means that the opportunity exists to address related but less urgent problems while tackling the most painful problem, which can result in achieving multiple goals with this solution.

As mentioned earlier, it is important to keep in mind the broader goals and future plans of the organization itself. For example, is the business planning to expand and, if so, by how much and in what directions? The business goals for the project should support the broader business goals of the organization and accommodate, or at least not conflict with, future plans.

The following is a list of general business goals. Each goal is accompanied by examples that connect business goals with technology by showing how an integrated security and directory system might address the goals. You can use this list as a starting point for articulating your own goals.

Increase user productivity
- User accounts are likely to proliferate in a heterogeneous computing environment, necessitating several passwords. An integrated security solution allows for use of the same user name and password to log on to multiple platforms and potentially use single sign-on to access applications, ultimately saving time in remembering, tracking, and resetting passwords.
- If you have an obsolete technology that is incompatible with some of the diverse components making up your systems, these incompatibilities can create barriers to information-sharing and user productivity. These barriers can be eliminated by replacing the old technology with an integrated security system based on open standards such as Kerberos and LDAP.
Increase the availability of information and services to users and applications
- Directories store information such as an address or telephone number and make it widely available to users and applications within your organization. When there are two or more unsynchronized directories within your organization, users and applications must search more than once for each piece of information. Single, integrated directory services accessible by all client computers and applications make published information immediately available to the entire organization.
- The introduction of new services, mergers and acquisitions, personnel changes, and outdated hardware and software can all result in the need to improve access to information and services.

Note Metadirectory services and other technologies can be used to ensure that two directories are synchronized so that all information appears in both directories. Users can then find what they need with a single search. However, in this case, data is duplicated in two or more places and the synchronization system must be maintained.

Reduce ongoing costs (administration , help desk , licensing , and support)
- Reducing infrastructure complexity and associated hardware, software, and personnel costs often means significant cost reductions in IT operations.
- Integrating two systems into one, thereby reducing the number of accounts, should reduce the number of administrative tasks such as creating, updating, canceling, and troubleshooting accounts. Moreover, maintaining two systems requires either maintaining two sets of administrators or training new administrators in the skills required for each system. These costs are reduced when skills in only one system are required.
- Directory consolidation and single sign-on are often viewed as useful ways to reduce help desk costs because they can reduce the number of calls from users having trouble managing multiple passwords and needing password resets. (See "Increase User Productivity.")
- Older technologies are frequently incompatible with other system components, adding to administration complexity. Removing this source of complexity can reduce troubleshooting costs.
Reduce the risk of service unavailability
- When security and directory systems are operating in a system-specific manner, each client must find a server of its own type to secure service. Server availability to all clients can be improved with an integrated security system in which one server is capable of authenticating clients from all operating systems. This assumes, however, a high-quality system design with sufficient redundancy.
- By adopting technologies such as Kerberos and LDAP that are based on open standards and interoperate with many systems, you decrease the risk of losing support should a single manufacturer cease producing the technology.
Improve the security of your organization's systems
- You can improve security by implementing an authentication mechanism where passwords are not sent in the clear (if your current system does not already have one). Centralizing authorization data can also help by decreasing the types of infrastructure, which increases the efficiency and reliability of removing access when it is no longer appropriate, and by replacing any unsecured access channels with secured channels.
- Directory consolidation and single sign-on help solve security problems when the burden of remembering and using multiple passwords leads to insecure practices, such as the use of simple passwords, writing down passwords, and account sharing, where several users share a single account and password.
- Obsolete technologies are more likely to have vulnerabilities that are well known to attackers. Replacing them with LDAP v3 and Kerberos v5 (the latest versions of open standards), which include resilience to the latest security attacks, will improve security.
Comply with new regulatory requirements , business policies , or industry best practices
- New regulations and policies often call for a level of auditing capability, security provisions, and the capability to meet time deadlines that is not possible with current systems, but that this solution can achieve.

Note The Product Management Role is responsible for driving the determination of the business goals and requirements and ensuring that they reflect input from the appropriate stakeholders. Development and Program Management are also key contributors, and all roles must read, understand, and agree upon the business goals. Product Management documents the business goals in the vision/scope document.

Creating the Vision Statement for Your Security and Directory Services Solution

After you have explored the problems and opportunities you want to address and have articulated your business goals, you can begin drafting an initial vision statement. This statement describes the desired future state of your organization's environment at solution completion in clear and concise language. The vision statement is an unbounded view of the solution that, in fact, might never be completely achieved. Later in your decision-making process, you will narrow the unbounded view into what will and will not be included in this particular project when you define its scope. More than one project may be required to fully realize the vision.

The Vision Statement's Purpose

It can be tempting to skip writing a vision statement and let your project be guided by a simple list of business goals. Failing to achieve consensus around a crisp, strong vision statement, however, is a critical failure factor for a project. The vision statement helps to ensure project success in the following ways:

Because it must be agreed upon, the vision statement helps stakeholders think through and voice their priorities. This often leads to the surfacing of conflicts that are easier and far less expensive to address at the beginning of a project than at the midway point or later. Thus, the statement helps mitigate the risk of a stakeholder derailing the project at a later stage.
The process of creating a vision statement helps participants to think broadly instead of myopically, opening up possibilities and helping to capture opportunities to realize additional value.
The articulated statement can serve as motivation to business sponsors and stakeholders to commit to the project initially as well as provide their ongoing support.
After agreement is achieved, the vision helps the project team maintain focus on the most essential goals during the course of the project by serving as a decision-making guide.

A good vision statement is short enough to be remembered, clear enough to be understood, and strong enough to be motivational. You may be able to use one of the following sample visions—at least as a starting point. Writing it is often an iterative process and you might need to revise it many times before it is acceptable to all stakeholders. Program Management records the statement in the vision/scope document. (See the “Vision/Scope Template” job aid for more information.)

Sample Visions

For a Windows security and directory services project, there are essentially two possible core visions. The first vision is the most complete and robust; it is realized by achieving either End State 2 or 4.

All users of IT systems can access any system in the organization for which they have the appropriate permissions by signing on once with a single user name and password. All security-related user information is stored in one place. (A shorter version of this is: "One user name , one password , one place for user information.")

This vision addresses the needs of two groups in the organization: the end users of the systems and the administrators and other IT personnel who manage the systems. The single user name and password benefits end users directly and administrators indirectly and the single store reduces administrative work.

The second vision is more restricted, omitting the second part of the first vision. It describes End States 1, 3, and 5.

All UNIX and Windows users can access any system in the organization for which they have the appropriate permissions by signing on once with a single user name and password.

Important To realize either vision, you might need to tackle the project in phases, depending upon the complexity of your systems. You might, in fact, choose to defer, indefinitely, working on some aspect of this vision. Nonetheless, your vision should reflect your ideal of where you would like your organization to be. The older your organization and the more systems present, the more likely it is that your environment is complex. Consequently, the more likely it is that a multiphased project will be required to implement your vision. Factors that generate complexity include: acquiring other companies, evolving through several waves of information technology, and making many small incremental changes to existing systems over time.

Because the second vision is a more restricted version of the first vision, the end states it leads to could represent preliminary stops on a route that eventually leads to the achievement of the first vision. For example, it is possible to get to End State 4 via End State 3, or to End State 2 via End State 1.

Representative Business Scenarios

To demonstrate the connections between business problems, business goals, and vision statements, six typical business scenarios are described in this section. Each scenario includes key facts about the organization's existing IT infrastructure and the business drivers for change. Although it is unlikely that any one scenario exactly matches your situation, you may find it helpful to identify the one that seems closest as a starting point for deciding upon a "best fit" end state. The scenarios are deliberately kept at a very high level so that the salient differences between them are the factors that would cause you to choose one end state over another.

Note that, for each scenario, the suggested vision statement is considerably broader than the specific drivers mentioned for the scenario. This is consistent with the purpose of developing a vision: to provide an unbounded, best-of-all-worlds view of where you want the organization to be. The actual project scope will be more constrained, as is discussed later in this chapter.

Note Scenario 1 leads to End State 1 as the best choice, Scenarios 2a and 2b to End State 2, Scenario 3 to End State 3, Scenario 4 to End State 4, and Scenario 5 to End State 5. However, a key difference between your scenario and the sample scenario that first appears most similar may require you to choose another path.

Caution If your situation is radically different from any of the described scenarios, it is possible that the solutions provided in this guide are not suitable for your organization.

Scenario 1: Litware, Inc.

Litware, Inc. has existing computers running UNIX and Windows operating systems; these computers use different stores for account data. On the UNIX-based computers, the accounts are managed using local files and the standard UNIX authentication mechanisms. A set of complex homegrown tools is used to manage those files to precisely control which users are authorized to access which applications on which computers. The applications are written specifically to rely upon this authorization structure. New human resources and productivity services are being deployed on the Windows-based computers, and UNIX users need access to these services. In the current environment, new Windows accounts need to be created for the UNIX users in order to provide access to the new services, which are Kerberized. The necessity for multiple accounts and passwords is difficult for users and creates help desk overhead.

Current Infrastructure:

Account management for UNIX and Active Directory environments is entirely separate.
Account management for UNIX environments is not centralized.
Application requirements dictate maintaining customized authorization systems.

Problem Statement:

UNIX users need access to new services being deployed on the Windows platform. (See trigger #5, Deployment of new services.)

Primary Business Goals:

Make Windows services available to user and service accounts that currently exist on the UNIX-based computers (increase the availability of information to users and applications).
Reduce ongoing costs by simplifying administration and help desk tasks.

Additional Business Goals:

Increase system security.
Increase user productivity.

Vision Statement:

All UNIX and Windows users can access any system in the organization for which they have the appropriate permissions by signing on once with a single user name and password. Users get timely responses to requests for administrative and help desk services.

Scenario 2a: Walnut University

The Walnut University infrastructure is currently limping along on outdated hardware that is past its useful life. The increasing use of computing resources by staff and students on multiple platforms is overloading the systems and administrators. The outdated hardware must be replaced, but this must be accomplished on a modest budget. Security for the environment as a whole needs to be improved.

Current Infrastructure:

Active Directory infrastructure exists.
Existing UNIX authentication and authorization system uses NIS.
Account management for UNIX and Active Directory environments is entirely separate.
Staff and students log on to shared UNIX workstations to access UNIX-based applications.

Problem Statement:

Capacity of systems and administrators has been exceeded due to old hardware and increasing use of systems. (See triggers #3, Overloaded administrators and help desk and #4, Aging software, operating systems, and hardware.)

Primary Business Goals:

Replace outdated hardware/software on a tight budget.
Reduce ongoing costs by simplifying administration and help desk tasks.

Additional Business Goals:

Increase system security.
Increase user (university staff) productivity by introducing single sign-on.

Vision Statement:

All users of IT systems can access any system in the organization for which they have the appropriate permissions by signing on once with a single user name and password. All security-related user information is stored in one place. (The short version is: "One user name, one password, one place for user information.")

Scenario 2b: Northwind Traders

Northwind Traders is faced with bringing their systems in line with regulatory requirements, which include securing all sensitive information with data encryption and minimizing operational risks. Their current systems do not consistently use data encryption for internal network communications. Recent problems with downtime on critical systems have made clear that the wide variety of separate infrastructures in the enterprise, some using obsolete technology, presents a risk.

Problem Statement:

System changes must be made to comply with regulatory requirements. (See trigger #1, Regulatory or policy changes.)

Primary Business Goals:

Meet security-related regulatory requirements.
Reduce the risk of service unavailability.

Additional Business Goals:

Conform to new industry or organization policies/best practices.
Contain administrative and help desk costs.

Vision Statement:

All users of IT systems can access any system in the organization for which they have the appropriate permissions by signing on once with a single user name and password. All security-related user information is stored in one place. The security infrastructure complies with all current regulations and is flexible enough to accommodate future changes. (The short version of this vision is: "One user name, one password, one place for user information.")

Scenario 3: Fabrikam

Fabrikam currently uses LDAP for authentication and local files for authorization. When the existing LDAP directory was implemented, it was intended to be used as the central authentication data repository for the entire infrastructure. However, the recent merger of Fabrikam with another company has introduced many other systems into the environment using diverse data repositories (a large Active Directory infrastructure plus several smaller UNIX systems). The existing, outdated LDAP directory is only used for authentication to the pre-merger UNIX systems, and the introduction of multiple other proprietary data stores in mission-critical roles has created a large administration burden. There is no way to export the contents of the proprietary data stores, which prevents total consolidation.

Current Infrastructure:

Existing UNIX infrastructure uses LDAP for authentication.
A small Active Directory infrastructure exists.
A new, large Active Directory infrastructure has been brought over from the other company.
Several new, small UNIX environments using diverse authorization methods have been introduced by another company.
Users have multiple logons to access the many different environments.

Problem Statement:

The merged company has too many data stores to operate efficiently, from both administrators' and users' points of view. (See trigger #2, Merger or acquisition.)

Primary Business Goals:

Consolidate authentication IT from pre-merger companies into a single unit (data store).
Reduce ongoing costs (administration and help desk) by simplifying authentication.

Additional Business Goals:

Increase access to information and services by users and applications across the organization.

Vision Statement:

All UNIX and Windows users can access any system in the combined organization for which they have the appropriate permissions by signing on once with a single user name and password. The flexible security infrastructure will accommodate significant change in corporate structures.

Scenario 4: Humongous Insurance

Humongous Insurance currently uses an LDAP directory for both authentication and authorization of UNIX-based computers. In addition, they have an existing, small Active Directory infrastructure serving a separate, small user base. The organization is experiencing dramatic growth and opening new offices. Staff in remote offices will be using Windows clients but will also need access to computers in the UNIX environment via remote logon. The current infrastructure does not have the capacity to handle the increased load of authentication and authorization and the existing system does not encrypt LDAP traffic.

Problem Statement:

Employees working from new, remote offices must be given secure access to systems in order to do their jobs. (See trigger #9, Organizational growth.)

Primary Business Goals:

Allow users in remote offices to remotely log on to the UNIX computers.
Meet growing demand for authentication and authorization services.
Contain ongoing administrative costs by simplifying the environment to enable administrators to support more people.

Additional Business Goals:

Increase user productivity.
Increase system security.

Vision Statement:

All current and future users of IT systems, regardless of location, can access any system in the organization for which they have the appropriate permissions by signing on once with a single user name and password. Security-related user information is stored in just one place.

Scenario 5: Maple University

Maple University has a large UNIX environment with many legacy services using Kerberos for authentication. An increasing number of Windows users need access to the services in the UNIX environment. As the base of Windows users needing access to UNIX services grow, the administration overhead and user burden inherent in using multiple user names and passwords for the differing environments increases. The university's IT budget for staff, software, and hardware is small, however, and will not support dramatic changes to the existing environment.

Current Infrastructure:

Existing UNIX-based Kerberos server is used for authentication in the UNIX environment.
Active Directory is used for authentication in the Windows environment.
Active Directory and UNIX environment authentication data are maintained separately.
Several key applications in the UNIX environment use Kerberos for authentication.

Problem Statement:

Administrative load has outgrown capacity of system administrators to handle it. (See trigger #3, Overloaded administrators and help desk.)

Primary Business Goals:

Make UNIX services available to users in the Windows environment.
Contain project costs.
Reduce ongoing costs (help desk).

Additional Business Goals:

Increase user productivity.

Vision Statement:

All UNIX and Windows users can access any university system for which they have the appropriate permissions by signing on once with a single user name and password. Minimal changes, low costs, and a short project duration—yet it's easier to do more.

Assessing the Current Security and Directory Systems

Achieving an understanding of your current situation is a vital step early in any project. Just as defining your problem statement, resulting business goals, and vision clarifies where you want to get to, assessing your current systems establishes your starting point. A current state assessment entails both an inventory of your current systems and an evaluation of them in light of the business goals you defined.

You may find it convenient to approach inventory-taking iteratively, beginning with the relatively high-level information that is needed for early Envisioning Phase decisions. To determine the best way to scope your project, you will find it helpful to have more knowledge about your current systems, and then when you move on to the Planning Phase and need to make concrete planning decisions for project plans, you will need a great deal of detail.

Inventory Your Current Systems

Performing an inventory is a task that can be done in parallel with the work that goes into articulating a vision. In addition to the specific decisions that inventory information supports, having an overall understanding of your inventory picture will help you to do the following:

Identify high-level technical requirements and issues that must be addressed.
Determine the technical feasibility of a possible solution by applying the identified requirements.
Recognize opportunities for addressing a cluster of related problems with a particular solution.
Identify elements that are not supported by the solution and thereby mitigate the risk of disabling functionality. For example, you may plan to retire parts of your existing infrastructure, but discover a system that currently relies on it, such as an older UNIX operating system that implements Kerberos and LDAP in ways that are not compatible with Active Directory.
Complete a gap analysis that measures the difference between the capabilities of your current system and the capabilities required to achieve your business goals.
Understand the extent of the effort in terms of time, dollars, and resources required to implement a solution.

Whether you complete your inventory at this time or delay the collection of detailed information until the Planning Phase is underway, your inventory should focus on the following general categories:

User and identity management infrastructure. You should document the scale and range of the user and identity management infrastructure currently employed within the organization. Identify and describe all user databases and identity stores regardless of their purpose or location.

A human resources database, for example, might be overlooked because it is not, strictly speaking, a directory and used by an individual department at a single site. Include this in the evaluation because it may be possible to incorporate it into the integrated solution you create. It can be used as a source of user names for bulk administration operations.

For each infrastructure component, you should record the technology that each employs and its current version. In addition, you should determine which technologies support the Kerberos or LDAP protocols and are compatible with the Active Directory implementation of these protocols. Those that do so will require little or no modification to take part in your integrated solution.
Network topology. Obtain network diagrams from network managers. These should include segment bandwidth capacities and the bandwidth capacity of the interfaces to servers affected by this project. If possible, obtain current figures on network utilization.

This is important because a significant proportion of network traffic can be related to authentication, authorization, and directory lookups. The current project may result in an increase or decrease in network traffic.

Some changes made by such a project tend to decrease the network load. For example, a single integrated directory does not require clients to query twice to search all information, whereas a directory split between UNIX and Windows does. If you are using a metadirectory service to keep two directories in agreement, the synchronization traffic may be significant; it is removed by creating an integrated system.

Other changes can increase network traffic. These include switching from using a nonencrypted channel for retrieving authorization data to an encrypted channel to retrieve this data, or switching from a local data store to a server-based data store. The latter would result in increased traffic only if in the present configuration there is no system for synchronizing data between local data stores. If there is a homegrown tool that takes the data from a local file on computer A and synchronizes it with local files on computers B and C, this will probably create about as much traffic as would replacing this and migrating computers A, B, and C to using a centralized server-based data store.

It is not possible to accurately estimate how traffic will change in response to your solution until the Stabilizing Phase of the project. However, detailed knowledge of the network will influence your design.
Access control mechanisms. The access control mechanisms within your organization determine which resources a given user can access and what actions they are permitted to perform. Your evaluation of these mechanisms must describe how they are implemented and used in Windows and your versions of UNIX. In particular, document the mechanisms' support, if it is included, for the Kerberos and LDAP protocols and whether this support is compatible with the Active Directory implementation of these protocols. For example, if you have a RADIUS service, then you should investigate and then document whether RADIUS user accounts can be held in a remote LDAP directory such as Active Directory.
Management procedures. List the administration and management procedures that are in place pertaining to authentication, authorization, and identity management. These procedures guarantee quality and consistency. Many of them can be carried over into the new solution, albeit with revisions because of the new features, user interfaces, and administrative tools. Others can be discarded. For example, if you have dispensed with a metadirectory service because you now have a single integrated directory, you no longer need the procedures for maintaining that service.

The following actions and events related to system and network administration include procedures that might be affected by this project:
- Management of user accounts
- Changes to access controls on resources such as files, printers, and the directory
- Publishing information in the directories
- Modification of the directory schemas
- Changes to the configuration of authorization mechanisms
- Changes to the configuration of authentication mechanisms

Developing the Solution Concept

If the business goals and vision define what the project is expected to accomplish, the solution concept addresses how the solution will accomplish these goals. It explains at a high level how the solution will solve the business problem in terms of the approaches (most importantly, the technical approach) it will take to build and deliver the solution. It includes an early description of functionality, an initial approach to building and delivering the solution, and project success factors and acceptance criteria. The result is the first summary of the system that you are proposing and becomes a significant part of the vision/scope document.

Because the solution concept will be evaluated by an audience with varying technical expertise (IT management, customers, stakeholders, and team members), it should be written in nontechnical language. It should not go into great technical detail; you will add the details as part of the work of the next phase (Planning). However, the solution concept should include enough information to inform feasibility studies, risk analysis, usability studies, and performance analysis.

Note Solution concept is an MSF term that should not be confused with the other use of the word solution (or technology solution) in this guide: the implementation of the end states.

This guide simplifies the process of developing the solution concept by offering five fully developed solutions (the five end states described in Chapter 1, "Overview of Authentication and Authorization Technologies and Solution End States"). The guide also describes technology alternatives for achieving each end state, as shown in the following table.

Table 2.3. Alternatives for Achieving Each State

1st Decision: End State	2nd Decision: Solution Technology
End State 1	NC OS
End State 2	NC OS CS (DirectControl) CS (VAS)
End State 3	NC OS
End State 4	NC OS
End State 5	NC*

*For End State 5, the solution described in this guide uses native UNIX operating system components; however, it is easy to extrapolate from this solution to an open source solution.

Key:

CS – commercial solution

NC – solution using native UNIX operating system components

OS – solution using native UNIX operating system plus open source components

Thus, developing a solution concept for any of the variations of the Windows security and directory services solution offered in this guide equates to deciding first which end state is appropriate for your situation, and then choosing the technology you will use to implement that end state (a commercial solution, or using components included in the UNIX operating system, or using UNIX OS in conjunction with open source components). The first decision is discussed in this chapter, whereas the second is addressed in Chapter 1, “Choosing the Right Technology and Planning Your Solution” of each volume in this guide.

Note One implication of this serial decision process is that scope and risk lists will be less complete than usual when the Vision/Scope Approved Milestone meeting takes place at the end of the Envisioning Phase because project scope will be heavily dependent upon the solution technology that is chosen. Both the vision/scope and risk assessment documents, however, are intended to be "living" documents that are subject to change as more information becomes known. The completed prototype, budget, and schedule may also result in scope modifications.

Having preconceived end states can save the work of developing a solution concept, but it does not eliminate the need to consider several inputs to decide among them. This requires identifying and documenting the items on the following list:

Business problem statement
Business goals
Vision statement
Assessment of current infrastructure
Design goals
High-level requirements
User requirements
Constraints
Assumptions

Note You have already done the work for the first four items in the preceding list. The sections that follow describe how to create the others.

Identify Your Design Goals

Design goals identify how technology will be used to achieve the business goals for the project. In most cases, it should be possible to link each design goal to one or more specific business goals. Design goals include descriptions of:

What the solution should enable users to do and what functionalities it will provide.
What the final design should look like at a high level—the technologies, their attributes, and how they interact.
Results that are aimed for during the process of reaching the final design, such as the impact on the production environment.

General design goals for an integrated security and directory services project may include:

A robust yet cost-effective authentication infrastructure.
Single sign-on, enabling users to log on to any computer or application in the organization by using a single set of credentials.
Sending only encrypted authentication information over the network.
Eliminating dependence on an existing data store (for example, NIS or LDAP), thereby eliminating any associated software licensing costs as well as platform costs.
Providing a single directory for administrators to manage authentication and authorization data for all accounts.
Using standards-based protocols and interfaces, thereby increasing flexibility in planning for future system enhancements or changes.

The following table lists common design goals as they apply to each of the end states. Although the list is not exhaustive, it is sufficient to clarify important differences and similarities among the five end states. You can use this table in conjunction with the preceding general list to speed the process of identifying design goals for your project.

Table 2.4. Design Goals for End States (ES) 1–5

Design Goal	Select This Goal?	ES 1	ES 2	ES 3	ES 4	ES 5
Consolidate Kerberos authentication for diverse systems into a single data store.
Consolidate LDAP authentication for diverse systems into a single data store.
Consolidate authentication account information (but not authorization account information) into a single data store.
Consolidate authentication and authorization account information into a single data store.
Retire existing authentication store and eliminate redundant stores.
Retire existing authorization store and eliminate redundant stores.
Enable users to access any Kerberized application in the organization using a single set of credentials and without needing to enter a password more than once (single sign-on).
Enable users to acquire Kerberos credentials for single sign-on during logon.
Adopt a consistent password policy across the enterprise, enabling users to change passwords by remembering just one set of rules.^3,4
Do not permit authentication information (user name and password) to be sent over the network in clear text.¹
Provide seamless logon on multiple platforms.
Use Kerberos credentials to access Kerberized applications in alternate Kerberos realms (cross-realm authentication).
Limit disruption to administration and user communities.
Minimize purchase of additional hardware.²
Minimize expansion of administration and help desk staff with company growth.
Minimize burden of changes to client computer configuration and applications.
Use existing UNIX Kerberos infrastructure.
Use existing Windows Kerberos infrastructure.
Use existing Windows LDAP infrastructure.
Minimize changes to the environment, applications, client computers, and staff.
Reduce need for retraining end users.
Reduce need to make changes to Kerberized applications.

¹For End States 2, 3, and 4, you must protect your LDAP connection with Kerberos or SSL/TLS.

²This is a possible goal for all end states, depending on the existing environment, but most likely for End State 5.

³This can be implemented for End States 1 and 2 using the instructions provided in this guide.

⁴This is possible in theory for End States 3 and 4, but cannot be implemented using the instructions provided in this guide. The current state of Active Directory does not provide for LDAP password change during logon and the UNIX passwd command must be configured for LDAP password change. The UNIX passwd tools are not entirely functional when configured for LDAP password change, and therefore no instructions are provided. See Chapter 8, "Evolving a Custom Solution" for discussion and references.

Identify Your High-Level Requirements

A requirement is a condition that the solution must meet. In defining high-level requirements, the team clarifies the vision statement by interpreting it in more concrete terms.

The high-level requirements should be brief and state only what the solution needs to address; they should not address how the requirements will be met. They should account for the business sponsor's, key stakeholders,' and end users' viewpoints and address the business goals identified earlier. The requirements should also include acceptance criteria.

Each team role drives a set of high-level requirements. However, because the focus of the Envisioning Phase is on defining and solving a business problem, the Product Management Role takes the lead in creating them. User Experience also plays an important role in creating requirements from the end users' viewpoints. The initial list of requirements is likely to be broad, but the team narrows it down to requirements considered essential; the subsequent application of constraints and results of trade-off negotiations will reduce it even further.

The following sample list reflects common high-level requirements for security and directory services projects. You can use these to begin your list, customize them as appropriate, and then add any others that are specific to your organization. You will also need to specify the criteria that you will use to determine whether the requirement has been met. The completed list should be documented in the vision/scope document. In this list, the sample requirements are placed beneath the business goal, shown in bold, that they most obviously support (some requirements support more than one business goal):

Increase user productivity. Eliminate the difficulties for users associated with multiple user accounts.

This is a barrier to user productivity that is removed when a single sign-on authentication system is in place.
Increase the availability of information and services to users and applications. Make Windows services available to user and service accounts that currently exist on the UNIX-based computers and vice versa.
Reduce ongoing costs such as administration , help desk , licensing , support , and hardware replacement:
- Remove the necessity to synchronize multiple directories and identity stores.
  
  When a single directory serves the whole organization, no synchronization or metadirectory system is required, resulting in less administration.
- Lower expenditure on hardware.
  
  Opportunities become available to reduce the number of servers in the system when a single directory or a single integrated authentication system is created. Clients of any operating system can then authenticate against Windows-based servers, and Linux-based and UNIX-based servers will no longer be required to provide security and directory services.
- Reduce administrative overhead associated with account maintenance.
Increase the security of the organization's systems:
- Provide for encryption of all sensitive data communications.
- Implement tighter controls for authentication and access control.
- Provide a strong authentication system that can be extended to provide secure channels for custom applications (GSS-API/SSPI).
- Provide a strong authentication system that can be extended to provide single sign-on to such various off-the-shelf software systems as SAP, Oracle, and Microsoft IIS, SharePoint®, and SQL Server™.
Reduce the risk of service unavailability:
- Increase the system's resilience to failures.
  
  If you do not make this a high-level requirement, you might create a system in which failures have a greater effect than before. For example, the failure of an Active Directory server might affect not only Windows users, but also Linux and UNIX users. Redundancy should be built in, allowing for alternate authentication and directory servers to be located and used during failure.
Comply with new regulatory requirements , business policies , or industry best practices:
- Meet regulatory requirements for items such as password policy and encrypted authentication (no clear text passwords).
- Provide high uptime for critical systems.
  
  This requirement also addresses the service unavailability business goal.

Identify User Requirements

Identifying user requirements begins with developing a detailed understanding of the ways that different users will use the new security and directory services solution. A systematic and efficient way to discover and list the uses is to create user profiles. The User Experience Role does this by identifying and describing all the different types of users who will use the solution, including system administrators who operate the solution and end users who benefit from it.

User Profiles

User profiles are descriptions of the eventual users of the solution in terms of geography, organizational and communication structures, user functions, resource availability, and other information that is relevant to their requirements for the solution.

For each user type, investigate how they will use the system, which features are relevant to them, and how the planned system improves on the existing systems.

The following are example user profiles for an integrated security and directory services solution. Each item describes a use that might apply. You can use them as starting points for the profiles you build, adding and eliminating items as necessary.

Windows-based workstation users:
- Have no interaction with the UNIX environment.
- Use authenticated applications hosted in the UNIX environment.
- Use authenticated applications hosted in the Windows environment.
- Use remote command-line logon to access UNIX clients or servers.
- Use a remote graphical user interface logon to access UNIX clients or servers.
- Use authentication to access services in the UNIX environment.
- Use authentication to access services in the Windows environment.
UNIX-based workstation users:
- Have no interaction with the Windows environment.
- Use an authenticated application that is hosted in the UNIX environment.
- Use an authenticated application that is hosted in the Windows environment.
- Log on to UNIX-based workstations.
- Use local command-line logon as the primary access method to local UNIX-based workstations.
- Use remote command-line logon to access UNIX clients or servers.
- Use a local graphical user interface logon as the primary way to access local UNIX-based workstations.
- Use a remote graphical user interface logon to access UNIX clients or servers.
- Use authentication to access services in the Windows environment.
- Use authentication to access services in the UNIX environment.
UNIX/Linux IT administrators:
- Maintain UNIX-based authorization and authentication identity stores.
- Maintain UNIX operating systems and hardware.
- Maintain UNIX-side configuration of application and service access.
Windows IT administrators:
- Maintain Windows-based authorization and authentication identity stores.
- Maintain Windows operating systems and hardware.
- Maintain Windows-side configuration for application and service access.
Help desk administrators:
- Add new users to authorization and authentication identity stores.
- Disable user accounts in authorization and authentication identity stores.
- Change user passwords.
- Assist end users with logon problems.
- Assist end users with password change problems.

The User Experience Role documents user profiles in the vision/scope document and examines them in conjunction with the usage statistics described in the following paragraph to formulate the user requirements for the solution. The user requirements should also be documented. User profiles with the associated user requirements will be used by testers as part of systematic acceptance testing.

Usage Statistics

You should document the size of the user community with respect to the platforms that will be employed in the solution. User numbers will help prioritize user requirements and enable you to quantify the benefits that result from implementing a heterogeneous security and directory services solution based on Microsoft Windows Server™ 2003. For example, quantifying the number of duplicate accounts provides an indication of the efficiency improvements that can be made by moving to a single, unified account database and authentication system. This information can also be helpful for decisions about scope (which user groups to include and exclude in a solution). Examples of the statistics to quantify and evaluate users include:

The number of UNIX and Linux users and applications.
The number of Windows users and applications.
The number of cross-platform users and applications.
The user population growth rates.
The user transfer rates between platforms (for example, the number of UNIX users becoming Windows users).

Identify Project Constraints

A constraint is a nonfunctional requirement that applies to various aspects of projects (such as budget, resources, or technology) and places a limit or dictates a limited range of possibilities. Constraints have both internal and external sources and represent an important input in developing a solution concept because they help narrow your choice of end state. A constraint may also present a conflict with other requirements. For example, spending limits can preclude a requirement that would entail extensive changes to existing infrastructure. However, you can sometimes deal with a constraint by restricting your project scope to reduce time, resources, or parts of the environment that are affected by the project.

The following is a sample list of common project constraints. Select those that are relevant and customize the items to apply specifically to your situation. Add additional constraints that are not on the list when documenting them in the vision/scope document.

Maintain system stability and existing functionality throughout the entire project, limiting disruption to administration and user communities.
Minimize changes to desktop configurations, applications, and environment.
Avoid making changes to Kerberized applications.
Minimize impact on existing authorization systems.
Minimize purchase of additional or replacement hardware.
Limit project costs to a specific budget.
Minimize expansion of staff needed to support a growing infrastructure.
Avoid creating UNIX user accounts for each Windows user who needs to access UNIX-based services.
Do not combine UNIX and Windows administrators into a single administration team.
Deliver solution within time deadline required by regulations.

Identify Assumptions

Assumptions are factors that are considered to be true, real, or certain but that are not yet validated. They are either prerequisites to project success or implications of actions that occur during the project that are key to success. The following table lists the technical assumptions that this guidance makes for each end state. Use this list as a checklist to ensure that the relevant assumptions are acceptable in your situation. After you have made the choice of end state, document all applicable assumptions in the vision/scope document. You may also want to include any nontechnical assumptions you are making that can affect the success of the project.

Table 2.5. Assumptions That Apply to Each End State (ES)

P/I1	Assumption	E S 1	E S 2	E S 3	E S 4	E S 5
P	All domain controllers are running in Windows Server 2003 domain mode.
P	Host name resolution (for example, DNS) is operating correctly.
I	Active Directory will replace the current authorization data store (for example, local files or NIS).
I	Active Directory will replace the current authentication data store.
P	UNIX-based workstations are running operating systems and OS versions that are compatible with the solution (generally very recent OS versions)².
P	UNIX key distribution centers (KDCs) are running operating systems and OS versions that are compatible with the solution.
P	The Active Directory infrastructure is capable of supporting the additional authentication load from the UNIX-based workstations (for End State 5, the additional load from the UNIX-based applications).
P	The Active Directory infrastructure is capable of supporting the additional authentication and authorization load from the UNIX-based workstations.
I	UNIX user authentication data will be migrated from the old data store to Active Directory or will be re-created in Active Directory.
I	UNIX user authentication and authorization data will be migrated from the old data store to Active Directory or will be re-created in Active Directory.
I	UNIX-based workstations and application servers will be modified to support Kerberos authentication against Active Directory.
I	UNIX-based workstations and application servers will be modified to support LDAP authorization against Active Directory.
I	UNIX-based workstations and application servers will be modified to support LDAP authentication against Active Directory.
I	SSL/TLS will be used to secure the LDAP connection to Active Directory.³
I	Kerberos cross-realm configurations will be pushed out to all UNIX-based workstations and application servers as needed. All Windows-based client computers will also need to be updated in order for them to participate in cross-realm activities.
P	UNIX-based workstations are time-synchronized with Active Directory servers and servers running Kerberized services.
I	Applications used by UNIX clients will not rely on the authorization data found in the Windows Kerberos ticket (PAC).
I	Active Directory will not store any authorization data for the UNIX users.
P	Schema changes will be made to the Active Directory database.⁴

¹P indicates a prerequisite for the solution; I indicates an implication of implementing it.

²If the open source solution is used, the version of the operating system is not as important. It may be possible to implement the open source solution on older operating system versions.

³The requirement for SSL depends upon the implementation selected. Some solutions support Kerberos to secure the LDAP connection.

⁴Not necessarily true for Centrify DirectControl (End State 2).

Select the Most Appropriate End State

At this point, you have completed the groundwork required for selecting the appropriate end state by identifying and considering all of the inputs to your decision. The process of compiling current state inventory information and determining requirements should have helped to shape your thinking and may have led to a preliminary conclusion about which solution best meets your needs. On the simplest level, the decision is a matter of identifying the end state that best matches your business, user, and technical requirements.

One challenge in determining the best match is that requirements are generally expressed in business terms and the end states are defined in terms of technology. Because the root problem that the organization is trying to solve is a business problem, any conflicts that arise need to be evaluated in terms of business results.

Participants can facilitate the decision-making process by staying focused on their areas of expertise. Decision makers who represent the business can contribute most effectively by ensuring that the business requirements are clear and by being prepared to assign priorities and make tradeoff decisions from the business perspective. Technical decision-makers need to act as interpreters by explaining the business implications of meeting or not meeting a technical requirement so that the two types of requirements can be compared. They also need to be able to clarify the business implications of technical alternatives when these alternatives are not apparent. Similarly, advocates for the end-user perspective must be prepared to articulate the business implications of user requirements.

Alternative Approaches

Different organizations will approach the end state decision in ways that vary in their formality, rigor, and required effort. Regardless of which approach or combination of approaches you use, the End State Selection Tool is a valuable supplement.

You may have a "best fit" end state in mind based on what you have learned about the end states and your organization's needs. Or you may read the sample business scenarios, each of which has an implied best fit end state, and identify the one that most closely matches your own situation. For these top-down approaches, you can increase confidence in your choice by checking your lists of goals, requirements, and constraints to ensure it meets them, and by reviewing the inventory section of your current state infrastructure assessment to ensure that the end state is feasible. This informal approach is faster than a more methodical approach but carries a greater risk that an important requirement or constraint will be overlooked.

Requirements frequently conflict with each other; a set of "must have" requirements might eliminate all possible solutions, or an otherwise-ideal solution might be ruled out by a single requirement. In those cases, it may be possible to adjust the scope of the project to eliminate the conflict. For example, you might determine that using Kerberos to provide a single authentication mechanism is the best solution to a problem, but then discover that Kerberos authentication is not supported by a small number of systems in your environment. Instead of choosing a less suitable authentication solution, you could instead change the project scope to omit coverage of that small set of systems.

If your unique requirements result in none of the five end states being viable even after you have adjusted the project scope to the maximum possible degree, then you have a further choice: you can explicitly drop requirements until the conflict is resolved and at least one solution becomes possible, or you can broaden the solution concept to consider bringing in additional mechanisms such as synchronization to solve the part of the problem that conflicts, or you can cancel the project. Do not regard cancellation as "failure"—it is the best possible choice when the alternative is to spend a great deal of money pursuing an unobtainable solution.
You can use the decision tree placed after this text to systematically narrow your choices from a technical perspective. Note that the scope of the decision tree is restricted to well-established solutions covered in this guidance, and there may be additional authentication and authorization solutions not reflected here. The decision flow assumes that, all else being equal, Kerberos is the most stable and robust authentication protocol. This is the reason that it was incorporated into Active Directory, which has a good track record as an implementation of Kerberos. Furthermore, it is assumed that one directory is less expensive to manage than two, and any reduction in the number of directories will save costs. Therefore, if Active Directory is already present, the best solution is to use it. This bias and assumption lead to End State 2 as the end state that most satisfactorily fulfills the more complete vision of "One user name, one password, one place for user information."

Although the questions concern technical choices, they are answered by applying the relevant business, user, and technical requirements and constraints. Working through this decision tree will require close collaboration between business and technical decision-makers, with technical people explaining the connections between the technical choices and their business implications.

Figure 2.1. Decision tree for end state decision

The End State Selection Tool

The End State Selection Tool (ESST) is a simple tool written in Excel that is intended to cut through some of the complexity in making a decision that must take several factors into account. It compares the end states on the basis of their capability to meet a number of common business and technical requirements, taken as a whole. The tool uses users’ inputs about their requirements and the importance of each requirement to show results for every end state and suggests the "best fit" end state. Many requirements are conflicting, all of the end states meet several of them, and no single end state meets all of them. Therefore, there will seldom be a single suitable solution—only one that is better than the others.

The tool also highlights the desired requirements that are not met by each end state, thus exposing the risks associated with choosing a particular end state.

The results of using the tool might show an unsatisfactory degree of differences between the end states, or it might highlight an unacceptable risk associated with the best fit end state. Users can then experiment with eliminating requirements or adjusting the importance (weight) they have assigned to a requirement to achieve more differentiation in the comparative scores, clarify the impact of a particular requirement, or eliminate a risk.

Caution The tool's list of major requirements that are collectively satisfied by the end states is not comprehensive; the tool uses only those requirements that help discriminate among the five end states. Thus the tool is best used to supplement other decision processes, not supplant them.

Defining the Project Scope

Defining project scope is a matter of establishing boundaries upon the "unbounded vision." The drivers for setting these limits include factors such as time, cost, legal constraints, technical constraints, resource availability, and market pressures. Project scope may be limited in terms of the features (defined as something that the user experiences) and functions (something that the underlying system does) that it delivers. It may also be limited in other ways, such as the systems and system components that the solution affects, the degree of integration with other systems, and the degree of planned support.

The scope of the project:

Defines which desired features and functions the project provides, solution trade-offs, and out-of-scope items. Out-of-scope items should explicitly identify any users or parts of the infrastructure, as well as solution-related services such as training, that the project will not include.
Distinguishes between the scope of the solution and the scope of the project in cases where the solution is implemented in stages or requires discrete projects that are run in parallel.

The Purpose of Scope

A clear definition of scope moves the team one step closer to a realistic plan for the project. It does not invalidate the vision, but sets the expectations for which part of it or aspects of it are planned to be accomplished in this project.

After the project is underway, a well-defined scope also helps prevent "scope creep"—the gradual addition of desirable features, functions, or affected parts of the infrastructure to the work of a project. Scope creep is a problem because it results in delays and cost overruns. The clear distinction between "in-scope" items and "out-of-scope" items helps the team adapt quickly to the new risks, constraints, and requirements that develop during the course of the project. Project scope may change after it is agreed upon at the end of the Envisioning Phase and documented in the vision/scope document, but it is important that any changes are made deliberately, with a clear understanding of their impact and with the explicit support of all stakeholders and the team. This is one reason for considering the vision/scope document a living document and putting it under change control.

The concept of scope can also be used to outline a plan for implementing a desired solution in phased projects. An initial project can restrict scope by limiting features and functions or by limiting the user groups, applications, or parts of the infrastructure affected by the project. Subsequent projects can be designed to accommodate budgetary and scheduling needs of an organization by including the elements that were excluded in the first project. In a phased solution, for instance, the first project might just cover single sign-on access to new human resource and productivity tools.

Scope in a phased solution can even be broadly defined in terms of implementing one end state in an initial project with the intention of implementing another end state in a later project. End States 1 and 3, and possibly even 5, may be considered as the first step or "phase" in moving to End State 2 or 4.

Reviews That May Help with Scope Decisions

Reviews that supplement the information gathering undertaken as part of the end state selection process can help in making scope decisions. The discoveries made as a result of a review could be used to limit scope. For instance, if a review determines that the authorization data for a specific group of users is especially complex, it might be a good plan to leave this group of users out of the first level-implementation of the solution. Following is a list of recommended reviews:

Review of Active Directory architecture in your environment to ensure it meets the requirements of this solution.
Review of domain name system (DNS) infrastructure to ensure it meets the requirements of this solution.
Review of time synchronization infrastructure to ensure it meets the requirements of this solution.
Enterprise-wide review of authorization roles.

Features and Functions In-Scope and Out-of-Scope

The following tables supply examples of features and functions that are in-scope or out-of-scope for each end state. A "Y" in an end state column indicates that the feature or function is in-scope and an "N" indicates that the feature or function is out-of-scope. You can use the information to specify both in-scope and out-of-scope items for your project. However, out-of-scope items need to be called out only when users and other stakeholders would normally associate them with the solution.

Table 2.6. In-Scope and Out-of-Scope Features by End State (ES)

Feature	E S 1	E S 2	E S 3	E S 4	E S 5
Users can easily change their passwords manually without help desk intervention.	Y	Y	N ¹	N ¹	Y
Users with expired passwords can change their passwords during logon.	Y ²	Y ²	N	N	N
Users can log on to computers in both Windows and UNIX environments with one user name and password.³	Y	Y	Y	Y	N
Users can access Kerberized services in both Windows and UNIX environments without being prompted for a user name or password.	Y	Y	N	N	Y
Users can access services on UNIX and Windows designed to use Active Directory domain credentials for authentication with the same user name and password used for UNIX logon.³	Y	Y	Y	Y	N
Current logon steps for users will remain unchanged.⁴	N	N	N	N	Y
Help desk staff can troubleshoot logon and password change issues with a minimum of training.	N ⁵	Y	N ⁵	Y	Y
No changes need to be made to help desk structure or staff training.	N	N	N	N	Y
Administrators can work with a single directory to provide user authentication and authorization for both Windows and UNIX users.	N	Y	N	Y	N
UNIX users receive a warning of impending password expiration.	Y ⁶	Y ⁷	N	N	N
Consolidation of authorization data into a single store.	N	Y	N	Y	N
UNIX users on UNIX-based workstations can use group data defined in Active Directory.	N	Y	N	Y	N
Capability to log on to UNIX-based workstation using cached credentials.	N	Y ⁸	N	N	N
Encrypted remote access to UNIX-based workstations/servers without implementation of additional tools.	N	N	N	N	N
Consolidation of authentication data into a single store.	Y	Y	Y	Y	N
Capability to log on to UNIX-based and Windows-based workstations with the same user name and password.	Y	Y	Y	Y	N

Note Y indicates that the function is in-scope for the end state; N indicates that the function is out-of-scope for the end state.

¹Available through commercial and open source solutions.

²Not available with native Red Hat 9 solution.

³Assumes no synchronization between multiple data stores.

⁴In most cases, changes visible to the user are minor.

⁵This might be possible if a preexisting user-provisioning tool can be modified without significant changes to the help-desk user interface.

⁶Available through open source solutions.

⁷Available through commercial and open source solutions.

⁸True only of Vintela and Centrify solutions.

Table 2.7. In-Scope and Out-of-Scope Functions by End State (ES)

Functions	E S 1	E S 2	E S 3	ES 4	E S 5
Enforcement of a single password policy throughout the enterprise.	Y	Y	Y	Y	N
Authentication accomplished securely through Kerberos.	Y	Y	N	N	Y
Kerberos features could be used to provide single sign-on.	Y	Y	N	N	Y
Availability of protected access credential (PAC) on UNIX-based computers for PAC-enabled applications.	Y	Y	N	N	N
Storage of authentication and authorization data in a user object in Active Directory.	N	Y	N	Y	N
SSL certificate management (certificates expire and need to be renewed).	N	Y ¹	Y	Y	N
Use of SSL/TLS to protect user information during logon.	N	Y ¹	Y	Y	N
Synchronization of passwords between Active Directory server and other data stores.	N	N	N	N	N
Synchronization of passwords between Active Directory server and UNIX key distribution center (KDC).	N	N	N	N	N

Note Y indicates that the function is in-scope for the end state; N indicates that the function is out-of-scope for the end state.

¹For open source solutions, Kerberos instead of SSL/TLS is used to secure user data.

Other Common Ways to Limit Scope

Scope can be limited across several dimensions in addition to features and functions. The following is a list of suggested items to consider when you are deciding how you will "bound" your vision by limiting the scope of your current project:

Account information:
- Specific users delineated by job function, role, business group, location, or division in your environment.
- Local UNIX accounts used for mission-critical services. (For example, for a mission-critical transaction processing system that runs as a particular UNIX account, you may want to consider keeping that account as a local account instead of migrating to Active Directory.)
- Other directory information. For example, deciding whether to migrate other information, such as automount maps and other NIS maps, stored in an LDAP directory to Active Directory as well.
Included systems and components:
- Specific computers delineated by function, role, business group, location, or division in your environment.
- Specific applications in your environment.
- Single sign-on to specific applications.
- Intranet authentication and authorization.
- Extranet authentication and authorization.
- Using existing PKI, deploying internal PKI, purchasing certificates from outside vendor.
Degree of integration:
- Integration with or impact upon enterprise monitoring or management systems.
Support:
- Support for specific version of operating systems.
Training:
- Developing help desk, administrator, end-user processes, and training.
Miscellaneous:
- Two-factor authentication.
- Delegating credentials (authenticate to a server, and then from there authenticate to another server or back-end service). Kerberos provides this; most other authentication does not.
- Kerberizing existing custom application to support single sign-on, possibly adding use of GSS-API/SSPI to provide encryption to the custom applications.

Job Aid: Vision/Scope Document

The job aids for this solution include a vision/scope document template in Microsoft Word. For the first four sections (“Business Problem/Opportunity,” “Vision Statement,” “Solution Concept,” and “Scope”), the template points to sections in this chapter that should be helpful in creating the document. The fourth section, “Solution Design Strategies,” refers to material covered in Chapter 1 of each of Volumes 2, 3, and 4 of this guide.

A completed template provides solid documentation to serve as the foundation for the project. Depending on your situation, you may find it appropriate to take a less detailed approach in this document. Nonetheless, it should be valuable to review the template to ensure that important considerations have not been overlooked.

Interim Milestone: Vision/Scope Document Drafted

The project team and customer now have a document that includes a broad view of the project, describing the problems and opportunities it addresses, the user community that benefits, how they benefit, and the approach to provide a solution. In addition, the scope of the project and solution are defined in terms of features included and those excluded. The team also has a clear and shared vision that defines the purpose of the project and provides direction.

Defining the Project Structure

The project structure document defines the approach your team will take to organize and manage the integrated security and directory services project. It serves as an essential reference for the project team members on how they will work together successfully. The document contains such information as:

Team member contact information.
Team organization and reporting structure.
Lists of team roles and responsibilities.
Communication and meeting logistics.
Procedures for elevating project issues.

Program Management takes the lead in defining the project structure. For more details, refer to the “Project Structure Template” job aid.

Assessing Project Risks

Risk (defined as the possibility of a loss) is inherent in any project. The loss could be anything from the diminished quality of a solution to increased cost, missed deadlines, or project failure.

Although risks cannot be eliminated, they can be managed. Continuous and proactive risk management, beginning with identification and prioritization (risk assessment) at the start of the project and including control and mitigation, is essential to delivering a successful solution.

For example, one risk associated with integrating the separate UNIX and Windows directory systems is that it might increase the impact of failures. After the integration is complete, a failure that previously only affected Windows users now affects UNIX users as well. The probability of this happening can be lessened by ensuring that the Active Directory environment is robust and that failover configuration for UNIX-based computers includes a wide and varied Active Directory environment. Identifying this risk early enables you to plan for its mitigation.

For a brief discussion of the ongoing risk management process, see the UNIX Migration Project Guide. For a more extensive discussion of the MSF Risk Management Discipline, see the MSF Web site at https://www.microsoft.com/technet/itsolutions/msf/default.mspx.

The Risk Assessment Job Aid

The team's risk assessment activities during the Envisioning Phase result in a risk assessment document that you can create using the “Risk Assessment Tool” job aid. This job aid contains extensive prepopulated lists of risks that apply to your project, one list for each end state. For each risk, the job aid defines and then specifies or explains how to calculate the following elements: condition, consequence, probability, impact, exposure, mitigation, and contingency. The document thus captures critical risk information: the risk description along with the impact that it will have on the project if it occurs, the chance of the risk occurring, and mitigation plans to reduce the chance of it occurring.

The job aid focuses on specific technical risks and is intended to jumpstart your initial identification of risks. Consider each risk and eliminate those that do not apply to your project. You will also need to identify and add risks that apply to your situation but which are more general in nature, such as those related to resource availability, time windows, and management support.

Overview of Technical Risks for an Integrated Security and Directory Services Project

The following is an overview of common types of risks you are likely to face with this project. Possible risks are listed in more detail in the job aid.

Service unavailability. If there is no authentication service available to a client, a user is prevented from logging on or accessing a resource. If there is no directory server available, a user might be unable to obtain information. Fortunately, both Kerberos and LDAP systems can be designed in such a way that clients can find other servers if their preferred one is down.
Time synchronization problems. This does not significantly affect directory access, but Kerberos is sensitive to differences in the system time of clients and servers. If a client is unsynchronized with the server (for Kerberos functionality, clocks on the client and server computers must be within x minutes of one another, where x is configured in Active Directory Group Policy), no user is allowed to log on to that computer. If two servers have time differences, trust relationships may break down, resulting in disrupted access to resources.
Replication interruptions. A distributed LDAP directory system, such as Active Directory, replicates changes from one server to another so that each user is presented with the most current information. If this fails, users are misled by data that was not replaced with up-to-date information.
Poor password management. If users choose insecure passwords, such as dictionary words without numbers or other characters, attackers can crack them with relatively little effort.

Estimating the Project Time Frame and Duration

At this time, the project team should be able to make a preliminary estimate of when the project will begin and how long it is expected to take. Considering that detailed plans have not been made, the project duration estimate is necessarily very rough and is based on experiences with similar or comparable projects. One important task is to identify and account in the estimate for schedule-related constraints, such as windows of opportunity for the work or potential conflicts with other planned events within the organization.

Closing the Envisioning Phase

The Envisioning Phase ends with the project’s first major milestone—Vision/Scope Approved. Achieving this milestone is customarily acknowledged at a formal meeting attended by the project team, the business sponsor, and the key stakeholders. The project team presents the vision/scope document and an initial risk assessment. Prior to the meeting, discussions and negotiations among these groups should have enabled them to reach consensus about the overall direction for the project, including which features the solution will and will not include, and a general timetable for delivery. The vision/scope document, as described throughout the preceding sections, should reflect this consensus.

By approving the vision/scope document, the meeting attendees indicate their willingness for the project team to proceed with the Planning Phase and signify their approval of the following:

The business needs that the solution is expected to meet.
The vision for the solution.
The design goals for the solution.
The risks that might be incurred by undertaking the project.

The signed-off vision/scope document is now subject to change control. Your next step is to move to the Planning Phase based on the end state solution you selected:

If you selected End State 1 or 2, then proceed to Volume 2: Solutions Using Kerberos Authentication (End States 1 and 2).
If you selected End State 3 or 4, then proceed to Volume 3: Solutions Using LDAP Authentication (End States 3 and 4). (Note: Volume 3 will be included in the next release of this guide.)
If you selected End State 5, then proceed to Volume 4: Solutions Using Kerberos Interoperability (End State 5). (Note: Volume 4 will be included in the next release of this guide.)

Chapter 2: Envisioning Your Windows Security and Directory Services Solution

On This Page

Introduction and Goals

Intended Audience

Knowledge Prerequisites

Major Envisioning Phase Tasks and Deliverables

Job Aids

Setting Up a Team

The Project Team Skills Template Job Aid

Special Considerations for Setting Up the Team for a Windows Security and Directory Services Project

Gaining Commitment and Support of Sponsors and Stakeholders

Identify Key Stakeholders

Facilitate Key Stakeholders' Involvement

Defining the Business Problem or Opportunity

Common Triggers Leading to Integrated Security and Directory Services Projects

Defining Business Goals

Creating the Vision Statement for Your Security and Directory Services Solution

The Vision Statement's Purpose

Sample Visions

Representative Business Scenarios

Scenario 1: Litware, Inc.

Scenario 2a: Walnut University

Scenario 2b: Northwind Traders

Scenario 3: Fabrikam

Scenario 4: Humongous Insurance

Scenario 5: Maple University

Assessing the Current Security and Directory Systems

Inventory Your Current Systems

Developing the Solution Concept

Identify Your Design Goals

Identify Your High-Level Requirements

Identify User Requirements

User Profiles

Usage Statistics

Identify Project Constraints

Identify Assumptions

Select the Most Appropriate End State

Alternative Approaches

The End State Selection Tool

Defining the Project Scope

The Purpose of Scope

Reviews That May Help with Scope Decisions

Features and Functions In-Scope and Out-of-Scope

Other Common Ways to Limit Scope

Job Aid: Vision/Scope Document

Interim Milestone: Vision/Scope Document Drafted

Defining the Project Structure

Assessing Project Risks

The Risk Assessment Job Aid

Overview of Technical Risks for an Integrated Security and Directory Services Project

Estimating the Project Time Frame and Duration

Closing the Envisioning Phase

Additional resources