Microsoft Identity and Access Management - Platform and Infrastructure

Introduction to the Platform and Infrastructure Paper

Executive Summary

This paper discusses several typical identity and access management problems that many organizations face. The paper also describes a technology platform that provides a foundation for identity and access management solutions, by using a fictitious organization called Contoso Pharmaceuticals. It examines the issues and opportunities that effective identity and access management technologies must address, as well as relevant threats and countermeasures.

The Business Challenge

Identity and access management has become more complex as digital identities take on an increasingly central role in specifying how users can participate in computer networks. Organizations need to identify users efficiently before granting them access to resources on local computers or the network. However, even businesses running small networks rarely store their identity information in one place. Multiple departments, locations in different countries and regions, business divisions, and software choices — along with mergers and acquisitions — result in database, directory service, and application-specific identity store proliferation.

Developing a consistent and effective identity and access management strategy requires a sound understanding of the approaches and technologies you can use to address proliferating digital identities. Organizations and IT departments need to implement both short term and strategic approaches to controlling and using identity.

An additional challenge to identity and access management is that security concerns must not impede business operations. There is always a tradeoff between the security level in an organization and functionality. This paper deals with these challenges by examining how to address security concerns without affecting the ability of users to carry out their jobs.

The Business Benefits

Meeting these challenges with an appropriate identity and access management platform will provide your organization with the following benefits:

• Improved and more cost efficient user access to resources.
• Centralized administration of digital identities.
• Reduced overhead by requiring fewer administrators to implement and maintain digital identities and carry out access management.
• Consistent security profile requirements to provide better safeguards for company resources.
• Increased opportunities for secure collaboration with business partners, customers, and employees working remotely.

Who Should Read This Paper

The intended audience for this paper includes architects, IT professionals and managers, technical decision makers, and consultants involved in identity and access management efforts.

Reader Prerequisites

This paper assumes the reader has a moderate knowledge of identity and access management concepts and technologies, as described in the "Fundamental Concepts" paper in this series.

Paper Overview

The business challenges discussed in this paper are the same ones many organizations face when dealing with identity and access management. Organizations need a technology platform that provides:

• Compliance with Lightweight Directory Access Protocol (LDAP) standards.
• Strong authentication services such as the Kerberos version 5 authentication protocol.
• Integral development support and a full range of developer application programming interfaces (API).
• Role-based access control (RBAC).
• Support for intranet and extranet scenarios.
• Support for authentication, authorization, and auditing in a distributed directory environment.

Enabling an organization to operate with partners, customers, and employees provides additional revenue possibilities and increases organizational flexibility. However, unauthorized attempts to access data, regulatory requirements, and data protection legislation — combined with the flood of viruses, worms and junk mail — make network security require a strong combination of planning, monitoring, analysis, and constant vigilance.

This paper consists of six chapters that cover the following topics:

Chapter 1: Introduction

The introduction provides an executive summary, the recommended audience for the paper, and an overview of each chapter in the paper.

Chapter 2: Approaches to Choosing a Platform

This chapter focuses on establishing a platform for identity and access management, and involves making some significant decisions that affect an organization's IT capabilities. These include whether to choose a single-vendor solution or multiple "best-of-breed" products that you can integrate to form a complete solution.

The remainder of the chapter discusses choices related to selecting a single platform or best-of-breed product, and the impact of either approach on the technology areas of directory services, access management, trust services, identity life-cycle management tools, and your application platform.

Chapter 3: Issues and Requirements

This chapter introduces the fictitious organization Contoso Pharmaceuticals, which is used to describe the many common business, technology, and security requirements organizations demand from an identity and access management platform. The chapter also discusses the security vulnerabilities in Contoso Pharmaceuticals that drive many of these requirements.

Chapter 4: Designing the Infrastructure

This chapter discusses the Contoso Pharmaceuticals technology architecture, based on their decision to use the Microsoft Identity and Access Management Platform. The platform architecture provides a core set of operating systems, directory and security services, and technologies that various solutions, applications, and business processes will rely on as the foundation for the company's identity and access management solution.

Chapter 5: Implementing the Infrastructure

This chapter provides guidance on how to prepare the Contoso Pharmaceuticals infrastructure. It introduces tools and templates that you can use to establish the baseline environment, which is an implementation prerequisite for the remaining papers in this series. The guidance in this chapter was created to help consultants and customers establish the Microsoft Identity and Access Management solution scenarios in a lab or proof-of-concept environment.

Chapter 6: Operating the Infrastructure

After the infrastructure has been implemented a number of ongoing operational activities need to take place at scheduled intervals to ensure that the platform will continue to work successfully. This chapter introduces operational references for the infrastructure services described in this paper.

Approaches to Choosing a Platform

Establishing a platform for identity and access management involves making some significant decisions that will make a noticeable impact on an organization's IT capabilities. The first decision an organization must make is whether to choose a single-vendor solution or multiple "best-of-breed" products that can integrate to form a complete solution.

The advantages of a single-vendor solution can include:

• Easier integration.
• Comprehensive, single-source support.
• Discount or package licensing.

The advantages of a best-of-breed solution can (but again, not always) include:

• The ability to choose individual products based on requirements.
• The ability to license and deploy only the products that are needed.

Many organizations enjoy the advantages of both models by selecting a single vendor (typically a platform vendor) for a significant portion of the infrastructure, and then augment this baseline of products with other products from vendors to fill specific functionality gaps. If an organization chooses this path, it is important for the platform vendor to demonstrate that the technology will interoperate with many other vendors in different technology areas.

The rest of this chapter discusses the choices that need to be made when selecting a single platform or best-of-breed product in the following technology areas:

• Directory services.
• Access management services.
• Trust mechanisms.
• Identity life-cycle management tools.
• The application platform.

Choosing Directory Services

Successful operation of the identity and access management platform requires a suitable location for storing application and identity information. While other options for storing user information exist, the industry has rapidly standardized on directory technology to achieve this capability. Most commercially available directories today support a common set of capabilities that include:

• Support for either the Lightweight Directory Access Protocol (LDAP) or Directory Access Protocol (DAP) or both of these protocols, based on the International Telecommunication Union (ITU) X.500 standard.
• Standardized attribute types based on the X.520 standard.
• Standardized object classes based on the X.521 standard.

Because directory object storage and directory access mechanisms are fairly consistent across most directories, what differentiates directory service products are often capabilities such as:

• Search performance.
• Storage and multiprocessor efficiency for scale up.
• Data replication performance for scale out.
• Robust failover and recovery capabilities.
• Integration with different types of security services.
• Integration with different types of applications and system management services.
• Publication technologies.
• Precise access control at the object and attribute level.
• Licensing.
• Support.

Directory requirements may also depend on the role that a directory is asked to perform. Capabilities that are required in one role may differ from those required in another role. For example, many organizations will need to deploy directory services to perform the following roles:

• Intranet (enterprise) directory
• Extranet (perimeter) directory
• Application directory

The following sections in this chapter describe considerations for directories in these roles.

Intranet Directory

Most organizations currently have one or more directory service on their intranet. Intranet directory services must provide the following capabilities:

• A central repository for user accounts.
• Centralized, secure storage of credentials used for authentication.
• Centralized storage of attribute information used for authorization.
• Information to locate network resources.
• Information to locate people and groups.

In addition to these capabilities, it is highly valuable if the intranet directory service also integrates tightly with security services that are often found on the intranet.

Extranet Directory

Extranet directories have the same fundamental requirements as intranet directories in most organizations. The additional requirements for choosing a directory that must support applications used by partners, customers, and employees include:

• The ability to scale to millions of users.
• Cost-effective licensing.
• Support for Internet-compatible authentication mechanisms.
• The ability to present multiple distinct communities or organizations (such as partners and customers) within a single directory.

Application Directory

Application directories are deployed in organizations where directory service technologies meet the requirements of the scenario, but where the data stored in the directory is not useful to a large set of users or applications. Application directories usually have a subset of directories that are used at the organizational level, and additional requirements for manageability and operability. Application directories should offer the following:

• Storage for application-specific information.
• Easy set up and deployment.
• A simple administration model.
• Reasonable scale up and failover capabilities.
• Low-cost licensing.

Choosing Access Management Services

Access management services provide the organization's applications with the capability to authenticate users securely and carry out robust authorization. When considering your access management choices, select technologies that integrate well with the directory services product.

Selecting Authentication Methods

The requirements and considerations for authentication mechanisms can vary greatly based on the scenario. Typical requirements that differentiate how authentication is performed include:

• What requirements can the organization impose on the user?
• What infrastructure can be established and maintained to support the user?
• Should the user have a single sign on (SSO) experience?
• What kind of applications does the user need to access?

Although there can be variations within the scenarios, intranet and extranet authentication offers one way to categorize users and applicable authentication mechanisms.

Intranet Authentication

Intranet authentication has the following characteristics that will influence the authentication mechanisms you choose:

• High levels of control (through policies) that govern how computer users (employees) can use the network.
• Complete control over the network environment and availability of services.
• Control over the configuration of user workstations.
• Multiple application types, such as client/server, Web-based or Microsoft® Windows® Forms-based.

Because of these characteristics, it is possible to choose authentication mechanisms for the intranet that offer high levels of security while providing an SSO experience. However, these also require a combination of sophisticated infrastructure, configuration, and certain user behaviors. Examples of authentication technologies that meet this description include:

• The Kerberos version 5 authentication protocol.
• X.509 digital certificates on smartcards.
• Hardware tokens such as RSA SecurID.

For more information about these technologies, see the "Intranet Access Management" paper in this series.

Extranet Authentication

With the single exception of employees (and in a few cases, partners) that access extranet resources by using VPN technologies over the Internet, Web-based extranet access has a completely different set of characteristics:

• Low levels of control (through policies) govern how computer users (customers, partners) can use the network.
• There is little or no control over the network environment and availability of services beyond your perimeter network.
• There is no control over the configuration of user workstations.
• Access requires mostly Web-based applications.

Because of these characteristics, authentication mechanisms should be chosen for the extranet that offer adequate levels of security without placing unrealistic requirements on users. Examples of authentication technologies that meet this description include:

• Forms-based authentication.
• X.509 digital certificates for employees.
• Microsoft Passport Services for customers and partners.

Even with the very explicit restrictions that the extranet environment dictates, extranet users expect the same SSO experience across multiple applications that intranet users enjoy. Furthermore, many organizations have requirements to provide an SSO user experience across different applications running on different platforms. A strong independent software vendor (ISV) market has matured to address this problem of providing Web SSO across heterogeneous platforms, and many suitable solutions are available from a large number of vendors.

For more information about these technologies, see the "Extranet Access Management" paper in this series.

Implementing Authorization

Most platforms support some form of access control list (ACL) mechanism for granting permissions on static objects such as files and printers. Access to these objects is granted by being a user or a member of a group that is explicitly allowed access to the object.

In addition, most organizations are contemplating whether to use some form of role-based access control (RBAC). RBAC tends to be more intuitive, and as a result it is easier to manage and more flexible.

RBAC mechanisms should be capable of implementing a business rule to define authorization policy. For example, a RBAC mechanism should be able to enforce a business rule of the following type:

Only bank tellers can process savings account deposits between the hours of 9am and 4pm.

An organization should choose a platform that provides efficient ACL – based access control for static objects, as well as a robust, flexible RBAC mechanism that is intuitive to manage, and capable of expressing complex business rules as access policies.

Implementing Trust Mechanisms

Of all the technologies that have been discussed so far, the implementation of trust is likely the biggest technology area that differentiates various platforms. At the highest level, trust is the reliance that one computer places on another computer or group of computers to assert the identity of a user. The differentiation between trust mechanisms is mostly in how computers and users become part of a circle of trust.

For example, host-based systems are, by their very nature, both autonomous and encompassing. Few organizations have more than one mainframe, and if they do, those computers are unlikely to trust each other except through the explicit sharing of passwords.UNIX and Linux operating systems are typically either stand-alone systems (not a member of any "circle of trust") or part of a Network Information Service (NIS) or NIS+ grouping. You can also configure UNIX and Linux workstations to use LDAP for authentication and authorization. When this happens, all such workstations configured to use the same directory instance become part of this circle of trust.

In order to become a truly valuable tool for enabling effective identity and access management, the platform should provide trust mechanisms that scale across the entire organization, and even between organizations. Establishing circles of trust should make up a fundamental component that you can organize into hierarchical groupings to make it easy to administer the trust relationship at the appropriate level.

Choosing Identity Life-Cycle Management Tools

Identity life-cycle management tools provide the means to manage the following basic tasks related to identities:

• User management.
• Credential management.
• Entitlement management.

All platforms come with tools and interfaces that allow the administrator to perform these basic tasks, but this is another area where a strong ISV market has developed in order to provide user-friendly, cross-platform management capabilities. In many cases, these tools are Web-based, which is highly appropriate for extranet identity management scenarios, such as partner-delegated administration (in which the partner organization takes responsibility for administering their users).

You should consider using best-of-breed identity management tools for your organization's scenario if the platform-provided tools that have been designed for the intranet scenario in this paper series do not meet your organization's requirements.

Implementing Identity Integration

Identity integration tools are often sophisticated, complex products in their own right. These tools can aggregate and synchronize the information that describes digital identities (attributes) between the many existing identity stores in established organizations. Some of these products are also described as metadirectory products.

Features to consider when evaluating an identity integration product include:

• How many different types of identity stores does it connect to?
• Does each "connector" require a footprint (a user account or an additional table) on the connected system?
• How robust are the rules that govern attribute flow between identity stores?
• What is the development environment for extending the rules that come with the product?
• Can the product synchronize or propagate user passwords from one store to another?
• Does the product support both state-based (based on the current state of an object) and event-based processing (based on changes within the connected identity store)?
• Does the product integrate well with the platform directory services selected by the organization?

Provisioning and Deprovisioning

The ability to provision and deprovision user accounts in multiple identity stores may be features that are part of an identity integration product or they may be implemented in a stand-alone product. The features to consider when evaluating provisioning products are similar to those for an identity integration product. The ability to support different levels of workflow is also an important distinction for provisioning.

Choosing an Application Platform

Application development environments have a history of integrating well with their native platform, but not so well with other platforms. For this reason, your organization's choice of application platform will most likely depend on your choice of infrastructure platform for the application servers in your environment.

Many organizations choose to develop or maintain applications on two or more platforms. For such organizations it is critical to understand how heterogeneous applications can interoperate by using common protocols and by taking advantage of common infrastructure services. An application platform that does not integrate or interoperate well with others should not be chosen. Application platform vendors should have a demonstrated commitment to interoperability and support the relevant standards efforts that make interoperability possible.

The Microsoft Identity and Access Management Platform

The following sections in this chapter describe the core products and technologies that make up the Microsoft Identity and Access Management Platform, and the benefits it brings to an organization.

Directory Services

Microsoft Windows Server™ 2003 includes support for the Microsoft Active Directory® directory service, and for an application directory service called Active Directory Application Mode (ADAM). The following figure shows the central role Active Directory plays, and how it integrates with other Microsoft and ISV technologies.

Figure 2.1. Active Directory integration with other network components

Active Directory

Active Directory has the following features that make it suitable for both the intranet and extranet directory service role:

• A central location for network administration and delegation of administrative authority. Administrators have access to objects representing all network users, devices, and resources, as well as the ability to group objects for ease of management, and apply security and Group Policy.
• Information security and SSO for user access to network resources. Tight integration with security eliminates costly tracking of accounts for authentication and authorization between systems. A single user name and password combination can identify each network user, and this identity follows the user throughout the network.
• Scalability. Active Directory includes one or more domains, each with one or more domain controllers, which enables you to scale the directory to meet any network requirements.
• Flexible and global searching. Users and administrators can use desktop tools to search Active Directory. By default, searches are directed to the global catalog, which provides forest-wide search capabilities.
• Storage for application data. Active Directory provides a central location to store data that is shared between applications, and for applications that need to distribute their data across entire Windows-based networks.
• Systematic synchronization of directory updates. Updates are distributed throughout the network through secure and cost-efficient replication between domain controllers.
• Remote administration. You can connect to any domain controller remotely from any Windows-based computer that has administrative tools installed. Alternatively, you can use the Remote Desktop feature to log on to a domain controller from a remote computer.
• Single, modifiable, and extensible schema. The schema is a set of objects and rules that provide the structure requirements for Active Directory objects. You can modify the schema to implement new types of objects or object properties.
• Integration of object names with Domain Name System (DNS), the Internet-standard computer location system. Active Directory uses DNS to implement an IP – based naming system so that Active Directory services and domain controllers are locatable over standard IP both on intranets and the Internet.
• LDAP support. Lightweight Directory Access Protocol (LDAP) is the industry standard directory access protocol, making Active Directory widely accessible to management and query applications. Active Directory supports LDAPv3 and LDAPv2.

Active Directory Application Mode

Active Directory Application Mode (ADAM) has the following features that make it suitable for the application directory service role:

• Ease of deployment. Developers, end users, and ISVs can easily deploy ADAM as a lightweight directory service on most Windows Server 2003 platforms and on clients running Microsoft Windows® XP Professional. You can easily install, reinstall, or remove the ADAM application directory, making it the ideal directory service to deploy with an application.
• Reduced infrastructure costs. By using a single directory technology for both your network operating system (NOS) and application directory needs, you can reduce overall infrastructure costs. Additional investment is not required for training, administration, or management of your application directory.
• Standardized application programming interfaces (APIs). LDAP, Active Directory Service Interfaces (ADSI), and Directory Services Markup Language (DSML) are implemented in both ADAM and Active Directory. These capabilities enable you to build applications on ADAM, and then migrate them to Active Directory as needed, with minimal change.
• Increased security. Because ADAM is integrated with the Windows security model, any application that uses ADAM can authenticate access against Active Directory across the enterprise.
• Increased flexibility. An application owner can easily deploy directory-enabled applications without affecting the directory schema for the entire organization, while continuing to use the identity information and credentials that are stored in the organization's NOS directory.
• Reliability and scalability. Applications that use ADAM have the same reliability, scalability, and performance that they have with deployments of Active Directory in the NOS environment.

For more information about ADAM, download the white paper "Introduction to Active Directory Application Mode"

Security Services

The following security services are tightly integrated with Windows application servers, Windows client operating systems, and computers running Windows 2000 Server and Windows Server 2003 acting as domain controllers:

• The Kerberos version 5 protocol supports authentication, including APIs for use by client/server applications, as well as a Kerberos Key Distribution Center (KDC) that is integrated with Active Directory.
• The Microsoft Security Support Provider Interface (SSPI) is a well-defined common API for obtaining integrated security services for authentication, message integrity, message privacy, and security quality of service for any distributed application protocol.
• The X.509 – based Public Key Certificate Server built into Windows Server lets organizations issue public-key certificates for authentication to their users, without depending on commercial certification authority (CA) services.
• Secure Socket Layer (SSL) and Transport Layer Security (TLS) use client/server X.509 digital certificates to support strong, mutual authentication and secure communications.
• Smart cards provide tamper-resistant storage for protecting private keys, account numbers, passwords, and other forms of personal information and are a key component of the public-key infrastructure (PKI) that Microsoft integrates into the Windows® platform.
• Microsoft Passport provides an SSO user experience for customer authentication to an organization's extranet applications.
• Access Control Lists (ACLs) on static resources. The Microsoft Windows Server™ object-based security model allows administrators to grant access rights to a user or group rights that govern who can access a specific object.
• Authorization Manager supports RBAC in custom applications.

Note Authorization Manager is included with Windows Server 2003, but you must download and install it for use on Windows 2000 Server from the Windows 2000 Authorization Manager Runtime page

• Security auditing allows changes to directory objects and access events to be reported through the Security Event log.

Identity Integration Services

Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1) includes the following features that you can use to streamline identity and access management across your organization:

• Identity aggregation, synchronization, and provisioning across heterogeneous identity stores.
• Management agents for connection to multiple identity stores, including directory services, databases, and e-mail systems.
• Password management and synchronization, including a self-service Web application for password resets.
• No connector footprint on the connected identity stores.
• Event or state-based synchronization processing.
• Easy extensibility through the Microsoft Visual Studio® .NET programming environment.

A reduced feature set version called the Identity Integration Feature Pack for Active Directory offers:

• Management agents for Active Directory, ADAM, and Global Address List (GAL) Synchronization.

Client Operating System

Organizations that standardize on Windows XP Professional will realize these benefits:

• Support for Windows-Integrated Authentication with platform services to achieve SSO for file, print and Web application services.
• Domain-level Group Policy to enforce increased security.
• Additional SSO capabilities between different organizations that use passwords, X.509 digital certificates, and Microsoft Passport accounts through Windows Credential Manager.

Development Platform

Microsoft Visual Studio.NET and the .NET Framework provide the capability to:

• Develop identity-aware applications that use the power of the Microsoft Identity and Access Management Platform.
• Reduce application development costs.

Platform Benefits

Implementing the Microsoft Identity and Access Management Platform with the solutions describe in the following chapters of this paper will allow Contoso to achieve the following benefits:

• A single, secure, trusted source of identity information. Administrators have a reliable, up-to-date view of all applications and systems, as well as all users and their entitlements.
• Seamless application integration. The Microsoft development platform provides secure, standards-based authentication, authorization, and data protection mechanisms.
• Improved security and provisioning. Identities across multiple systems in the organization for employees, customers, or partners are removed as soon as their relationships with the organization end.
• Simplified administration and reduced administrative costs. Administrators can add, change, and remove digital identities and entitlements quickly and easily in a centralized place.
• Fine-grained access control. Administrators can control more precisely what resources users can access, what they can do with those resources, and how security policies are applied to users and resources at a detailed level.
• Using fewer passwords and better password management. Users can access applications more conveniently and Helpdesk personnel will spend less time managing password problems.
• Interoperability among identity systems and operating systems. The solution provides interoperability through standards-based access and authentication mechanisms that reduce the time it takes to integrate and administer multiple systems.
• Secure, reliable auditing. Auditing provides the necessary trail to explain who, what, when, where, and how resources are accessed across the network.
• Local Credential Management. Strong protection of locally stored password credentials by using Windows Credential Manager.

While the platform provides core services that are required for identity and access management, several solutions need to be implemented with the platform to achieve all of these benefits. Chapter 4, "Designing the Infrastructure" in this paper discusses these solutions.

Issues and Requirements

To implement an effective identity and access management infrastructure in your organization, you need to choose a technology platform by critically analyzing your organization's requirements against the technology capabilities. This functional analysis ensures that the solution meets your business goals while keeping the platform secure and manageable.

This paper covers these issues by using the fictitious company Contoso Pharmaceuticals. The Contoso Pharmaceuticals scenario is intended to provide insight into the problems that a typical organization might face when addressing common identity and access management issues.

Introducing Contoso Pharmaceuticals

Contoso Pharmaceuticals is a fictional company based in the United States with its headquarters and primary manufacturing facility located in Orlando, Florida. Contoso currently has 5,300 employees and yearly revenues of $3.8 billion.

The company's success rests largely on a corporate culture that focuses on pioneering research and development. Contoso Pharmaceuticals is renowned for its commitment to customer service and its low-cost production facilities. Contoso has experienced strong growth the past two years, fueled partly by acquiring a smaller pharmaceutical supplies company, Fabrikam Ltd. (another fictitious company) in the United Kingdom. Several more such acquisitions are planned to strengthen the parent company's market position.

Information Technology Department

The Contoso IT department consists of several hundred technical and managerial personnel. The 22 full-time system administrators manage more than 500 servers of all types, including computers running Microsoft® Windows®-based server operating systems, Sun ONE Directory Server 5.1 (formerly iPlanet Directory Server), and mainframes running third-party and custom applications. The administrators also manage the company's Microsoft Exchange Server infrastructure and an internal Contoso portal site for employees. The remaining servers are dedicated to file and print services and database functions.

Administering the company's Microsoft Windows Server™ 2003 domain controllers and the Microsoft Active Directory® directory service is an important part of daily operations. One of the many tasks that domain administrators perform is provisioning accounts into Active Directory.

Contoso has a large and well-trained Helpdesk operation that supports a twenty-four hour, seven days-a-week operation. Helpdesk operators offer support for applications such as e-mail, word processing, and business applications, as well as password reset assistance for employees locked out of company systems. Contoso also has several infrastructure and security architects who review enterprise-wide and departmental IT requirements to create proposals for IT strategies, investments, and standards.

Operating Systems

A wide range of system platforms and applications make up the Contoso Pharmaceuticals IT infrastructure. Although Windows-based servers and clients make up the majority of its systems, Contoso also has business-critical systems, including servers running Sun ONE Directory Server 5.1, and workstations running Sun Solaris 9. The systems running Sun Solaris 9 are currently managed with Network Information System (NIS).

The Contoso intranet Active Directory design features a single forest with an empty root domain and a single child domain. All of the original Contoso user, service, and machine accounts were migrated to Active Directory from Microsoft Windows NT® 4.0 domains. The company also operates the external Domain Name System (DNS) servers that service the Contoso.com Internet domain. These DNS servers are separate from the internal ones that service the intranet Active Directory forest.

Additional Identity Stores

In its recent acquisition of Fabrikam Ltd., Contoso also acquired multiple infrastructure products, such as Lotus Notes Release 6.5.4 for messaging, and a server running Sun ONE Directory Server 5.1 that provides the authentication and directory services for a custom-developed Web application. These systems are still required to support the business activities of the former Fabrikam employees in the short term. The long term plan calls for migrating the Fabrikam infrastructure into the existing Contoso environment.

Business and Technology Issues

Contoso operates in a highly competitive environment in which time-to-market is a key industry driver. Clinical trials are large investments, and a single day's delay in delivering results or submitting a product for approval by the U.S. Food and Drug Administration (FDA) can cost the company nearly a million dollars. Therefore, interaction with users and partners is a key part of the company's operations. Regulation is another primary consideration, as regulatory fines and penalties can range from millions to tens of millions of dollars.

A major business challenge Contoso faces is to expand both the quality and scope of the organization's interaction with customers, partners, and employees who work remotely. New ways of interacting with customers to get their feedback, and to communicate the advantages of the organization's products, have resulted in many improvements. These improvements involve the product development process to create products better suited to customers' needs, which increases the company's market share. However, historically administration involvement has made this process costly and difficult to maintain.

Contoso understands that improving the technology solutions they use to collaborate with partners will lead to greater efficiencies in the product development process. At the same time, employees are increasingly mobile and need easier access to data necessary for their jobs, both through the corporate network and over the Internet.

Contoso appreciates that an identity and access management platform must improve the infrastructure's manageability and security, specifically in the areas of digital identity management. As a long term objective, the company wants to consolidate duplicate identity stores for separate applications into a centralized identity store that will provide greater administrative efficiency, lower total cost of ownership (TCO), and result in fewer administrative errors and greater security.

However, the Contoso architects and administrators are aware that there are short- to medium-term issues they must address before they can meet these goals, particularly on the security side. The "Threats and Countermeasures" section that appears later in this paper summarizes these security concerns and the countermeasures that can reduce or neutralize the threats.

Contoso Pharmaceuticals has identified the following key requirements in its two-year plan to improve identity and access management:

• Provide the best possible technology infrastructure for the rapid development, evaluation, and marketing of the company's products.
• Increase the efficiency and security level of the company's IT infrastructure, in particular managing digital identities, to pave the way for additional growth without having to accumulate additional administrative overhead and IT complexity.
• Consolidate security and privacy mechanisms and related technologies to meet government regulatory requirements, such as the FDA 21 Code of Federal Regulations (CFR) Part 11 (Part 11), and the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

To fulfill these requirements, Contoso has undertaken a comprehensive review of its most critical applications and processes. The next section identifies each of these key assets.

Key IT Assets

Contoso Pharmaceuticals has identified a number of IT assets that are of the highest importance to the company. The following assets contribute key capacities in addressing central business and technical issues:

• The extranet-accessible Sales and Contacts application and the sales employee user accounts.
• The extranet-accessible Partner Research application, and the extranet partner identity store.
• The extranet-accessible Customer Trial feedback application, and the extranet customer identity store.
• SAP application data and SAP user accounts.
• Microsoft Exchange e-mail infrastructure and accounts.
• Lotus Notes e-mail infrastructure and accounts.
• Applications that use the Sun ONE Directory Server 5.1 and UNIX user accounts.

The following diagram summarizes these key assets.

Figure 3.1. Contoso key IT assets

The Extranet Accessible Sales and Contacts Application

The sales force for Contoso spends a significant amount of time out of the office, visiting customers and building new business. The staff needs to track their sales and sales contacts, which is done through a Web application and database hosted in the Contoso perimeter network, also known as the demilitarized zone (DMZ). The information this application maintains is not critically sensitive. However, exposure of this data could cause problems for Contoso and its business partners, and would have a broader impact on the public perception of Contoso's trustworthiness.

Unavailability of the application would create the biggest issue because it would seriously hamper the effectiveness of the sales force.

Sales Employee User Accounts

Individual sales employee user accounts can access sensitive materials within a specific scope through the extranet. These accounts could also be misused to mount an attack on the broader Contoso organization and its IT resources.

The Extranet-Accessible Partner Research Application

Collaboration with research partners is essential to new product development, which Contoso depends on for its future growth. Much of that collaboration takes place through a single application hosted in the Contoso perimeter network. While the data in the application is backed up frequently, a successful attack on the application could cause serious problems for Contoso — disclosed research data could lead to a competitive disadvantage and possible regulatory action.

The Extranet Partner Account Store

Partner accounts have less access to Contoso IT resources than employee accounts. Partner accounts only allow access to the Partner Research application. However, compromise of a single account or the entire account store would likely lead to a compromise of at least part of the application. Again, this could lead to competitive disadvantage and possible regulatory action.

The Extranet-Accessible Customer Trial Application

The success of Contoso products depends on early customer feedback during the product development cycle. One of the ways Contoso takes advantage of technology is by providing a Web application whereby customers can easily provide feedback on products in the trial phase.

Contoso collects nearly 50 percent of its customer feedback through the Customer Trial feedback application. Disruption of this application would severely hamper the company's ability to complete trials and submit the results to the FDA, which could result in regulatory action if the FDA had reason to believe that application security was compromised.

The Extranet Customer Account Store

Customer accounts have less access to Contoso IT resources than employee accounts. Customer accounts only allow access to the Customer Trial feedback application. However, a compromise of a single account or the entire account store would likely lead to a compromise of at least part of the application. Another contributing factor would be the damage done to customer relations due to the perception that poor security practices at Contoso could leak customer privacy information. This could again result in regulatory action against the company.

SAP Application Data and SAP User Accounts

Contoso has implemented several SAP – based enterprise resource planning (ERP) applications. Some of these applications serve critical business functions and distribute confidential data to users. Compromise of this data could hamper the company's ability to compete in the marketplace, or result in significant fines from violating regulatory requirements.

Individual user accounts can be used to access sensitive materials within the scope of the SAP application. This could result in financial information leaks to investors that could harm Contoso.

Microsoft Exchange E-mail

Contoso uses Microsoft Exchange Server and Microsoft Outlook® for internal and external e-mail. Compromise of this data could lead to competitors gaining commercially sensitive information, and could also lead to regulatory action.

Lotus Notes E-mail

Fabrikam Ltd. used Lotus Notes for internal and external e-mail, and this environment was migrated during the merger with Contoso. Compromise of this data could lead to competitors gaining commercially sensitive information, and could also lead to regulatory action.

Sun ONE Directory Server 5.1 and UNIX User Accounts

Sun ONE Directory Server 5.1 provides directory services and authentication support for a custom Web application that Fabrikam uses. Compromise of this application and its data could lead to competitive disadvantage and possible regulatory action.

Individual UNIX user accounts can access sensitive materials within a specific scope at Contoso. These accounts could also be misused to mount an attack on the broader Contoso organization and its IT resources.

Completing the Analysis

After completing the analysis of their IT assets, Contoso identified the following issues with their current identity and access management platform:

• No clear strategy exists for reducing the cost and complexity of managing digital identities in the Contoso environment.
• Provisioning and deprovisioning users for customer applications is not standardized.
• Applications under development complicate the IT infrastructure when they add more identity stores.
• Authentication mechanisms are often custom-developed for each application, or are obsolete mechanisms that are standard on legacy systems. In either case, these mechanisms are expensive to implement, and are often not sufficiently secure against the many threats found in today's computing environment.
• Application authorization is a concern because application developers often implement custom mechanisms, which adds to development and maintenance time and cost.

Threats and Countermeasures

Many identity and access management security issues are actually security vulnerabilities. A vulnerability is a weakness in an information system or its components that could be exploited to produce a security breach. Vulnerabilities may result from problems with people, processes, or technology. Examples can include system security procedures, hardware design, or internal controls. Vulnerabilities can arise at any point in a network's defenses, and assessment is usually part of an overall security review.

Current Threats

Contoso Pharmaceuticals has just completed a major security review of its network. Part of the review included categorizing threats to the network. When creating the scope for its identity and access management project, Contoso decided to consider first and foremost the potential attacks from internal and external sources. Internal threats cover those that target the intranet, while external threats deal with those specific to the extranet.

Security Issues and Vulnerabilities

The Contoso environment has a number of vulnerabilities that relate to the business and technology issues covered earlier in this chapter. From a security perspective, the Contoso identity and access management solution must address the following concerns:

• Contoso must make more of its business information available through Internet-facing applications, but the security mechanisms implemented on the internal network are not strong or consistent enough to allow widespread access to this network.
• Security breaches at Contoso are difficult to investigate because there is only incomplete, disjointed, and scattered forensic evidence available through security audit logs.
• Existing application identity stores are not secure, and an attack against the user accounts they control is both possible and likely to occur.
• Existing application authentication mechanisms are not secure, and an attack against the authentication mechanisms is both possible and likely to occur.
• Existing application authorization mechanisms are poorly designed, and an attack against these mechanisms is both possible and likely to occur.

The first vulnerability highlights the constant challenge with identity and access management: systems that interface with customers, partners, or employees can only bring benefits if those people can access them. However, the very act of granting access increases the security risk.

Breaking these categories down further, the Contoso security review identified the following process and account vulnerabilities that are open to exploitation from internal and external sources:

• Account provisioning
• Account deprovisioning
• UNIX workstation accounts
• SAP authentication
• SAP application data protection
• Employee accounts
• Partner accounts
• Customer accounts

The employee, partner, and customer account vulnerabilities are similar, but the employee accounts vulnerability has more serious implications.

Account Provisioning

Inefficient or incomplete provisioning is not a direct security threat because nominally it only sets the stage for the inability to access application and network resources. However, inadequate account provisioning mechanisms can lead to other practices that are a direct threat to security, such as account sharing or allowing anonymous access to valuable assets.

Account sharing is the main risk associated with the account provisioning vulnerability. A recent report by the Helpdesk at Contoso states that this widespread practice is causing high volumes of support incidents due to failed logon attempts that cause accounts to become locked out, and multiple users simultaneously using the same identity to access resources.

An anonymous follow-up survey by the Contoso IT department found that the number one reason for users sharing accounts is that new employees are not provisioned quickly enough to access applications and network resources. This identity sharing was especially true among contract staff, who frequently complete several months of work before receiving the proper access they need to do their work.

Supervisors address this problem by giving contingent staff user names and passwords established for different users, who may or may not still be working at Contoso. This nonstandard practice makes it impossible for application or network administrators to audit who or what is using network resources or accessing application data. Some supervisors have even admitted to providing subordinates with their own account and password information, thus allowing the staff to access resources and data at elevated entitlement levels.

Account Deprovisioning

The account deprovisioning vulnerability is a far more serious concern. Former employees or external hackers could use old accounts left over in application identity stores or directories to gain unauthorized access to, or corrupt confidential and valuable data.

The main risk associated with the account deprovisioning vulnerability is stale accounts. A recent audit of an application-based identity store revealed that accounts were still active for employees that had left the company over three years ago. Stale accounts provide a backdoor which either a former user or an attacker could use to attack application data.

While the vulnerability from former owners of the account is obvious, it is also important to consider that the three-year-old account has not had a password change during this period. Stale accounts increase the opportunities for attackers to mount successful brute-force attacks on these static passwords, particularly if there is no policy in place to enforce password changes and account lockouts. These accounts can then be used to compromise or corrupt application data critical to Contoso business processes.

UNIX Workstation Accounts

Contoso has 40 workstations running Sun Solaris 9 that personnel in the Accounting department use to perform their daily functions. The Solaris workstations are administered through a single Network Information Service (NIS) domain.

Sun Microsystems developed NIS to centralize the administration of UNIX systems. The general NIS functionality is analogous to Windows NT 4.0 domains. NIS is very popular because it is easy for a knowledgeable UNIX administrator to set up and administer, it scales reasonably well, and it is supported by nearly all forms of UNIX. Unfortunately, NIS does not have good security characteristics.

One of the biggest security concerns with NIS is that it does not provide the ability to enforce password expiration or password complexity. In addition, all member servers in a NIS domain receive a copy of the password file that contains the encrypted password of every user in the domain.

Weak or old UNIX passwords are a threat to the security of the network, because they allow an attacker to quickly obtain a user account and password combination. After they have been compromised, user accounts can be used to escalate an attack on systems that might only be protected against anonymous attacks. Tools that apply brute-force and dictionary attacks against password files are widely available on the Internet. The UNIX user accounts at Contoso are not subject to password policy enforcement, and the NIS password policy file is widely distributed.

SAP Authentication

SAP is a well-known and widely deployed ERP application server and Contoso has implemented several such applications. Several of these applications serve critical business functions and distribute confidential data to users. Therefore, this data is critical to the company's business. Application availability interruptions, data corruption, or loss or exposure of data could cost Contoso millions of dollars.

Legacy authentication mechanisms and data access protocols that SAP provides do not have the capability to protect authentication secrets (passwords) when they are used to access the application. SAP user passwords can be intercepted by anyone with a network tap on a user's network segment.

SAP Application Data Protection

By default, client/server SAP application data sent over the network is unprotected. Any attacker who can view the network traffic on the SAP user's network segment can compromise SAP application data by stealing it or introducing incorrect data with potentially severe effects on the consistency of the data maintained in the SAP system.

The data exchanged between users and the SAP application server is critical to the company's business. Again, in this case application availability interruptions, data corruption, or loss or exposure of data could cost Contoso millions of dollars.

Employee Accounts

The employee accounts vulnerability involves two main risks — authenticating with plaintext passwords, and storing plaintext passwords on servers that are not secure. These vulnerabilities apply to both the internal and external networks.

When Contoso Sales department employees authenticate to the external Sales and Contacts application, they often do so by using their enterprise account credentials. This can expose those credentials to external threats through a compromise of the Web server located in the perimeter network, or to application administrators who cannot be trusted with such information.

Authenticating with Plaintext Passwords

An analysis of password use in the Contoso scenario revealed that employees of the Contoso sales organization used their enterprise account passwords to access a Web application hosted on servers in the perimeter network. The sales application uses Basic authentication over Secure Sockets Layer (SSL) to grant access to the application. While SSL does a good job of protecting the user's password on the network, the plaintext password is present on the Web application server. If the Web application server was compromised, the plaintext user passwords would be accessible.

Furthermore, there was no official company or departmental policy on whether the password for this application should or should not be the same as the user's enterprise account password; so many employees use the same password because remembering another password is difficult.

With valid account passwords, an attacker can gain unauthorized access to files and services that could not be attained otherwise. If the user's extranet account password is the same as their enterprise account password, then even more information could be obtained.

Storing Plaintext Passwords on Servers That Are Not Secure

To authenticate Sales and Contact application users, the Sales and Contact application compares the plaintext password acquired through Basic authentication to a password value in a Microsoft SQL Server database located in the perimeter network. With valid account passwords, an attacker can gain unauthorized access to files and services that could not be attained otherwise.

The computers running SQL Server are protected from direct access via the Internet by IP Security Protocol (IPSec) policy and physical network design. An external attack on a SQL Server would have to be a multi-tier attack through the externally-facing Web servers. However, because there is no policy or technology in place to prevent application administrators from accessing employee passwords, the internal attack is much easier to mount and simply requires an application administrator to skim the desired information as the application is running.

Partner Accounts

Contoso has an application for its research partners that uses password-based authentication. The application has a local identity store of user names and passwords that is kept in a database hosted on another computer, separate from the Web servers hosting the application. This design presents a number of identity manageability problems, but also presents security vulnerabilities as well.

Foremost among these is the security vulnerability of the accounts database. The accounts database stores the passwords in plaintext in a single location for all of the accounts that use the application. If unauthorized users gain access to the database, then they could compromise all of the accounts. In addition, during authentication, each Web server makes an unauthenticated request to the database to extract the user's password to compare it to the credential presented by the user. This process means that the plaintext password is visible in the physical perimeter network, which constitutes a significant risk.

Customer Accounts

Contoso also has an application for its customers that uses password-based authentication. The considerations and risks for this vulnerability are identical to those of the Partner accounts vulnerabilities.

Security Countermeasures

With a good understanding of the vulnerabilities in your own organization, you can select countermeasures to address them. Choosing appropriate security countermeasures depends on the vulnerabilities you need to address, and the criticality factor and likelihood of each being exploited.

Correctly choosing suitable countermeasures is particularly important, as each countermeasure can address multiple vulnerabilities. In addition, implementing a countermeasure may have beneficial effects in addressing other minor vulnerabilities that were not part of the initial threat assessment. These countermeasures drive the requirements for a platform selection and how it will be used.

The security requirements for the Contoso Pharmaceuticals action plan include using the following:

• Automatic provisioning and deprovisioning of user accounts.
• The Kerberos version 5 authentication protocol.
• Generic Security Services Application Programming Interface (GSS – API) and Kerberos protocol integration.
• Client certificate authentication with encryption.
• Password authentication to Active Directory.
• Microsoft Passport authentication to Active Directory.

At the end of each countermeasure section, a list details the vulnerabilities they address.

Contoso has also taken steps beyond implementing these identity and access management countermeasures, including:

• Implementing extensive defenses against virus threats, such as block lists and attachment filtering, as well as server and workstation virus scanners.
• Improved operational procedures and training policies designed to reduce the threat of accidental system misuse.
• Physical network and services design improvements to reduce mechanical threats, such as power outages, hardware failures, and network malfunctions.
• Well-defined contingency plans in case of natural disasters such as fires, flooding, and earthquakes.

Automatic Provisioning and Deprovisioning

Automating account provisioning and deprovisioning not only provides significant productivity gains, but can close several security loopholes. The most significant of these is when an employee leaves the company, and the organization fails to deactivate his or her account.

Account provisioning can be automated given an authoritative source of employee status, and a known set of application identity stores that administrators can centrally manage. For example, you can script a Human Resources (HR) application to generate an employee status table on a daily basis. You can then use an identity integration product to consolidate the HR application employee status with digital identity states in stores such as directories and applications.

Deployment Considerations

Identity integration products typically come with a number of connectors, or management agents, that provide a communication channel allowing for identity information synchronization. In addition, you need one or more authoritative sources for digital identities. Typically the sources can be a single (or collection of) HR systems, contractor databases and others, but the scenario for every organization will differ to some degree.

The Contoso Scenario

Contoso has identified its HR application as the authoritative source of information for identity status. The company has elected to deploy an identity integration and provisioning product to manage identity data in different stores, such as Active Directory, Lotus Notes Release 6.5.4, and Sun ONE Directory Server 5.1.

When the HR application indicates that a new employee should be provisioned, the system will add or activate the matching account in the other systems. When the HR application reports an employee's status as terminated, then the system will remove or deactivate the matching account in the other systems.

Security Issues Addressed

Implementing an identity integration product can address security issues with account provisioning and deprovisioning.

The "Identity Aggregation and Synchronization" paper in this series covers how to implement Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1), an identity integration product that provides the ability to automatically provision and deprovision employee accounts.

Using the Kerberos Version 5 Authentication Protocol

The Kerberos version 5 authentication protocol, introduced for Microsoft platforms in Microsoft Windows 2000, offers many desired security characteristics for a network authentication protocol. The Kerberos version 5 protocol is highly secure, utilizing the latest in cryptographic technologies and protocol design. The Kerberos protocol also provides better performance, as its design takes advantage of a central authentication facility, the Kerberos protocol Key Distribution Center (KDC), while offloading the work of the KDC through the use of relatively long-lived tickets.

Deployment Considerations

In the Contoso scenario, the KDC is on each domain controller running Windows Server 2003 Directory and Security Services. Kerberos interoperability provides the additional benefit of a single sign on (SSO) experience for Windows-based operating systems and possibly even UNIX clients.

The Contoso Scenario

The Contoso administrators plan to configure UNIX workstations to use the Kerberos version 5 protocol to authenticate to Active Directory domain controllers. They also plan to configure SAP R/3 to require Secure Network Communications (SNC) authentication in conjunction with the Kerberos version 5 protocol.

Security Issues Addressed

Implementing the Kerberos version 5 authentication protocol helps address security issues in the following areas:

• UNIX workstation accounts.
• SAP authentication.
• SAP application data protection.

The "Intranet Access Management" paper in this series covers how to implement the Kerberos version 5 protocol, including how to configure SNC authentication on SAP R/3 and how to configure UNIX workstations to authenticate by using Kerberos and Active Directory.

Using GSS-API and Kerberos Integration with SAP

SAP R/3 version 4.0 offers support for SNC. One mode of SNC allows for integration with GSS-API, and through GSS-API, you can use the Kerberos version 5 protocol.

One mode of SNC allows for integration with GSS-API, as described in IETF RFC-2078. GSS-API provides for both data confidentiality and integrity when used with a security protocol that also supports these capabilities. Kerberos version 5 is such a protocol. Configuring the SAP Application Server and the SAP graphical user interface (GUI) client to use both SAP SNC and the Kerberos version 5 protocol will fully protect the SAP application data from interception.

Deployment Considerations

SAP R/3 does not implement the KDC, but instead uses the KDC already installed in the network environment. In the Contoso scenario, the KDC is on each domain controller running Windows 2000 Server or Windows Server 2003 with Active Directory. You must configure SAP to use the Kerberos version 5 authentication protocol. However, after you have configured this, Kerberos interoperability has the additional benefit of providing the foundation for SSO on Windows-based and UNIX – based client operating systems.

The Contoso Scenario

In the Contoso scenario, the administrators configured SAP R/3 to use SNC authentication, and implemented GSS – API with the Kerberos version 5 protocol for Windows-based client workstations to provide end-to-end application data security.

Security Issues Addressed

Implementing GSS-API and the Kerberos version 5 protocol helps address security issues in the following areas:

• SAP authentication.
• SAP application data protection.

The "Intranet Access Management" paper in this series covers how to configure the SAP R/3 client to use SNC for integration with GSS-API and the Kerberos protocol.

Using Client Certificate Authentication with Encryption

Transport Layer Security (TLS) is the Internet Engineering Task Force (IETF) standard version of Secure Sockets Layer (SSL) developed by Netscape Communications, and is described in IETF RFC – 2246. TLS has the capability to perform public key-based client authentication by using a digital certificate. This is a very powerful capability because you have configured a public key infrastructure (PKI) trust, you can use an X.509 digital certificate, and the corresponding private key, in place of relatively weak passwords for authentication.

To enable this solution, you create a shadow account that represents the user in the external Active Directory hosted in the perimeter network computers. Because this account never uses its password for authentication, you can set a very strong password, such as one that employs a 24-character cryptographically-generated random value.

Deployment Considerations

Because the external account is only accessible by using a valid X.509 certificate, it is possible that employees may not have access to an important business application if they do not have access to the X.509 digital certificate and the corresponding private key. In such a case, the organization should consider whether temporary access to the extranet application could be granted by resetting the password on the account — and telling the employee what the password is — or by creating a mechanism to issue new certificates through the extranet, or by making a virtual private network (VPN) connection to the internal network.

Because client certificates eliminate the need for passwords, they need to be kept secure through workstation security policies.

The Contoso Scenario

The Contoso architects configured the Sales and Contact application to require TLS and client certificate authentication. This involved setting up a certification authority (CA) and assigning certificates to sales department staff.

Security Issues Addressed

Implementing client certificate authentication with encryption helps address security issues in the following areas:

• Authenticating with plaintext passwords.
• Storing plaintext passwords on servers that are not secure.

The "Extranet Access Management" paper in this series covers how to configure client certificate authentication with encryption.

Password Authentication to Active Directory

Active Directory is designed to store highly-sensitive information, such as account passwords, in a secure manner. Passwords, in most cases, are not actually stored in such a way that the original password can be determined. Active Directory uses cryptographic hashes (one-way encryption) of the password, which is sufficient to provide authentication by using the protocols that Windows Server 2003 provides. The cryptographic hashes themselves are protected with encryption keys that are only accessible to the operating system, thus further preventing the compromise of highly-sensitive passwords.

Active Directory also provides the mechanisms to perform password-based authentication in a secure manner. In other words, without having to send plaintext password information over the network between the application server and the identity store. An example of a secure authentication mechanism would be secure bind Lightweight Directory Access Protocol over SSL or TLS, (LDAPS).

Deployment Considerations

Using a different account store for authentication usually requires a code change in the application. Applications that use a database table for authentication need to be updated to use Active Directory.

The Contoso Scenario

Contoso updated its Partner Research application for partners to use Active Directory as the identity store for partner accounts, and the mechanism for access management.

Security Issues Addressed

Implementing password authentication to Active Directory helps address security issues in the following areas:

• Authenticating with plaintext passwords.
• Storing plaintext passwords on servers that are not secure.

The "Developing Identity-Aware ASP.NET Applications" paper in this series describes how applications can perform authentication and authorization by using Active Directory.

Microsoft Passport Authentication to Active Directory

A separate usability study indicated to Contoso architects that customers are challenged by trying to manage user names and passwords for different Web sites. Research indicated that an identity broker such as Microsoft Passport could provide authentication for customers visiting the Contoso Web site while not requiring the customer to maintain an additional identity.

This approach also satisfied the security requirements of the Contoso Customer Trial feedback application because they could eliminate passwords for customer accounts completely. Validating a Passport credential and then mapping the Passport Unique ID (PUID) to an account in the external Active Directory thus authenticates users to the Contoso site.

Deployment Considerations

Using a service such as Microsoft Passport for authentication usually requires a code change in the application. In addition, to support specific authorization, you must provision (through automated means) large numbers of Passport mapped accounts in Active Directory through a scalable and manageable mechanism.

The Contoso Scenario

Contoso rewrote its application for customers to use Microsoft Passport and Active Directory as the authentication mechanism and the identity store for customer accounts.

Security Issues Addressed

Implementing Microsoft Passport authentication to Active Directory addresses the following:

• Authenticating with plaintext passwords.
• Storing plaintext passwords on servers that are not secure.

The "Extranet Access Management" paper in this series covers how to configure Microsoft Passport authentication to Active Directory.

Platform Requirements

The results of the Contoso business and security requirements analysis produced the requirements that the identity and access management platform must fulfill for the company. Key areas that the platform must address are described in the following sections.

Access Management

The access management services of the chosen platform must provide authentication, authorization, and trust services that fulfill the following requirements:

• Both client and server operating systems for client/server applications, and file and print services must interoperate to perform seamless authentication and provide an SSO user experience.
• Global authorization entitlements must be derived from global identity information, although such information may be global only within specific scopes, such as the intranet or perimeter network.
• The infrastructure must implement robust and manageable authorization mechanisms.
• The platform must offer flexible mechanisms for trust, within the organization and externally. Such trusts could be explicit trusts through a public key infrastructure (PKI) configuration, or implicit trusts through operating system mechanisms.
• The infrastructure must implement manageable and secure trust configuration mechanisms to integrate multiple identity stores for future acquisitions.

Directory and Security Services

The directory and security services of the chosen platform must support:

• Secure storage for identity credentials that can interoperate with secure, standards-based authentication mechanisms.
• LDAP to interoperate with certain applications and services.
• Strong encryption of user credentials, and services that must not distribute credential information (even in encrypted form) outside the services.
• Different types of credentials to meet the requirements of numerous authentication protocols, such as the Kerberos version 5 protocol, biometrics, SSL, and TLS.
• Two-factor authentication mechanisms, including PKI and smart cards (for future deployment).
• Seamless interoperability between client/server operating systems over a known set of application and security protocols.

Identity Life-Cycle Management

The identity life-cycle management services of the chosen platform should fulfill the following requirements:

• The identity and access management infrastructure should use a common set of standards-based protocols to manage the company's identity stores.
• A single directory should be able to serve as the central intranet identity store. It must offer redundant services in case of hardware or network failures.
• An extranet directory isolated in the perimeter network will store user accounts for customers and partners.

Application Platform

The chosen platform must support applications requirements for Contoso:

• Existing and planned applications must use the infrastructure for digital identities, which must be accessible through common, standards-based protocols.
• The application servers must have built-in support for strong authentication protocols such as the Kerberos version 5 protocol, and support for client certificate authentication that use SSL and TLS.
• The application servers must be able to implement traditional access control list (ACL) authorization and role-based access control.

Security Auditing

The chosen platform must support the security auditing requirements of Contoso:

• The platform must offer detailed auditing capabilities for all authentication, trust, authorization, and configuration operations.
• The platform must expose manageable, but specific auditing services for all aspects of the server and application infrastructure.

Designing the Infrastructure

Contoso evaluated several vendor platforms for identity and access management, including Microsoft. Based on the company's requirements, Contoso has chosen to standardize on the Microsoft Identity and Access Management Platform. This chapter discusses the infrastructure design that resulted from this decision.

Solution Concept

The key capabilities Contoso requires are provided by the following features of the Microsoft Identity and Access Management Platform:

• The Microsoft® Active Directory® directory service is compliant with the Internet Engineering Task Force (IETF) RFC 3377 — LDAP (version 3.0).
• The extranet Active Directory which holds customer and partner account information can reside in the perimeter network and can support employee authentication without a trust relationship with the internal directory.
• Active Directory provides several options for strong encryption of user credentials. Because of integration with strong network authentication protocols, such as the Kerberos version 5 authentication protocol, Secure Sockets Layer (SSL), or Transport Layer Security (TLS) client authentication, credentials are never distributed outside of the directory.
• Active Directory in Microsoft Windows Server™ 2003 supports password-based credentials through the Kerberos version 5 protocol and Digest authentication protocols. Active Directory also supports public key infrastructure (PKI) credentials for client authentication through the Kerberos version 5, SSL, or TLS protocols.
• Active Directory provides seamless authentication by using the Kerberos version 5, SSL, and TLS protocols.
• Desktop client operating systems, such as Microsoft Windows® 2000 Professional, Windows® XP Professional, and workstations running either UNIX or Linux, seamlessly interoperate with the server operating system for authentication and authorization through the Kerberos version 5, Lightweight Directory Access Protocol (LDAP), and other standards-based protocols.
• Windows Server 2003 and many client operating systems interoperate to authenticate users with a set of default credentials that are calculated or retrieved during the logon process. This authentication is transparent to the user and satisfies the user experience requirement for SSO.
• Windows Server 2003 implements access control lists (ACL) and role-based authorization. Active Directory has robust and flexible mechanisms for expressing entitlements through group membership.
• Windows Server 2003 Directory and Security Services implements several levels of trust, including cross-forest trust, external trust, PKI trust, and cross-realm trust with UNIX Kerberos realms.
• Windows Server 2003 with Active Directory provides detailed auditing capabilities for all authentication, trust, authorization, and configuration operations that are performed on the system.

Solution Architecture

The solution architecture includes the following components:

• Directory services
• Authentication methods
• Authorization methods
• Trust mechanisms
• Identity life-cycle management
• Identity-aware applications

Directory Services

Successful operation of the Contoso identity and access management platform requires the Contoso team to identify the authoritative source for creating identity information, and an authoritative location for storing application and identity information. The team also needs to implement a suitable attribute information flow between directories.

The organization's current directory services configuration for its infrastructure includes the following:

• An intranet Active Directory forest.
• An extranet Active Directory forest.
• A Sun One Directory Server 5.1 (formerly iPlanet Directory Server).

The extranet Active Directory forest cannot be used as the authoritative directory service, because it only contains shadow accounts for employees. The Sun One Directory Server 5.1 is scheduled for decommissioning after the application that depends on it has been rewritten to work with Active Directory.

The intranet Active Directory forest provides the current central repository for user accounts within Contoso. Therefore, the company selected the intranet Active Directory to act as the authoritative source for all directory and application-specific information.

The Contoso team will use an identity integration product to replicate certain directory objects to achieve the following:

• Create accounts for all members of the Sales department in the extranet forest.
• Use an attribute in Active Directory to identify which employees joined Contoso from the recently acquired company.
• Replicate these accounts into Lotus Notes Release 6.5.4 and Sun ONE Directory Server 5.1.

Intranet Active Directory Forest

The intranet forest consists of an empty root domain corp.contoso.com and a single child domain na.corp.contoso.com. The na.corp.contoso.com domain contains the following organizational units (OU):

• Employees
• Solaris Workstations
• Windows Clients
• Groups
• Disabled
• Contacts

The step-by-step process for installing Active Directory on Windows Server 2003 and creating OUs is covered in the product documentation.

Extranet Active Directory Forest

The external forest contains a single domain perimeter.contoso.com. The perimeter.contoso.com domain runs at the Windows Server 2003 functional level and contains the following OUs:

• Employees
• Trial Users
• Groups

There is no trust relationship between the internal and the external forest. The section on Trust later in this chapter discusses the reason for this.

Figure 4.1 shows the Active Directory structures for Contoso.

Figure 4.1. The Active Directory logical structure for Contoso

For more information about Active Directory, see the Windows Server 2003 Active Directory page.

For additional guidance, see the Designing and Deploying Directory and Security Services page.

Authentication Methods

Contoso chose authentication methods based on the characteristics of each method and the environment in which they will operate. The selection process resulted in a single authentication method for the intranet directory, and three methods for the extranet directory as shown in the following two figures.

Figure 4.2. Intranet authentication and authorization mechanisms in the Contoso infrastructure

Figure 4.3. Extranet authentication and authorization mechanisms in the Contoso infrastructure

Authenticating to the Intranet Directory

The primary authentication mechanism for the internal network is the Kerberos version 5 protocol, which Windows Server 2003 and Windows XP Professional support natively. Many other platforms include Kerberos protocol libraries, especially various distributions of UNIX, including Linux. Contoso will use the Kerberos version 5 protocol wherever possible because it is a standards-based highly secure network protocol. Many platforms implement Kerberos version 5 protocol authentication, and for this reason, this protocol provides a good foundation for interoperability.

All managed client computers on the internal network, including computers running the Windows XP Professional and Sun Solaris operating systems, log on by using the Kerberos version 5 protocol to accounts in the internal forest. When they have logged on, users authenticate to specific resources, again using the Kerberos version 5 protocol.

Authenticating to the Extranet Directory

The external network uses several different types of authentication, because the Kerberos version 5 authentication protocol is not currently supported for web clients on Internet-facing applications in the Contoso environment. The three external, Internet-facing applications hosted in the Contoso perimeter network use the following distinct authentication methods:

• Microsoft Passport.
• Microsoft Windows Forms-based authentication.
• Secure Sockets Layer (SSL) and Transport Layer Security (TLS) client certificate authentication.

All three of these authentication mechanisms use the extranet Active Directory forest as the identity store. The extranet domain contains user accounts with mappings for Passport and client certificate authentication, as well as secret password credentials for Windows Forms-based authentication.

Authorization Methods

The main authorization method Contoso will use employs access control lists (ACL) on file and print servers (not shown in Figure 4.3). However, Contoso will also use roles-based access control through Authorization Manager in Windows Server 2003. Authorization Manager interacts with Internet Information Services (IIS) 6.0 to provide both URL – level authorization and detailed, application-level entitlements for access to Web applications.

Contoso will use security groups to organize users, for example by department or role. These security groups will simplify the granting of entitlements to users, and reduce the administrative operations involved when users change jobs within the organization.

Trust

The Contoso team had the following set of choices to consider when implementing federation between the external directory and the internal infrastructure directory:

• Cross-forest trusts
• PKI–qualified subordination
• Shadow accounts

Cross-Forest Trusts

Windows Server 2003 enables the use of trusts between forests. In the Contoso environment, this option was considered so that employees who use the external applications could authenticate to the internal directory through the trust relationship.

The company's long-term vision is to create and deploy applications that take advantage of end-to-end authentication. A necessary task before reaching that milestone is to undertake a thorough analysis of the internal network security, and then follow up with corrective action as needed to fix any problems identified.

In the end, the Contoso team decided not to establish such a trust in the organization's environment. A combination of security concerns specific to the Contoso scenario, and the fact that the company's application scenarios do not currently require the trust relationship informed this decision. In the Contoso case, the main concern is the security of the internal network rather than additional application functionality resulting from a trust relationship between the external and internal forest.

On the other hand, your organization could have scenarios in which you need to implement cross-forest trusts. For example, external users might need to authenticate against an external server and access information inside your organization's intranet. In this case, you could require that the user identity carries across with the application request from the Web server to the application data source. Such a scenario is possible by using the new Kerberos version 5 protocol delegation features, and cross-forest trust mechanisms included with Windows Server 2003.

PKI-qualified Subordination

Public Key Infrastructure (PKI) provides an organization with the ability to exchange data securely over a public network by using public-key cryptography. A PKI consists of certification authorities (CA) that issue digital certificates, directories that store the certificates (including Active Directory in Windows 2000 Server and Windows Server 2003), and X.509 certificates that are issued to security entities on the network. The PKI provides validation of certificate-based credentials and ensures that the credentials are not revoked, corrupted, or modified.

Qualified subordination is the process of cross-certifying CA hierarchies by using basic, policy, naming, and application constraints to limit which certificates are accepted from partner CA hierarchies, or a secondary hierarchy within the same organization. You can use qualified subordination to define which certificates issued by a partner's PKI are trusted by your organization. Qualified subordination also provides methods for compartmentalizing and controlling certificate issuance within an organization according to policy guidelines.

Contoso implemented a three-tier PKI infrastructure consisting of an issuing CA, an offline intermediate authority, and an offline root CA in accordance with Microsoft best practices. Contoso IIS administrators then requested server certificates from the issuing certificate authority to enable SSL encryption on the Internet Web applications on IIS. Contoso also enabled user certificate auto-enrolment policy in Active Directory for employees, and enabled Active Directory Mapper and client certificate mapping in IIS.

Shadow Accounts

The federation design that Contoso selected to implement authenticates internal users (employees) in the perimeter network applications by creating shadow accounts in the external Active Directory. These shadow accounts are only for certificate-based authentication. The shadow accounts contain a limited amount of authorization information relevant to the extranet application, such as name and group membership, but not the user's account password.

The Sales department employees use these shadow accounts to access an application hosted in the perimeter network. Because the shadow accounts are sufficient to access the external application, no trust is required between the external and internal forest.

Identity Life-Cycle Management

To manage the life cycle of digital identities, Contoso selected Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1). This product provides the necessary identity integration support for efficient synchronization, provisioning, and deprovisioning of digital identities. It also provides management agents that enable connections to the various identity stores within the Contoso environment.

The Contoso implementation will use Microsoft certificate services and policy configuration to enable user certificate auto-enrollment. The auto-enrollment capability makes user certificate management possible and cost-effective. In the Microsoft Identity and Access Management Framework, user authentication with client certificates is most appropriate for scenarios in which it adds an identifiable security benefit.

For example, client certificate authentication avoids the security risk associated with using passwords to authenticate to servers hosting the Sales and Contacts application in the perimeter network. Contoso only deploys certificate services and configures auto-enrollment on its internal network, as no application scenario requires certificate-based authentication for external customers and partners.

Identity-Aware Applications

To provide support for developing identity aware applications, Contoso implemented a policy of using the Kerberos version 5 authentication protocol with Active Directory domain controllers wherever possible. Applications that cannot use the Kerberos protocol for authentication (such as extranet applications) will instead use Windows Forms-based authentication for business-to-business (B2B) cases, Microsoft Passport for business-to-consumer (B2C) cases, and certificates or smart cards (in the future) for business-to-employee (B2E) cases.

Authorization will be provided by access control lists (ACL) for persistent objects, such as files and items in the directory. Web-based applications will use role-based access that uses Authorization Manager.

The Contoso Network

Figure 4.4 illustrates the full implementation of the Contoso identity and access management architecture.

Figure 4.4. The network layout of the Contoso identity and access management infrastructure

The implementation for the Contoso identity and access management technology architecture includes the following:

• A firewall that isolates the external Active Directory from the internal network.
• No direct connection from the Internet to the internal network.
• No direct connection from the Internet to the external Active Directory.
• A separate forest for the extranet.
• Two Web servers running IIS 6.0 in the extranet that host the company's applications for sales employees and customers.
• A perimeter network Web server that also hosts the certificate revocation list (CRL) distribution point to check certificates employees use when they authenticate to the external applications.
• A Lotus Notes Release 6.5.4 application and a Sun ONE Directory Server 5.1 that provide services as part of the internal network.
• Certificate services that are on the internal network.

The Contoso identity and access management platform is based on the Windows Server System Reference Architecture (WSSRA) developed by Microsoft and a number of leading hardware and software vendors. WSSRA (formerly Microsoft Systems Architecture 2.0 or MSA) provides tested step-by-step instructions for implementing large-scale IT infrastructures based on Microsoft technologies.

For more information about WSSRA, see the Windows Server System Reference Architecture page.

Appendix A to this document provides the settings to configure the Contoso environment in a Virtual PC (VPC) 2004 test environment.

Enabled Solution Scenarios

A Microsoft platform infrastructure enables the following solutions:

• Identity aggregation and synchronization across multiple directories.
• Password management, including password propagation to multiple directories.
• Intranet access management, including UNIX and SAP integration with Active Directory.
• Extranet access management, including support for B2B, B2C, and B2E environments.
• Developing identity-aware ASP.NET applications, including support for intranet and extranet application development.

The underlying strategy for the company is to replace manual and inefficient administrative processes for managing digital identities with automated and efficient ones. Later papers in this series provide much more detail on each of these targeted areas that are outlined in the following sections.

Identity Aggregation and Synchronization

To provide identity aggregation and synchronization within the organization, Contoso chose to use MIIS 2003 with SP1 as the identity integration product that will integrate with all of the company's directory services and other identity stores, including:

• The intranet Active Directory forest.
• The extranet Active Directory forest (containing customers, partners, and employee shadow accounts).
• The SunOne Directory Server 5.1 (formerly iPlanet Directory Server).
• Lotus Notes Release 6.5.4.

For more information about this topic, see the "Identity Aggregation and Synchronization" paper in this series.

Password Management

To implement effective password management, Contoso chose the following components:

• Group Policy in Active Directory to enforce password strength, complexity, and expiration.
• A custom password filter and notification dynamic link library (DLL) that enables users to change their passwords in Active Directory and then propagates their changed passwords to other directories and identity stores.
• MIIS 2003 with management agents (MA) that manage password changes with all connected directories.
• A custom Windows Service using Windows Management Instrumentation (WMI) to provide a bridge between the Active Directory domain controllers and the MIIS 2003 MAs. This combination will propagate password changes to Lotus Notes Release 6.5.4 and Sun One Directory Server 5.1.
• A customized Web application provided with MIIS 2003 to enable Helpdesk operators to reset user passwords in one location. MIIS 2003 will then propagate the password changes to the connected directories.

For more information, see the "Password Management" paper in this series.

Intranet Access Management

For intranet access management, Contoso standardized on the following configurations:

• Employing the Kerberos version 5 authentication protocol for both authentication and data protection.
• Using Active Directory domain controllers as Key Distribution Centers (KDC) for authentication that uses the Kerberos version 5 protocol.
• Enabling application support within SAP R/3 and the UNIX workstations for authentication that uses the Kerberos version 5 protocol.

For more information, see the "Intranet Access Management" paper in this series.

Extranet Access Management

For extranet access management, Contoso chose the following architecture to grant access to Web applications for partners, customers, and employees:

• An external Active Directory forest to manage accounts for all external users.
• Self registration for establishing customer accounts in Active Directory.
• Microsoft Passport Services for customer authentication and SSO.
• Forms-based authentication with SSL encryption to protect the partner authentication sequence.
• MIIS 2003 to provision employee shadow accounts into the external Active Directory forest.
• Microsoft Windows Authorization Manager for roles-based authorization.
• Microsoft Certificate Services for PKI.
• IIS 6.0 to host the Web applications.
• Microsoft Internet Security and Acceleration Server (ISA) to provide a perimeter network and access control between the internal and external networks.

For more information, see the "Extranet Access Management" paper in this series.

Developing Identity-Aware ASP.NET Applications

To ensure consistency when developing identity-aware applications, Contoso standardized on the following approaches:

• Use the Kerberos version 5 protocol for intranet applications.
• Use Kerberos authentication between application Web servers and back-end resources.
• Perform authentication and authorization integration with Active Directory, which will provide the sole directory service for applications.
• Use role-based access control within Web applications and ACLs on back-end server resources.

For more information, see the "Developing Identity-Aware ASP.NET Applications" paper in this series.

Implementing the Infrastructure

The previous chapters in this paper provide you with information about the typical issues, requirements, and design of an infrastructure for identity and access management. This chapter provides guidance on how to prepare the Contoso Pharmaceuticals infrastructure. It also introduces the tools and templates that you can use to establish the baseline environment, which is an implementation prerequisite for the remaining papers in this series.

This guidance was created to help consultants and customers establish the provided Microsoft Identity and Access Management solution scenarios in a lab or proof-of-concept environment.

Tools and Templates

The Identity and Access Management download package includes Identity and Access Management Tools and Templates.msi, which is the Tools and Templates installer file. When you run the installer file, the resulting folder structure will look similar to the one displayed in the following figure, depending on where you install it.

Figure 5.1. The Tools and Templates folder structure

Note The Tools and Templates MSI package can occasionally produce an error during the installation process. See the Identity and Access Management Series Readme.htm file for more information.

The Tools and Templates that are part of this download include text-based scripts, code samples, and configuration files that are related to identity and access management, but do not include any executable programs or compiled code.

Note These samples are provided as examples only. Be sure to review, customize, and test these tools and templates before you use them in a production environment.

Folder: Baseline

Infrastructure Services Overview

The identity and access management infrastructure of Contoso Pharmaceuticals is built on guidance from the service blueprints in the Windows Server System Reference Architecture (WSSRA) page.

In particular, Contoso has implemented the following Microsoft services to support their identity and access management initiatives:

• Network services, including Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP) services provided by Microsoft Windows Server™ 2003.
• Directory services, including an intranet Active Directory forest and an extranet Active Directory forest provided by Windows Server 2003.
• Certificate services, including a three-tier public key infrastructure (PKI) provided by Windows Server 2003.
• Web application services, provided by Internet Information Services (IIS) 6.0, which is included in Windows Server 2003.
• Middleware services, provided by the Microsoft .NET Framework, and running on Windows Server 2003.
• Firewall and proxy services, provided by Microsoft Internet Security and Acceleration (ISA) Server 2000, and running on Windows Server 2003.

Note Contoso Pharmaceuticals has chosen to use shadow accounts in the extranet Active Directory forest rather than implement a trust between the extranet Active Directory forest and the intranet Active Directory forest as described in the WSSRA guidance.

In addition, Contoso has deployed the messaging services lifecycle guidance, part of the Windows Server System Reference Architecture, as described in Introduction to Messaging Services.

For testing purposes, Contoso messaging services are running on one computer that runs the Windows Server 2003 operating system as well as Microsoft Exchange 2003.

Infrastructure Security

All Windows Server 2003 servers in the Contoso environment have been securely configured by following the appropriate guidance in the Windows Server 2003 Security Guide.

Baseline Implementation

Contoso Pharmaceuticals has a number of groups, users, and other baseline configuration details that are required in their environment for subsequent solution scenarios described in this series to work properly.

This section describes how to configure the basic Contoso environment on top of the services described earlier in this paper, including:

• A computer in the intranet running Exchange Server 2003 that contains the required intranet domain user mailboxes and storage groups.
• An intranet Active Directory forest containing the required OUs, groups, and users.
• An extranet Active Directory forest containing the required OUs, groups, and users.

Populating the Contoso Exchange Environment

The Contoso Exchange environment is the primary mail system for Contoso users. Prior to creating any Contoso users, the required Storage Groups and Mailbox Stores must exist. Run this script from an open command prompt by using cscript.exe as the script host.

Using the ExchangeBaseline.vbs Script

Run the ExchangeBaseline.vbs script by using the cscript executable as the script host. Ensure that you run the script as follows at the command prompt:

CSCRIPT.EXE ExchangeBaseline.vbs <param1>

The script takes the following parameter:

/s – Mandatory. Denotes the target Exchange Server to connect to.

The following is an example command line for running this script:

Cscript.exe ExchangeBaseline.vbs /s <hostname>

Note This script may take a few minutes to run due to the Microsoft Exchange process used to mount mailbox stores.

To configure the Exchange environment

1. Log on to the Contoso Exchange Server with administrative privileges.
2. Click Start, click Run, and then, at the Open prompt, type cmd.exe and then click OK.
3. Run the ExchangeBaseline.vbs file by using cscript.exe as the scripting host.
4. At the command prompt, ensure that you type the script as follows:

   Cscript.exe ExchangeBaseline.vbs /s FFL-NA-MSG-01

Note Replace FFL-NA-MSG-01 with the name of your Exchange Server.

1. Ensure that the script returns the following confirmation message for all operations:Completed Successfully.

If any errors occur after you run the script, correct the problem, and then rerun the script.

Populating the Intranet Active Directory Forest

The Contoso intranet Active Directory na.contoso.com forest is the primary intranet directory for Contoso. The ADBaseline.vbs script will create the required OUs, users, and groups needed for the Contoso solution scenarios in this series.

Using the ADBaseline.vbs Script

Run the ADBaseline.vbs script by using the cscript executable as the scripting host. Ensure that you run the script as follows at the command prompt:

CSCRIPT ADBaseline.vbs <param1> <param2> <param3> <param4>

The script takes the following parameters:

/t – Mandatory. Denotes the target environment to prepare, which must be the intranet for this scenario.

/s – Mandatory. Denotes the domain controller that Active Directory will target.

/m – For the intranet only. Denotes the target Exchange Server to bind to. This parameter is ignored for the extranet.

/f – Optional. Denotes the target data file that contains the Contoso intranet user information. By default, the script uses the IntranetADData.txt file.

The following is an example command line for running this script:

Cscript.exe ADBaseline.vbs /t intranet /s <domain controller> /m <Exchange Server> /f IntranetADData.txt

You can also run this script remotely. If you do, ensure that the workstation is a member of the target domain, and that you are logged on as a domain administrator.

To configure the na.corp.contoso.com forest

1. Log on to the Contoso Exchange Server domain with administrator privileges.

Note You must run the script from the Exchange Server to access the required Exchange libraries and create the target user mailboxes.

1. Click Start, click Run, and then at the Open prompt, type cmd.exe, and then click OK.
2. At the command prompt, run the ADBaseline.vbs script by using the following command:Cscript.exe ADBaseline.vbs /t intranet /s FFL-NA-DC-01 /m FFL-NA-MSG-01 /f IntranetADData.txt

Note Replace FFL-NA-DC-01 with the name of your intranet domain controller and FFL-NA-MSG-01 with the name of your Exchange Server.

1. Ensure that the script returns the following confirmation message for all operations: Completed Successfully.

If any errors occur after you run the script, correct the problem, and then rerun the script.

Populating the Extranet Active Directory Forest

The Contoso Active Directory perimeter.contoso.com domain is the extranet forest for Contoso. As in the previous procedure, use the ADBaseline.vbs script to populate this forest.

To configure the perimeter.contoso.com forest

1. Log on to the Contoso perimeter.contoso.com domain controller with domain administrator privileges.
2. Click Start, click Run, and then at the Open prompt, type cmd.exe, and click OK.
3. At the command prompt, run the ADBaseline.vbs script by using the following command:Cscript.exe ADBaseline.vbs /t extranet /s FFL-CP-DC-01 /f ExtranetADData.txt

Note Replace FFL-CP-DC-01 with the name of your extranet domain controller.

1. Ensure that the script returns the following confirmation message for all operations: Completed Successfully.

If any errors occur after you run the script, correct the problem, and then rerun the script.

Operating the Infrastructure

After you have implemented and tested the infrastructure, a number of ongoing operational activities must happen to ensure that the solutions will continued to operate successfully. This chapter, while not extensive, does introduce a few operational considerations for the infrastructure services in this paper.

Infrastructure Services

For more complete information about operational considerations for your identity access management environment, see the Windows Server System Reference Architecture (WSSRA) page.

Directory Services

The Microsoft® Active Directory® directory service is central to all identity and access management solutions that use the Microsoft platform. Therefore, Active Directory operations are an important part of any procedures that maintain these solutions.

Backing Up Active Directory

Unlike most applications, you can back up Active Directory as part of the system state by using tools such as the Microsoft® Windows Server™ 2003 backup tool. This tool can back up the entire system state while the domain controller is online. Other third-party applications and enterprise backup utilities have the same capability.

You should schedule regular backups for all critical servers, as the backup from one domain controller cannot be used to restore another domain controller in your environment.

Monitoring Active Directory

While backup is a critical operational procedure for the infrastructure, many problems can be identified and resolved before they become serious through actively monitoring Active Directory. Monitoring Active Directory can resolve issues in a timely manner, and users gain the benefit of improved reliability for Active Directory, as well as the services that depend on it, and quicker access times.

There are a number of tasks involved when monitoring Active Directory, including:

• Verifying that the domain controllers can communicate with the monitoring infrastructure.
• Reviewing and resolving all new alerts and events on each domain controller.
• Reviewing Active Directory reports to detect intermittent problems and other issues.
• Reviewing Active Directory and Microsoft Identity Integration Server 2003, Enterprise Edition, (MIIS 2003) activity to ensure the account information created is correct, and that accounts have not been created outside of the automated processes.

For more information about managing and supporting Active Directory, see the Microsoft Windows Server 2003 Active Directory.

Certificate Services

There are a number of operational issues to consider with any public key infrastructure (PKI), including backup and recovery, auditing and monitoring, and certificate management.

Back up all certification authorities (CA) regularly to ensure that the CA database, CA certificates, and the CA keys are protected. This is particularly important for your CAs, as they are not readily retrievable outside of the backup recovery process.

Microsoft Certificate Services records notable items into the Windows Event log. Review these logs regularly to track CA activity, particularly for issued certificates and changes to the certificate revocation list (CRL).

Take great care with certificate management to ensure that the CRL is accurate and up to date. You should also ensure that user certificates are correctly managed to prevent them from expiring while users are out of the office. In addition, you should ensure that the CA and IIS 6.0 certificates are maintained, up to date, and reissued at regular intervals so that users are not locked out from services they need to access.

For more information about certificate management, see the Windows Server 2003 PKI Operations Guide.

Firewall and Proxy Services

Monitor the Microsoft Internet Security and Acceleration (ISA) server not only for performance issues, but also for security alerts and warnings. An ISA server provides a robust monitoring and management framework, and allows access to activity logs and summary reports. You can also configure an ISA server to issue alerts based on the events that it detects.

As ISA server is a critical security resource. Take a great deal of care when examining its log files. When practical, consider enabling an alert system to notify operators about suspect events.

Other tasks involved in monitoring your ISA server include:

• Verifying that the ISA server is operating and that its services are enabled.
• Reviewing and resolving all new alerts and events that the ISA server generates.
• Reviewing the ISA server logs and reports for security issues and other problems.
• Using Network Monitor to track network traffic.

For more information about ISA server and ongoing management and support for it, see the Internet Security and Acceleration Server page.

Patch Management

Contoso Pharmaceuticals uses Windows Server Update Services (WSUS) and the Automatic Updates Service, which is included with Windows Server 2003 and Windows® XP Professional. These two services can ensure that all servers and clients in your environment have the latest security and software updates installed.

For more information about WSUS, see Windows Server Update Services.

Configuration Settings for Microsoft Identity and Access Management Series

Introduction

This appendix summarizes the settings that you can use to reproduce the Contoso environment by using Microsoft Virtual PC (VPC) 2004. The following diagram illustrates the test setup.

Figure A.1 The Identity and Access Management Series test environment

Note The test environment does not completely replicate the full Contoso environment in Figure 4.4, because of the number of VPC images that a single host computer can support adequately.

Host Computer

Recreating the Contoso environment with VPC images requires a host computer with very high specifications. The following table lists the settings and hardware requirements for a single host computer that can run the entire test network.

Note The host should be able to communicate with the Extranet Domain Controller, FFL-CP-DC-01, to run the extranet Web applications installed on that computer.

Table A.1. Host computer setup requirements

VPC Images

To recreate the computers in the Contoso environment, you should build and configure VPC images with the settings in the following tables. After you finish installing the operating system, install Virtual Machine Additions on all images.

Extranet Forest Root Domain Controller

Table A.2. Extranet Forest Root Domain Controller Settings

Internal Firewall/Proxy

To simplify the setup, the test environment uses a single firewall that fulfills the functions of the internal firewall and proxy server between the perimeter network and the intranet.

Table A.3. Internal Firewall/Proxy Settings

Intranet Forest Root Domain Controller

Table A.4. Intranet Forest Root Domain Controller settings

Intranet Child Domain Controller

Table A.5. Intranet Child Domain Controller settings

MIIS Server

Table A.6. MIIS Server settings

Exchange Server

Table A.7. Exchange Server settings

Lotus Notes

Table A.8. Lotus Notes settings

Sun One Directory Server

Table A.9. Sun One Directory Server settings

Offline Root CA

Table A.10. Offline Root CA settings

Offline Intermediate CA

Table A.11. Offline Intermediate CA settings

Windows XP Client

Table A.12. Windows XP Client settings

UNIX Client

Sun Solaris is not supported on VPC 2004, so the test environment uses an alternative UNIX distribution that runs on VPC.

Table A.13. UNIX Client settings

---