Microsoft Identity and Access Management - Extranet Access Management

Chapter 1: Introduction to the Extranet Access Management Paper

Executive Summary

This paper introduces several techniques for managing secure Web access while addressing business-to-employee (B2E), business-to-customer (B2C), and business-to-business (B2B) extranet requirements. The paper also includes prescriptive implementation details for B2E Web single sign on (Web SSO) using certificates and B2C Web SSO using Microsoft® Passport.

For the purposes of this paper, extranet is defined as follows according to the entry for the term in the Microsoft Computer Dictionary, Fifth Edition:

Extranet — An extension of a corporate intranet using World Wide Web (WWW) technology to facilitate communication with the corporation's suppliers and customers. An extranet allows customers and suppliers to gain limited access to a company's intranet in order to enhance the speed and efficiency of their business relationship.

Business Challenge

As demand for access to business resources continues to increase, organizations require internal applications and information to be accessible in a secure fashion to an increasing number of employees, customers, and partners. The challenge of managing extranets that provide such access increases with the levels of access granted. At the same time, the requirements for controlling the levels of access granted to users grow more complex.

In addition to securing sessions over the Web, organizations need a robust authentication and access control mechanism that allows users to gain easy entry to business resources they need to do their work. However, these same organizations need to restrict user access to proprietary business resources without imposing complex and costly management requirements that call for separate entitlement and authentication services.

Many organizations also need to apply a common security model that includes authentication, Web SSO, authorization, and personalization for both existing and planned applications. In addition, many organizations today have multiple applications for employees, partners, and customers. Forcing any of these users to repeatedly log on to access multiple applications within a single browser session creates frustration and a less-enjoyable user experience.

The Business Benefits

In order to realize your return on the investment made in extranet applications, it is essential that users have a secure, seamless, and transparent experience when browsing to multiple applications within a single browser session. This capability protects extranet assets while encouraging additional partners, customers, and employees to participate in automated processes that will either save money or increase revenue for your organization.

This user experience can be provided by consolidating application identity stores and standardizing authentication and authorization, using platform services that require less management while improving security. The business benefits that an organization might achieve with a well thought-out extranet strategy include:

• Reduced administration costs. Identity life-cycle management costs can be shifted to other services, partners, or reduced by automated synchronization processes.
• Increased revenue. Attracting and retaining customers by providing an efficient and secure way of interacting with the organization's business processes.
• Improved business processes. Allowing employees, partners and customers to collaborate securely in near real-time can increase the chance of "closing the deal."
• Improved security for critical business information. A secure and manageable extranet infrastructure combined with an application development platform that leverages the power of the infrastructure makes it possible to have information more accessible, while ensuring that only individuals who should have access do have access to critical business information.

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. Optional additional reading on related topics can be found in the "Intranet Access Management" paper in this series.

To implement the solutions in this paper, readers should have an understanding of the infrastructure described and implemented in the "Platform and Infrastructure" paper in this series, plus the following areas and technologies:

• Familiarity with configuring Microsoft Internet Information Services (IIS) 6.0.
• A basic knowledge of certificate services and public key infrastructure (PKI).

Paper Overview

This paper includes seven chapters. It focuses on the following issues and concepts that are essential to an effective external-facing access management strategy:

• Web SSO.
• Strong authentication over the Internet.
• Roles-based authorization.
• Securing data sent over the Internet.
• Employee access management with extranet directory services.
• Partner access management with extranet directory services.
• Customer access management with extranet directory services.

Chapter 1: Introduction

This chapter provides an executive summary, defines the recommended audience for the paper, and provides reader prerequisites and an overview of the chapters in the paper.

Chapter 2: Approaches to Extranet Access Management

This chapter builds on the information provided in the "Fundamental Concepts" paper. There are many approaches to developing an extranet with strong authentication, SSO services, roles-based authorization, and personalization to meet the needs of your organization. The chapter discusses how you can apply these approaches to extranet scenarios.

Chapter 3: Issues and Requirements

This chapter defines the background, issues, and requirements for the B2E and B2C scenarios for Contoso Pharmaceuticals, a fictitious company.

Chapter 4: Designing the Solution

This chapter focuses on identifying and highlighting key elements that address the initial requirements for a sound design. The Contoso requirements for the B2E and B2C extranet access scenarios are used to specify the solution architecture.

Chapter 5: Implementing the Solution

This chapter focuses on implementing the B2C and B2E solutions for Contoso. The chapter includes step-by-step instructions to configure the Contoso extranet to support both B2E and B2C applications.

Chapter 6: Testing the Solution

This chapter provides guidance on how to troubleshoot and validate the Contoso solution scenarios implemented in the previous chapter.

Chapter 7: Operational Considerations

The final chapter of the paper provides an overview of some core operational procedures required for day-to-day management of the extranet access management solutions.

Solution Scenarios

In addition to a general discussion of extranet access management approaches, this paper also provides detailed prescriptive guidance for implementing an extranet identity and access management solution for organizations operating B2E and B2C scenarios. The prescriptive guidance builds on the Contoso Pharmaceuticals scenario introduced in the "Platform and Infrastructure" paper in this series.

The scenarios in this paper have been developed by Microsoft to illustrate the typical challenges organizations face in providing extranet access management and SSO services. The guidance includes information about how Microsoft technologies can address them. Chapters 3 through 7 of this paper focus entirely on these two solution scenarios.

Business to Employee Extranet Access

B2E extranet scenarios are driven by the requirements for a mobile workforce to access data and applications while not connected to the internal network.

This scenario is designed to provide you with the information you need to implement secure and scalable extranet access based on x.509 certificates, and the following Microsoft products and technologies:

• The Microsoft Active Directory® directory service.
• Microsoft Certificate Services for public key infrastructure (PKI).
• IIS 6.0.
• Microsoft Authorization Manager for role-based access control.

Business to Customer Extranet Access

Contoso has aggressive plans to provide Web applications in its extranet that will provide important information and services for specific customers beyond those on the company's Internet site. Chief among these planned applications is an over-the-counter (OTC) drug trial feedback application that will provide Contoso with a very efficient way of gathering critical customer feedback about upcoming products.

The application must improve customer satisfaction through a better user experience; while improving administration processes and reducing customer support costs associated with public access to their data and applications. This scenario will demonstrate the use of:

• Self registration for new accounts in Active Directory.
• Passport Services for customer authentication and SSO.
• Active Directory and Microsoft Windows Authorization Manager for role-based access control.

Web SSO through Passport Services meets the organizational challenge of reducing support costs for customer remote access to your environment.

Note   For a B2B solution scenario that implements Forms-based authentication using sample code, see the "Developing Identity-Aware ASP.NET Applications" paper in this series.

Chapter 2: Approaches to Extranet Access Management

This chapter continues the discussion of the authentication, authorization, and user management technologies in the "Fundamental Concepts" paper, and their relevance in fulfilling extranet requirements.

Approaches for integrating applications and providing a Web single sign on (SSO) experience may differ for an extranet; they are not equally applicable to business-to-employee (B2E), business-to-business (B2B), and business-to-customer (B2C) scenarios. This chapter discusses the various techniques available and their suitability in each scenario.

A number of vendors also provide extranet-focused authentication and authorization technologies that complement the Microsoft Identity and Access Management Platform for providing extranet access management services. This chapter concludes with a few of these offerings that you may wish to consider.

Extranet Considerations

Before discussing the approaches and solutions available for providing extranet access, it is worthwhile to understand some of the technical areas for consideration that will influence your decision on the approach you select, including:

• Virtual private network (VPN) or Web SSO access.
• Directory service selection.
• Existing applications.
• Identity life-cycle management.
• Password security.

VPN or Web Access

Many organizations are rapidly adopting a Web-based extranet strategy to provide access to remote employees (and partners and customers) because of the challenges of establishing and maintaining access through a virtual private network (VPN).

VPN technology has long been used for remote access and can provide a secure, user-friendly experience when it is possible to use such technology. Unfortunately, many remote locations do not permit outbound VPN for security reasons.

In addition, VPN access often places additional software or hardware requirements on the client, further limiting access only to clients that have been preconfigured for VPN from locations that allow VPN connections.

Deploying Web-based applications and data portals directly to the extranet solves the fundamental problem of VPN access because all access is over HTTP ports, which almost all organizations and networks allow. Doing this while providing the same security and user experience that VPN provides presents the typical challenge that many organizations face.

When VPN access to extranet resources is the preferred approach for employee access or trusted business partners, Microsoft Internet Authentication Service (IAS) is a great choice. IAS is described in the following section.

Internet Authentication Service

Internet Authentication Service (IAS) is the Microsoft implementation of the industry standard Remote Authentication Dial-In User Service (RADIUS) protocol. IAS provides authentication, authorization, accounting, and auditing of remote access (dial-up and VPN) and both wireless and wired 802.1x LAN network connections.

IAS uses identities from Active Directory to provide SSO, and prevents access by unauthorized identities (users or devices) to the network. In addition, the technology offers the following features:

• IAS allows you to use Microsoft Windows-based groups to specify the level of access users and devices may have on the network. Access permissions can be applied to connections using IP filters and virtual local area networks (VLAN).
• IAS interoperates with any dial-up or VPN server, wireless access point or 802.1x authenticating switch that supports the industry standard RADIUS and Extensible Authentication Protocol (EAP) protocols.
• As a RADIUS proxy, IAS forwards authentication and accounting messages to other RADIUS servers.
• Network Access Quarantine Control allows the configuration of remote access client computers to be verified before IAS will grant them access to the network.
• IAS allows you to use various authentication options, including passwords, certificates, and smart cards. Partners can create additional authentication mechanisms (for example, token cards) using the EAP software development kit (SDK).
• IAS makes it easier to deploy a secure wireless LAN by supporting the Protected Extensible Authentication Protocol (PEAP), which does not require the deployment of certificates to wireless clients. PEAP authenticates wireless LAN clients using server-side digital certificates by creating an encrypted Secure Sockets Layer/Transport Layer Security (SSL/TLS) tunnel between the client and the authentication server. The tunnel protects the subsequent password-based authentication exchange.
• IAS is supported on Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition.

For more information about IAS, see the Internet Authentication Service page.

The remainder of this paper focuses on providing Web-based extranet access solutions.

Directory Service Selection

There are several Microsoft technology choices available to provide extranet directory services, including the following in order of preference:

• Active Directory.
• Active Directory Application Mode (ADAM).
• A custom database (using Microsoft SQL Server™ or another database product).

Some of the advantages of Active Directory over ADAM for extranet use include:

• Richer authentication features, including integration with the Kerberos version 5 authentication protocol (including Kerberos protocol transition and constrained delegation for n-tier servers), Public Key Infrastructure (PKI), and Microsoft Passport. Each of these is extremely useful in extranet scenarios.
• Richer authorization features. Authorization Manager, which provides URL Authorization for IIS, cannot use ADAM security principals.
• Active Directory supports cross-forest trusts, which many customers use between an extranet directory and intranet directory to simplify management of identities which must access resources in both.
• Connectivity with many Microsoft applications, such as Microsoft SharePoint™ Portal Server and Microsoft Exchange Server that require users to have an Active Directory account.

Using a custom database to store identities is a popular mechanism that developers often use. Because they can apply the database skills they are comfortable with in this way — many extranet applications are based on custom databases. Unfortunately, the effort required to develop, test, and support custom database-based identity stores for extranet applications is misguided. Platform directory and security services are easy to use, require less development effort, provide a wide range of flexible capabilities, and help reduce the number of identity stores the organization needs.

The remainder of this paper discusses the possibilities and techniques available when using Active Directory as the extranet directory service.

Existing Applications

In many cases, the design and capabilities of current applications deployed by the organization in the extranet will dictate what kind of identity and access management infrastructure should be deployed to support them. For example, if the organization has an existing independent software vendor (ISV) application that only supports a custom authentication mechanism, then little can be done at the application level to use a different authentication mechanism — unless the ISV commits to providing additional functionality via an upgrade.

Organizations creating new applications should carefully weigh the options for an application development platform and make choices based on the level of integration with an evolving extranet access management infrastructure. For more information about how Microsoft Visual Studio® .NET provides a rich application development environment for creating applications that integrate well with an extranet access management infrastructure, see the " Developing Identity-Aware ASP.NET Applications" paper in this series.

Identity Life-Cycle Management

Extranet access management solutions require identity life-cycle management services such as provisioning, and user, credential, and entitlement management.

When choosing various techniques for an extranet access management solution, be sure to reflect on the following business and technology considerations:

• Can the extranet directory be managed from the intranet, or do strict security policies require the extranet to be managed separately?
• Will employee accounts be stored in the extranet directory as shadow accounts, or will there be a trust in place with the intranet directory?
• How will new accounts be provisioned? Will extranet provisioning be handled with intranet accounts? Will identity information be synchronized between the intranet and extranet?
• Will partners require Web-based delegated administration capabilities?
• Will your organization manage customer accounts, or will customers manage their own accounts?
• How will users change and reset passwords?

The techniques discussed in this paper are influenced by the identity life-cycle management choices your organization should make.

Password Security

Before considering each authentication technique, be aware that passwords are often the weakest elements of security systems and frequent targets for attack. It is important to understand which authentication techniques are password-based, because they create larger attack surfaces in your extranet.

The way a password is used for authentication is also something to consider. Some authentication protocols (such as Basic and Forms-based authentication) require a plaintext password to authenticate a user. This means that the server itself must have a plaintext password to authenticate the user even though the communications channel between the browser and server is encrypted. Today's viruses and worms can take advantage of plaintext password authentication mechanisms to capture hundreds or thousands of passwords before an organization realizes what has happened.

Other protocols may use a secure, one-way hash (such as Digest authentication), meaning that the server does not require any knowledge of the plaintext password. And some authentication protocols do not use passwords at all (such as SSL and TLS Certificate authentication).

For these reasons, many companies choose not to use password-based authentication techniques in their extranet, particularly for employee access. This approach helps limit the possibility of employee password attacks from outside the intranet.

Authentication Methods

There is a wide range of authentication technologies and techniques that Web applications can use on the extranet. Because of this greater variety across extranet scenarios, extranet authentication is typically more complex and varied compared to the authentication technology an organization uses for its intranet. The method you choose will often be dictated by:

• The role of the user and the sensitivity of the data being accessed.
• A particular type of credential that forces a particular authentication mechanism.
• A particular identity store (possibly external) that fits the requirements of the scenario.
• The ability of the method to protect sensitive data sent over the Internet.
• The user experience provided by different authentication mechanisms.

Authentication methods applicable to extranet scenarios include:

• Client X.509 digital certificate authentication over Secure Sockets Layer 3.0 (SSL) and Transport Layer Security (TLS) 1.0.
• Microsoft Passport Services.
• HTTP Basic and Digest authentication.
• Forms-based authentication.
• Web Services – Federation.

SSL and TLS Authentication

Nearly all data that is transmitted over the Internet between an organization's extranet applications and the employees, partners, and customers who use them should be protected from unauthorized individuals viewing the communications channel. For this reason, SSL or TLS is almost always used in extranet scenarios to provide data security, which these protocols do by encrypting all client/server traffic.

SSL and TLS are well-known mechanisms that provide this secure communication channel between client and server applications. Less well understood is how the protocols also provide robust authentication for both the server and the client.

Server Authentication

Organizations commonly use SSL and TLS 1.0 to secure Web application data and to verify the identity of the organization's Web applications. This is typically referred to as server authentication.

SSL and TLS over HTTP, commonly referred to as Hypertext Transfer Protocol Secure (HTTPS), automatically authenticate server applications to clients using a server's X.509 certificate.

SSL server authentication occurs because the client browser application, such as Microsoft Internet Explorer, validates the server's certificate according to PKI policy maintained on the client system. In order to achieve SSL and TLS server authentication, X.509 certificates only need to be installed and configured on a Web application server, such as one running IIS. No client configuration is required in most cases.

Another possibility is to use SSL and TLS to provide strong, mutual authentication (the combination of server and client authentication) by configuring the Web application server to require client authentication using X.509 certificates.

Client Authentication

Client authentication requires that clients are issued X.509 certificates. X.509 certificates may be stored on the user's computer as software certificates, on a smart card, or in a hardware token as a hardware certificate.

The client browser application (such as Internet Explorer) attempting to authenticate the user to the server using SSL or TLS, must provide the server with the user's X.509 certificate, and also prove that it has access to the private key associated with the certificate. After it has been validated, the Web application server can map the client's certificate to a corresponding account in Active Directory in order to create an authorization context.

SSL client authentication, because it is based on strong public key technology, provides extremely strong authentication for high-value applications and data.

For more information about SSL client authentication, see the Step-by-Step Guide to Mapping Certificates to User Accounts.

Note   While X.509 digital certificates offer the possibility of strong authentication without using a password, the private key material associated with the certificate must be well protected. An attacker who gains access to the key material will be able to authenticate as the user. Workstations should be protected by security policy and workstation owners should take the normal precaution of locking workstations when they are not in use. Additional security can be gained by storing the certificate on a smart card or other protected hardware token.

For more information about workstation security please see the Windows XP Security Guide.

Single Sign On

SSL and TLS client authentication does not require the user to provide a password to authenticate to a Web site. Instead, the user must have access to an X.509 digital certificate stored on either the user's computer or a separate hardware device. Not only is authentication using digital certificates more secure then password-based authentication, it also provides a single sign on (SSO) experience for the user if one of the following conditions is met:

• The user has exactly one certificate in their user certificate store that is accepted by the Web application server.
• The user has explicitly configured a certificate to be used for a particular Web application resource through the Windows Credential Manager.

Appropriate Extranet Scenarios

The Microsoft Windows Server platform provides built-in, no-cost certificate services for issuing both server and client X.509 certificates that will meet the security and business requirements of many organizations. However, a significant amount of additional effort is required to deploy, operate, and manage a certificate services infrastructure and not every organization will decide that the security characteristics of strong, mutual authentication over SSL and TLS are worth the expense. However, when the environment includes a manageable number of internal or external users, and the Web application delivers very sensitive information, a certificate services infrastructure can be a worthwhile business investment.

For the reasons discussed above, SSL and TLS 1.0 are perhaps best suited for use in B2E and some B2B scenarios. On the other hand, it is better to design B2C and the other B2B scenarios around alternative techniques for client authentication.

Microsoft Passport

Microsoft Passport presents a number of authentication service advantages for organizations that are deploying extranet applications. First among these advantages is that Microsoft Passport accounts are issued and managed outside the organization that is hosting the extranet application. This external management means that the hosting organization has no responsibility to provide account life-cycle management for customers or other users that use Passport for application authentication.

For certain scenarios (primarily B2C and B2B) in which the numbers of users can be in the hundreds of thousands or even millions, Passport provides organizations with the ability to avoid millions of dollars of identity management-related overhead. Users handle forgotten passwords and user identities directly with the Passport service.

For more information about Microsoft Passport Services, see the following resources:

• The Microsoft .NET Passport Review Guide
• The Microsoft .NET Passport for Developers Web page

Single Sign On

Another advantage provided by Passport authentication is that the Passport authentication protocol can provide a Web SSO user experience. In Passport terms, this means that a user authenticates once (per browser session) to Passport Services, and then can authenticate to different Passport-enabled applications without entering their credentials again (if the application permits Passport SSO). Because Web SSO is a Passport-wide feature, cross-site Web SSO can be achieved through Passport, including to the organization's extranet and other Passport sites as well.

Windows Server 2003 and IIS 6.0 offer a powerful new feature that allows for Passport accounts to be mapped to Active Directory accounts. This feature is important because it allows applications to be developed to a common security standard that focuses on Active Directory for authorization and entitlement management, while Passport is used for authentication.

Note   Because Microsoft Passport Services offer the possibility of SSO authentication to many different sites and applications, the Passport password must be well protected. An attacker who gains access to the Passport password or a Passport-authenticated workstation will be able to authenticate to Passport sites as the user. Workstations should be protected by security policy and workstation owners should take the normal precaution of locking workstations when they are not in use.

For more information, see Setting Up .NET Passport in IIS 6.0 (IIS 6.0).

Appropriate Extranet Scenarios

Passport is perhaps best suited for organizations running B2E, B2C, and B2B applications in environments where large volumes of users need to authenticate to your applications. The value of the data exposed by these applications should at the same general level as the security characteristics of the Passport authentication services.

For example, Microsoft provides a Web site for employee classified advertisements that any Microsoft employee (as well as employee spouses, friends, and acquaintances designated by the employee) can use to list personal items for sale. This classified ad service uses Passport authentication, which meets the Microsoft requirement for maintaining some control over access to the service, but makes it accessible for a large group of individuals without the need to maintain credentials for those users.

On the other hand, using Passport for authentication may not always be the most suitable alternative. The three main issues to adopting Passport for B2C and B2B authentication are:

• The manageability of Passport accounts that may be associated with an organization.
• The security policies for Passport accounts.
• Understanding how to securely use Passport.

The first issue is due to the fact that Passport accounts are conceptually tied to an e-mail account. The e-mail account might be a Hotmail account (a Passport partner), but it also might be an e-mail account that belongs to an organization. Passport Services today do not provide the ability for an organization to manage all of the accounts in the e-mail namespace that it owns. The ability to do so would provide an opportunity to build authorization and business logic around the Passport account e-mail attribute.

The second issue is due to the fact that today there is no ability to require (at the application level) that a Passport account be managed by strong security and password policies. Common customer requirements are for Passport to enforce the same type of strong password policy that organizations apply to their own networks. Again, future versions of Passport plan to have this feature.

The third issue is that the Passport authentication protocol is based on the cookie mechanisms defined for HTTP state management as defined in RFC 2965. When sent over the Internet unencrypted, authentication cookies can be captured and replayed, thereby allowing an attacker to access an application as a valid user. To prevent replay attacks, Passport has the capability to enforce the application to require that all cookies it receives for Passport authentication are protected by SSL, which completely mitigates the threat of cookie theft and replay.

Note   Initial authentication of the user to Passport, which includes the credentials of the user, is always protected by SSL or TLS.

Digest and Basic Authentication

Basic and Digest authentication are part of the HTTP 1.1 protocol as defined in RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication".

Note   Digest authentication has improved in Windows Server 2003. Windows Server 2003 comes with an authentication package for Windows Digest Authentication, which is used by IIS 6.0. IIS 5.0 in Windows 2000 Server implemented a form of digest authentication, but its implementation was flawed in that it required user passwords to be stored in Active Directory using reversible encryption.

Digest Authentication in Windows Server 2003 (incorrectly called Advanced Digest Authentication in some documentation) stores user credentials on the domain controller as an MD5 hash (a one-way hash) and does not require reversible encryption for user passwords.

Issues

There are a few common issues with the use of Digest and Basic authentication for extranet applications that include:

• No Web SSO functionality.
• The generic Internet Explorer logon dialog.
• Basic authentication delivers plaintext credentials to the Web server.

The first issue is due to the fact that Digest and Basic authentication are session-based authentication mechanisms that are specifically prohibited from using the same credentials to establish a new session. In HTTP terms, this means that when the user browses to a new URL, the Digest or Basic authentication credentials will not be reused and the user will receive a new login prompt. For extranets that have more than one application, this produces a poor user experience.

The second problem is that both Digest and Basic authentication are integrated in Internet Explorer through a similar dialog box that is displayed to the user when the server issues a Digest or Basic (or NTLM) authentication challenge. The Internet Explorer dialog does not provide much information to the user about what they are about to do or what to do if it doesn't work.

The final problem worth noting is specific to Basic authentication. While Digest uses cryptographic techniques to hide the user's password from the Web server, Basic authentication transmits the plaintext password to the Web server. The security risk is that a Web server is not particularly trusted and should not be permitted to see the plaintext credentials. Even if the Web server is highly trusted (managed by the same group in the organization that manages Active Directory, for example), there is still a security risk if the server is compromised. If the server is compromised, there is a possibility that malicious code could be installed on the server to capture plaintext passwords and transmit this information back to the attacker. Any service that uses Basic authentication should switch to Digest authentication as soon as possible.

Note   Digest authentication uses cryptography to protect user credentials (the password) during the client-to-server authentication step. Basic authentication, however, transmits all sign-on credentials in plaintext, and for this reason this method of authentication is vulnerable to interception unless SSL and TLS 1.0 are used to protect all URLs that use Basic authentication.

Single Sign On

For those sites that enable Basic or Digest authentication, the user can create an SSO experience by selecting Remember My Password during logon in Internet Explorer. This only caches credentials for a specific Web site, so it is not a full Web SSO experience.

The lack of Web SSO is a limited concern when users only need to access a single application or URL. Microsoft recommends that organizations deploying multiple extranet applications look for more robust authentication methods to provide Web SSO.

Appropriate Extranet Scenarios

Basic authentication, even over SSL, is not recommended for any extranet scenarios because of its security limitations.

Digest authentication has better security characteristics than Basic authentication because the Web server doesn't receive a plaintext password. However, because the user experiences are the same, Digest authentication is best reserved for specific scenarios where users trust how applications have been established in the extranet.

The implementation of Digest and Basic authentication in IIS 6.0 is closely integrated with Active Directory. Although this approach makes centralized management of accounts possible, the application architect must consider how accounts for employees, partners, and customers are provisioned and maintained. Because these authentication methods are user name and password-based, some thought has to be given to how the user will manage their account and perform such actions as password changes and password resets, as well as how entitlements will be managed on an ongoing basis.

Forms-based Authentication

Forms-based authentication uses Web forms to collect user credentials such as user names and passwords. After these credentials are collected, it is typically up to the application to validate the credentials using a choice of mechanisms and then establish session state through HTTP cookies. One common use of cookies in this scenario is to provide Web SSO. Applications can be developed using this approach so that authenticated users are able to move freely between cooperating services. Application development platforms such as Microsoft ASP.NET provide interfaces that can validate the client credentials as well as write cookies containing information about the user.

The main advantage of Forms-based authentication is that it does not provide a generic logon dialog as described previously for Digest and Basic authentication. Using the state information in cookies and the rich UI possible in Forms-based authentication, the developer has the ability to manage the client's logon experience. Aids to the logon experience can include hints about what credentials to use, helpful error messages about what to do if authentication fails, and where to go for more information.

Another advantage of Forms-based authentication — in some scenarios — is that Forms-based authentication is easy to implement against non-directory identity stores. The application developer has a choice of any identity store to authenticate against, including directories that use Lightweight Directory Access Protocol (LDAP), SQL Server databases, or even flat files that contain user names and passwords. This wide-open approach to identity authentication, however, has created many of the problems that organizations face with identity life-cycle management, so only make such choices carefully.

Single Sign On

Forms-based authentication can provide an SSO experience to users, depending on how all participating applications have been designed.

The disadvantage of Forms-based authentication (and the associated Web SSO cookies) is that there is no common standard for creating the cookies. In order to enable Web SSO between applications, each application must be able to understand the cookie content. To create a secure Web SSO mechanism, it is also necessary that cookies be protected from tampering by potential attackers. It is possible to protect cookies and meet security requirements using shared key or public key cryptographic techniques, but such mechanisms usually imply configuration and management of the keys by application administrators. Third party SSO products usually handle key rotation automatically.

Note   The "Developing Identity-Aware ASP.NET Applications" paper in this series includes sample code for implementing Forms-based authentication and Web SSO.

Appropriate Extranet Scenarios

Forms-based authentication is appropriate for B2E, B2C, and B2B scenarios as long as the application architect fully understands the issues and the trade-offs relative to other authentication options.

Note   Like Basic authentication, Forms-based authentication transmits all sign on credentials in plaintext, making it vulnerable to interception unless SSL or TLS are used to protect the application logon page, and all pages where authentication cookies are sent. If possible, the architecture should isolate and protect the servers that accept and process plaintext credentials from the servers that deliver the Web applications.

Security Assertion Markup Language

Security Assertion Markup Language (SAML) is an industry standard for creating XML-style security tokens. SAML tokens can be used as authentication "tickets" much like HTTP cookies can be used, with the advantage that a standard format allows applications, platforms, and operating systems from different vendors to interoperate with respect to authentication and authorization.

However, SAML is not a complete authentication mechanism in that it does not define client-to-server protocols. For more information about SAML, see the Organization for the Advancement of Structured Information Standards (OASIS) home page.

XML Web Services

XML Web services are the fundamental building blocks in the move to distributed computing on the Internet. Open standards and the focus on communication and collaboration among people and applications have created an environment where XML Web services are becoming the platform for application integration. Applications are constructed using multiple XML Web services from various sources that work together regardless of where they reside or how they were implemented.

Web Services include a number of standards that apply to identity and access management. The main standards that affect Authentication are Web Services – Security (WS–Security) and Web Services–Federation (WS–Federation).

Web Services–Security

WS–Security is a multi-vendor open specification for implementing security in Web services. WS–Security Version 1.1 is now an OASIS standard. Related specifications such as WS–Trust, WS–Federation and WS–SecureConversation combine with WS – Security to create an end-to-end protocol for Web services authentication and data protection.

For more information about Web services, see Web Services and Other Distributed Technologies, on MSDN and the article "New Technologies Help You Make Your Web Services More Secure" on the Web Services Developer Center.

Web Services–Federation

WS – Federation is a multi-vendor open specification that covers establishing federation trusts across public networks. These federation trusts can link organizations or link external users to an organization. WS–Federation builds on the foundations and mechanisms specified in WS–Security, WS–Policy, and WS–Trust, by using the concepts of claims and security tokens to enable richer trust realm mechanisms across and within federations.

For more information about the WS–Federation definition, see "Web Services Federation Language", on the MSDN Web site.

Single Sign On

WS–Security and WS–Federation can enable single sign on to multiple applications, if those applications are hosted by one federated organization. Signing in to an application that is hosted by another organization with a separate trust relationship would require the user to log on again.

Appropriate Extranet Scenarios

WS–Security and WS–Federation give the flexibility to address B2E, B2B, and B2C scenarios, depending on which federation setup is in use. The next section illustrates how Windows Server 2003 R2 provides federation topologies for each scenario.

Windows Server 2003 R2

Windows Server 2003 R2 implements WS–Federation as part of the Active Directory Federation Service (ADFS). ADFS enables organizations that use Windows Server 2003 R2 to implement one of three federation topologies:

• Federated Web SSO. Federated Web SSO enables two businesses to establish a a federation trust. This federation trust would then enable the customer business to authenticate to one or more Web applications that the supplier business hosts, and to order components online. The Federated Web SSO topology is an extremely effective way of implementing secure authentication between partner organizations (B2B), and is increasingly the recommended way of providing this type of integration.
• Federated Web SSO with Forest Trust. Federated Web SSO with Forest Trust enables organizations to integrate external and internal Active Directory forests. The organization can use ADFS to link the intranet and extranet forests, enabling external and internal users to access and authenticate to network resources while increasing security. Federated Web SSO with Forest Trust is suitable for both B2E and B2C scenarios.
• Web SSO. Web SSO enables users to authenticate only once, and then access multiple Web-based applications. Web SSO can be used for both B2C and B2E scenarios.

For more information about ADFS, see "Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2".

Summary

The following table summarizes the extranet authentication techniques discussed above.

Table 2.1. Summary of Extranet Scenarios and Authentication Techniques

Legend:

    Recommended

º     Optional

    Not recommended

    Fully Supported

*    Supported with some customization

û    Not Supported

Authorization Techniques

Extranet applications can employ the same range of authorization techniques as intranet applications. The list of possible techniques includes:

• Access control lists (ACL) on objects and resources
• Role-based access control (RBAC)
• Claims-aware authorization in ADFS

The "Fundamental Concepts" paper in this series provides a full discussion of the first two techniques. The solution scenarios in this paper describe the use of Authorization Manager to implement URL authorization, while additional guidance on authorization is available in the "Developing Identity-Aware ASP.NET Applications" paper in this series.

For more information about Windows Authorization Manager, see Role-Based Access Control for Multi-tier Applications Using Authorization Manager.

ADFS in Windows Server 2003 R2 provides a new authorization technique that uses claims to establish whether a user is authorized to access a resource. Claims are statements (for example, name, identity, key, group, privilege, or capability) made about users and understood by both partners in an ADFS federation.

A claims-aware application is a Microsoft ASP.NET application that has been written by using the ADFS library. This type of application is fully capable of using ADFS Claims to make authorization decisions directly.

A claims-aware application accepts claims that the Federation Service sends in ADFS security tokens. Claims-aware authorization consists of a Hypertext Transfer Protocol (HTTP) module and objects for querying the claims that are carried in the ADFS security token.

For more information about how the Federation Service uses security tokens and claims, see the Federation Service Web Page, on Microsoft TechNet.

Trust Techniques

The "Intranet Access Management" paper in this series describes how trust can enable SSO in the Windows platform on the intranet. Many of the same concepts apply to trust relationships between intranet and extranet forests, however, there are a few additional issues to consider.

Using Windows Trusts

Many organizations are satisfied (even if they cannot achieve SSO) if a user can use their intranet Active Directory password-based credentials to log on to the extranet. This can be implemented using a one-way external or cross-forest trust from the extranet to the intranet. A few points to consider when evaluating the use of Windows trusts between an extranet and intranet include:

• Ports — Windows trust requires that a significant number of ports be opened in the firewall that allow domain controller to domain controller and workstation to domain controller communication.
• SSO — SSO using the Kerberos protocol is generally not possible if proxy authentication is required. For more details, see the Microsoft Knowledge Base article, "Internet Explorer Does Not Support Kerberos Authentication With Proxy Servers".
• SSO using NTLM — This configuration is possible, but an external Web site will need to be explicitly added to the Local Intranet Security Zone feature in Internet Explorer For more information, see Setting Up Security Zones.

Many organizations choose not to establish a Windows trust between the intranet and extranet because of one these factors or because they wish to achieve greater logical separation between the external and internal-facing networks.

Shadow Accounts

Creating "shadow" accounts in the extranet that mirror accounts in the intranet is one way that works with most kinds of authentication using the same identity (username) and possibly even the same password. The B2E scenario in this paper describes how to use shadow accounts along with X.509 client digital certificates to enable strong authentication without passwords, trusts, or open ports connecting the internal and external networks.

A good solution for automatically managing shadow account identities is described in the "Identity Aggregation and Synchronization" paper in this series. Microsoft does not recommend whether Windows trust or shadow accounts should be used — organizations should choose a model that they are most comfortable with.

Password synchronization is a more contentious issue and Microsoft does not recommend synchronizing intranet account passwords to the extranet unless no better option exists.

PKI Trusts

When using shadow accounts without synchronized passwords, there is usually some other form of trust used to link the intranet identity with the extranet identity. The B2E scenario in this paper describes how digital certificates are used to authenticate employee access to the extranet. Before this scenario can be implemented, a PKI trust must be established between the intranet certificate services and the extranet Web servers. The PKI trust allows the extranet Web servers to trust the contents of the intranet digital certificates in order to perform the mapping from digital certificate to shadow account in the extranet Active Directory.

Trusting Passport or Other Identity Stores

The B2C scenario in this paper describes how Passport identities can be mapped to accounts in the extranet Active Directory. Before this can happen, the tickets must first be validated as coming from Passport. The process of performing the validation is based on the keys that were exchanged between the organization and Passport during the establishment of the contract, or trust, between the two entities.

Federation

The federated identity mechanisms in products such as Windows Server 2003 R2 enable the establishment of trust between two organizations. The parties of the trust will agree on which identities will be federated and what claims about those users can be made as they navigate from one organization's resources to another.

Personalization Techniques

Personalization is an interesting topic for discussion because it means many different things to different people. Personalization could be data that is stored relative to some identity. The data could be specific to a single application and, for example, could include information such as a relationship level between an organization and a customer such as "Gold," "Premier," "Silver," or other such designations.

The challenge of storing personalization data is where to put it. In general, Microsoft recommends that user identity information such as credentials, entitlements, and other security-related data should be stored in Active Directory, but storing personalization information in Active Directory typically requires schema extensions. It should be noted that frequent changes to personalization data types or attributes could significantly burden the Active Directory service and the Active Directory administrators.

Accordingly, application developers should evaluate Active Directory Application Mode (ADAM) or SQL Server databases for storing highly-volatile or application-specific personalization data. See the "Intranet Access Management" paper in this series for more information about ADAM.

Personalization can also indicate the manner in which information or options are displayed to a Web application user through a portal. For example, if an organization has six applications or resources for all of its users but only three of these are represented as links that a customer can use, the portal implementation design requirements could state that only the customer-relevant links should be displayed to a user with the role of "customer."

This kind of personalization can be implemented in the portal application using a roles-based authorization mechanism such as Windows Server Authorization Manager or ASP.NET roles.

Personalization is a feature that ships in many commercial applications as well. Examples of Microsoft products that support personalization include:

• SharePoint Portal Server 2003
• Windows SharePoint™ Services
• Microsoft Commerce Server 2002
• Microsoft Content Management Server 2001

Independent Software Vendor Solutions

Microsoft products currently do not provide an end-to-end solution for some aspects of extranet access management. The key gaps in Microsoft product offerings include:

• Cross-platform Web SSO capabilities.
• Web SSO solutions that do not require custom code.
• Web-based delegated administration and self-service (for identity life-cycle management in the extranet).
• Cross-platform authorization interfaces.

For more information, visit the Web sites of the following independent software vendors (ISV) listed in alphabetical order for products designed to fill these gaps:

• BMC Software (acquired OpenNetwork)
• Computer Associates (acquired Netegrity)
• Oracle (acquired Oblix)
• Proginet (acquired Blockade)
• RSA Security

Chapter 3: Issues and Requirements

This chapter introduces the Contoso Pharmaceuticals scenario, including background, issues, and requirements for the company's business-to-employee (B2E) and business-to-customer (B2C) needs.

Note   For a B2B solution scenario that implements Forms-based authentication using sample code, see the "Developing Identity-Aware ASP.NET Applications" paper in this series.

Business to Employee Extranet Access

The sales personnel at Contoso work both in the office and on the road, visiting customers and building the company's business. One of their primary tasks is capturing sales and contacts information in a centralized database at corporate headquarters. Creating this information requires the sales force members to have access to Web applications that allow them to enter and modify customer contact information while they are out of the office. Additional applications are planned for the in the near future.

Background

Contoso maintains a legacy B2E Web application that allows its sales employees to log on remotely and manage customer information. The application authenticates users against an external directory that is separate from the organization's intranet directory. Because there is no synchronization between the two directories, sales employees were forced to create additional user accounts and passwords. This situation created management problems and security concerns because sales employees frequently either forgot their additional passwords (for accessing the application) or taped written reminders to their laptops.

The legacy Contoso Sales and Contacts application is a Web-based application hosted on Microsoft® Internet Information Services (IIS) 6.0. The Web server performs Basic authentication over Secure Sockets Layer (SSL) by authenticating the user against an application directory using Lightweight Directory Access Protocol (LDAP) simple bind.

After the user has been authenticated, the application queries a group attribute on the user object in order to perform authorization. The application determines whether the group attribute contains a value equal to Sales. The presence of the Sales value in the group attributes authorizes the user to access all sales and contact information in the application. There is no specific control implemented in the authorization mechanism — any user with access is allowed to create, delete or edit any information in the database.

The application provides no auditing functionality to track what changes were made to the database or who made them.

The accounts in the external directory are created manually as part of the hiring process for new Sales department employees, which increases IT administrative costs because administrators must create accounts in the organization directory and "shadow" accounts in the external directory.

In addition, there have been problems with new members of the sales force not getting access to the application because the manual process is not executed. When this occurs, the new employee must call the Helpdesk to determine why they don't have access.

Business Issues

The following issues have been identified as adversely affecting the business strategy for Contoso:

• The processes surrounding how Contoso administers the Sales and Contacts application (for example, creating new accounts and resetting passwords) sometimes delays critical updates to the contact database. These delays result in:
  • Reduced employee productivity.
  • Missed business opportunities.
  • Missing or incomplete sales financial data.
• Manual provisioning of the identity store for the Sales and Contacts application burdens administrators with time-consuming user administration duties, resulting in excessive maintenance costs.
• Sales employees complain about cumbersome processes required to use the application and inadequate support, factors that result in lower employee satisfaction and increased attrition. The situation has occasionally made Contoso look unprofessional to its customers and unequipped to handle their needs.

Technical Issues

The following technical issues affect Contoso:

• The existing authentication from the Sales and Contacts application is not practical to use as a Web SSO infrastructure for other externally-facing applications.
• Authorization is currently built into the application with no easy way to modify user roles or extend them to other applications.
• The application queries the directory for every request, placing a significant load on the directory. This authorization information should be cached.

Security Issues

The following security issues negatively impact the security strategy for Contoso:

• Many sales employees write their external account passwords down to remember them, thus compromising security.
• Currently, there is no auditing of access to the Sales and Contacts application.
• Although the Hypertext Transfer Protocol Secure (HTTPS) protocol is used to protect the logon to the Sales and Contacts application, employee shadow account passwords are exposed on the externally-facing Web servers. This situation creates the risk of exposing these credentials if a sophisticated attacker successfully compromises the Contoso Web servers. If an employee's shadow account password is compromised, then all of Contoso's sensitive sales and contacts data would be compromised as well.
• The LDAP simple bind that is used to validate the account password is exposed on the external network (although not on the Internet) because the application directory does not support encrypted LDAP bind.
• Many Contoso Sales department employees use the same user name and password for the Sales and Contacts application as they do for their internal accounts. This situation exposes these credentials to both external threats (if a Web server located in the perimeter network is compromised) and to internal threats (from Sales and Contacts application administrators who should not have access to such information).

Solution Requirements

Contoso must satisfy the following requirements before the company can complete this portion of its identity and access management solution:

• Provide a Web SSO infrastructure that supports key applications used by employees.
• Use digital client certificates with Web SSO.
• Use the Microsoft Active Directory® directory service as the user identity store.
• Restrict access to the application by authorizing users according to their role (sales employee).

Business to Customer Extranet Access

Contoso currently has a B2C application that allows customers to provide feedback on trial products. The user population for the Customer Trial feedback application includes members of the general public who agree to participate in the trial.

Background

For Contoso customers to access the Customer Trial feedback application, accounts are matched in Active Directory to service authentication and authorization requests. Providing Helpdesk services for account creation, maintenance, and password reset requests requires a large staff available 24 hours a day while the trial is running.

The Customer Trial feedback application uses HTTPS as its communication protocol. The Web server uses Basic authentication to authenticate users against an application directory using LDAP 3.0. The registration process that users follow to join the trial automatically creates customer accounts. After completing the registration process, each user receives a user name and password that they use to log on to the Customer Trial feedback application and submit a weekly trial report.

Business Issues

The B2C Customer Trial feedback application for Contoso, and the processes that directly relate to it, present the following major business issues:

• As the company's customer base grows, Helpdesk costs to maintain passwords are increasing.
• The company is receiving negative feedback from customers that describes administrative support for the Customer Trial feedback application as slow and cumbersome. Some frustrated customers quit the trial program, leaving Contoso with less customer feedback.
• Customers are having difficulty remembering their user names and passwords for the Contoso site, placing a large administrative burden on the Helpdesk to service password reset requests.

Technical Issues

The B2C Customer Trial feedback application, and the processes that directly relate to it, present the following major technical issues for Contoso:

• The existing authentication process for the Customer Trial feedback application is not practical to use as a Web SSO infrastructure for other externally-facing applications.
• Authorization is currently built into the application with no easy way to modify user roles in the Customer Trial application or extend them to other applications.
• Users are not able to self-manage account information such as passwords.

Security Issues

The B2C Customer Trial feedback application, and the processes that directly relate to it, also present the following major security issue for Contoso:

• Customers who cannot remember their user names and passwords for the Contoso site are using the same passwords for all their Internet accounts, making the accounts less secure.

Solution Requirements

Contoso must satisfy the following requirements to complete this portion of its identity and access management solution:

• Implement Web SSO that does not require Contoso to manage the customer accounts internally.
• Implement user provisioning for customer user accounts.
• Encrypt storage, password transmission, and other sensitive data.
• Use Active Directory as the user identity store.
• Run the Customer Trial feedback application using IIS 6.0.

Chapter 4: Designing the Solution

The previous chapter considered the business, technology, and security issues for two extranet access management scenarios, and listed the solution requirements for each. Designing the appropriate solution is the next part of the overall process.

The following sections in this chapter present a solution concept, the solution prerequisites, and a solution architecture for each of the extranet access management scenarios. After the design is complete, the last sections describe how each of the solutions will work.

Business to Employee Extranet Access

One highly secure choice for providing access to employees is to integrate X.509 digital certificate authentication into the Contoso extranet platform to create an easy to manage SSO environment for Web-based applications. Web single sign on (SSO) using client certificate authentication provides a solution that addresses the security challenges faced by organizations with business to employee (B2E) initiatives, while meeting growing business requirements such as telecommuting and support for a mobile workforce.

Solution Concept

The following figure illustrates the solution concept by providing a high-level overview of the identity and access management solution for Contoso, which is designed to meet the company's B2E requirements. To secure access to the Sales and Contacts application, the Web server uses digital certificates as the authentication method. The system authenticates employees with valid certificates, and provides them with the appropriate access based on their credentials in the directory.

Figure 4.1. The solution concept of the Contoso B2E extranet access scenario

Solution Prerequisites

The B2E solution in this paper requires you to install and configure the following:

• An extranet Microsoft® Active Directory directory service forest containing employee shadow accounts.
• The forest functional level set to Microsoft Windows Server™ 2003.
• A public key infrastructure (PKI) established in the organization's intranet.
• Employee laptops and workstations on the internal network must have a valid X.509 certificate provided by the PKI infrastructure, as shown in the following figure.
• The extranet Active Directory employee shadow accounts must be mapped to the employee certificates.

The "Identity Aggregation and Synchronization" paper in this series explains how to maintain the certificate mapped shadow accounts automatically through Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1), and the "Platform and Infrastructure" paper in this series creates shadow accounts in the extranet Active Directory with the user certificates mapped. Either approach is acceptable.

Figure 4.2. Certificate auto-enrollment

Mobile employees receive client certificates via certificate services and auto-enrollment as show in Figure 4.2. Auto-enrollment policy is defined in Active Directory Group Policy, which indicates to workstations during logon that they must contact the issuing certificate authority (CA) to receive an SSL client certificate.

Solution Architecture

The following figure shows the logical design of the Contoso B2E extranet access solution:

Figure 4.3. The logical design of the Contoso B2E extranet access solution

The solution architecture of the B2E Sales and Contacts application has the following characteristics:

• Only members of the Sales group in Active Directory with workstations that have valid user certificates installed can access the Sales and Contacts application.
• The Web server supports Hypertext Transfer Protocol Secure (HTTPS) services with appropriate Secure Sockets Layer (SSL) libraries to validate client certificates.
• Employees access the Sales and Contacts application using HTTPS and client certificate mapping will authenticate them.

Figure 4.4 shows the network design for the Contoso B2E extranet access solution:

Figure 4.4. The network design of the Contoso B2E extranet access scenario

How the Solution Works

This section details how the B2E extranet access solution works after it has been implemented and validated as described in Chapter 5, "Implementing the Solution," and Chapter 6, "Testing the Solution."

Accounts

Along with their intranet Active Directory account, "shadow" accounts are also set up for sales employees in the extranet Active Directory forest. The extranet shadow accounts map to digital certificates that are installed on the employees' computers.

Credentials

Digital certificates are automatically issued to each employee through Microsoft Windows Server™ 2003 Certificate Services auto-enrollment policy when they first log on to the organization's domain. They are stored on each employee's desktop computer so that they are only accessible by the employee while they are logged on to the computer.

Authentication

When employees access the Sales and Contacts application through the Internet using HTTPS, the workstation uses their issued X.509 client certificate to authenticate. If the workstation fails to provide a valid certificate, the user is denied access to the Sales and Contacts application. If the workstation provides a valid certificate, the Web server maps the credentials in the digital certificate to an account in the extranet directory.

Microsoft Internet Information Services (IIS 6.0) maps the user's identity contained in the user principal name (UPN) value of the subject alternate name attribute in the certificate to the external Active Directory account, which IIS then impersonates for authorization.

Authorization

The IIS 6.0 virtual directory that contains the Sales and Contacts application is configured to use Windows Authorization Manager for authorization. IIS requests authorization to the application from Authorization Manager by providing the user's identity and the application (scope) that is being accessed.

Authorization Manager determines whether the user has a role that is allowed to access the application. In this case, the role is derived from membership in the Sales group, which is maintained in Active Directory. Authorization Manager passes the result of the access check back to IIS 6.0, which will then grant or deny access to the application.

A core component of the logical design for this scenario is Authorization Manager, which is used to provide Uniform Resource Locator (URL) authorization. The key components of Authorization Manager are a policy store in the external Active Directory and an Internet Server Application Programming Interface (ISAPI) filter in IIS 6.0 that invokes the Authorization Manager APIs to determine access.

Contoso modified the IIS 6.0 metabase to indicate which resources — represented by a URL in the scenario — are protected by Authorization Manager.

The policy store in Active Directory contains the authorization policies, which consist of application groups, roles, and tasks. Application groups can contain Active Directory users based on membership in organizational units (OU), groups, or Lightweight Directory Application Protocol (LDAP) 3.0 queries based on user attributes. Role definitions include permissions that apply to sets of objects associated with users assigned to their roles. Tasks define what users can do in the B2E application, for example, "Access URL."

Trust

Contoso created and configured the instance of Active Directory in the perimeter network as a separate forest from the internal directory, with no trust configured between the intranet and extranet forests, to achieve the greatest degree of isolation between the intranet and extranet networks, and to simplify the port configuration of the firewall that separates the networks.

The extranet Active Directory is used to authenticate any user accessing an extranet-based application, including employees authenticating from the Internet. This directory can be synchronized with the internal directory by using MIIS 2003 with SP1. For more information, see the "Identity Aggregation and Synchronization" paper in this series.

Extending the Solution

Contoso plans to fully automate the creation and synchronization of shadow accounts for employees in the extranet directory through a system built on Microsoft Identity Integration Server 2003, Enterprise Edition. For more information, see the "Identity Aggregation and Synchronization" paper in this series.

Business to Consumer Extranet Access

The business to consumer (B2C) extranet access scenario describes a possible solution for implementing a secure, scalable Web SSO infrastructure for customers in the Contoso extranet. The uses for Microsoft Passport and Microsoft Authorization Manager are highlighted in this scenario. The scenario addresses requirements for Web SSO self-registration and security challenges faced by organizations with B2C initiatives.

Solution Concept

This solution centers on using Windows Server 2003 to provide authentication and authorization services for applications in a B2C environment through Microsoft Passport and Microsoft Authorization Manager.

Solution Prerequisites

Contoso has the following technologies in their environment to enable this scenario:

• An extranet Active Directory forest.
• The forest functional level set to Windows Server 2003.
• A PKI infrastructure established in the organization's intranet.

Solution Architecture

Figure 4.5 shows the logical design for the Contoso B2C extranet access solution.

Figure 4.5. The logical design of the Contoso B2C extranet access scenario

The capabilities of the B2C Customer Trial feedback application for the Contoso extranet access scenario include the following:

• Microsoft Passport is used for customer authentication.
• Each customer's Passport identity will be mapped to an account in the external Active Directory.
• Users only access the Passport-enabled pages of the Customer Trial feedback application through HTTPS.
• The Customer Trial feedback application will only be available to users who are members of the Trial Users group.
• The self-registration process for the Customer Trial feedback application provisions users.

For security reasons, Contoso created and configured the instance of Active Directory in the perimeter network as a separate forest from the internal directory. This external Active Directory authenticates and stores entitlements for all users of the organization's extranet applications. The following figure shows the network design for the Contoso B2C extranet access solution.

Figure 4.6. The network design of the Contoso B2C extranet access scenario

Contoso uses two servers running Windows Server 2003 to implement the B2C solution for this scenario. To centralize its user identity store, Contoso uses the same external Active Directory account to store customer accounts and employee accounts.

How the Solution Works

This section details how the B2C extranet access solution works for Contoso, after completing the implementation and validation activities in Chapter 5, "Implementing the Solution," and Chapter 6, "Testing the Solution."

Accounts and Authentication

When customers access the Customer Trial feedback application, they are prompted to provide valid Passport account information. They can use pre-existing Passport accounts to authenticate with the system. For customers who do not have a Passport account, they must click a hyperlink to launch a self-registration wizard to create an account through the Passport graphical user interface (GUI).

After a user authenticates through Passport, IIS 6.0 maps the user's Passport identity to the external Active Directory account, which IIS 6.0 impersonates for authorization purposes.

Authorization

The IIS 6.0 virtual directory that contains the Contoso Customer Trial feedback application is configured to use Authorization Manager. IIS 6.0 requests authorization to the application from Authorization Manager by providing the user's identity (obtained through the IIS impersonation mechanism) and the application (scope) that is being accessed.

Authorization Manager determines whether the user has a role that is allowed to access the application. In this case, the role is derived from membership in the Trial Users group, which is maintained in Active Directory. Authorization Manager passes the result of the access check back to IIS 6.0, which will then grant or deny access to the application.

Contoso modified the IIS 6.0 metabase to indicate which resources — represented by an URL in the scenario — are protected by Authorization Manager.

Chapter 5: Implementing the Solution

The previous chapters in this paper provide you with information about the typical issues, requirements, and the solution designs that address the extranet access solution scenarios for business to employee (B2E) and business to consumer (B2C). This chapter provides prescriptive guidance on how to implement these solutions, and introduces the tools and templates provided for each scenario.

The prerequisites and implementation guidance in this chapter can be verified by following the guidance in Chapter 6, "Testing the Solution."

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. 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.

When you run the installer file, the resulting folder structure will look similar to the one shown in Figure 5.1, depending on where you install it.

Figure 5.1. The Tools and Templates folder structure

This guide assumes that you have installed the Tools and Templates into the default location of %UserProfile%\My Documents\Identity and Access Management Tools and Templates. If you use a different installation location, ensure that you use the same path in all the steps in this document.

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

Folder: B2E Extranet Access Example

Table 5.1. The B2E Extranet Access Example Folder

Folder: B2C Extranet Access Example

Table 5.2. The B2C Extranet Access Example Folder

Business to Employee Extranet Access

Implementing the Contoso B2E solution for the Sales and Contacts application primarily requires configuring components already installed with Microsoft® Windows Server™ 2003. To implement its solution, Contoso will use the server's existing digital certificate infrastructure for authentication and Authorization Manager in Windows Server 2003 for authorization. Finally, the Contoso solution requires some minor modifications to the Sales and Contacts application.

Implementation Prerequisites

For these implementation details to work correctly, you need to first implement basic Contoso infrastructure as introduced in the "Platform and Infrastructure" paper in this series, and as described in Chapter 4, "Designing the Infrastructure," and Chapter 5 "Implementing the Infrastructure." In particular, this implementation requires the following prerequisites:

• An intranet Active Directory forest. It should contain the provided Contoso OUs, Groups, and Users.
• An extranet Active Directory forest. It should contain the provided Contoso OUs, Groups, and Users.
• A three-tier public key infrastructure (PKI)/certificate services infrastructure.

The extranet server running IIS needs to be configured according to the information in the following Microsoft Knowledge Base articles:

• To configure SSL and install a Web server certificate, see:
  • "Installing a New Certificate with Certificate Wizard for Use in SSL/TLS".
  • "How To Set Up an HTTPS Service in IIS".
• To configure IIS for Worker Process Isolation Mode, see the information about Determining Application Compatibility with Worker Process Isolation Mode.

Implementation Overview

The high-level tasks that will be performed in order to implement this scenario are:

• Establishing user certificate auto-enrollment.
• Configuring authentication using X.509 certificates and Active Directory.
• Configuring Authorization Manager.
• Configuring Authorization Manager for the Sales and Contacts application.
• Configuring the Sales and Contacts application to use Authorization Manager

Establishing User Certificate Auto-Enrollment

In addition to installing the appropriate certification authorities (CA), Contoso has also enabled user certificate auto-enrollment policy (a new feature in Windows Server 2003) in Active Directory to further improve the manageability of the solution. The steps needed to enable certificate auto-enrollment are documented in the product help documentation.

To enable client certificate auto-enrollment in the NA domain Active Directory, use the following steps in the product documentation

1. Click Start, and then click Help and Support.
2. Click Security, click Public Key Infrastructure, and then click Certificate Services.
3. Click Checklist: Configuring certificate auto-enrollment.
4. Follow the checklist items ending with Certificate Services example implementation: Establishing auto-enrollment for user certificates.

Contoso modified the default user template using the following steps:

To create the Contoso user authentication certificate template

1. Log on to your Intranet Issuing CA with administrative privileges and then open the certificate template MMC by clicking Start, Run, and then type certtmpl.msc and press ENTER.
2. Create a duplicate of the User template, and name the new template by clicking the General tab and then type Contoso-User in the Template display name field.
3. Click the Subject Name tab, click Build from Active Directory Information, and then under Subject name format select Fully distinguished name.

Ensure that Email name and User principal name (UPN) are selected under Include this information in subject alternate name.

1. Click the Extensions tab and then ensure that only Client Authentication (OID 1.3.6.1.5.5.7.3.2) is included in Application Policies.
2. Click the Security tab, click Add, type Domain Users and click OK, and then select the permissions for Read, Enroll, and Auto enroll, and click OK.
3. Open the Certificate Authority Microsoft Management Console (MMC) snap-in, right-click the Certificate Templates folder, click New, click Certificate Template to Issue, and then select the Contoso - User template.

Configuring Authentication Using X.509 Certificates and Active Directory

To map client certificates to corresponding Active Directory users using Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1) for this scenario, see the "Identity Aggregation and Synchronization" paper in this series. Alternatively, the infrastructure setup activities in the "Platform and Infrastructure" paper creates employee shadow accounts in the extranet Active Directory with the client certificate mapping in place.

Establishing Certificate Authority Trust in IIS 6.0

Due to a security feature in Microsoft IIS 6.0, you must install the root certification authority (CA) certificates in the local computer's Trusted Root Certification Authorities certificate store. You also must install all intermediate certification authority certificates in the user certificate chain in the local computer's Intermediate Certification Authorities certificate store.

IIS 6.0 verifies certificates based on the rules specified in the crypto application programming interface (API). The crypto API rejects certificates if the root CA and intermediate CA certificates are not installed in the local computer's Trusted Root Certification Authorities and Intermediate Certification Authorities certificate stores, respectively.

Contoso obtained the root CA and intermediate CA certificates from certificates issued to Contoso users. The following tasks were performed on the root CA and the intermediate CA in the Contoso environment so an administrator can obtain the CA certificate.

Configuration Overview

Contoso used the following tasks to establish Certificate Authority Trust in IIS 6.0. You can tailor these tasks to meet the requirements of your organization.

• Task 1: Export a CA certificate
• Task 2: Import the Certificate to the Local Computer's Trusted Root Certification Authorities Certificate Store
• Task 3: Import the Certificate to the Local Computer's Intermediate Certification Authorities Certificate Store

Task 1: Export a CA Certificate

Complete the following steps to export a certificate from the CA server.

To export a CA certificate

1. Click Start, Run, and then at the Open prompt type mmc and click OK.
2. On the File menu, click Add/Remove Snap-in, and then click Add.
3. From the Snap-in list, double-click Certificates, select Computer account, and then click Next.
4. Select Local computer, click Finish, and then Close and OK to exit the wizard.
5. Double-click Certificates (local computer), double-click Personal, and then click Certificates.
6. Right-click the CA certificate, click All Tasks, and then click Export to open the Certificate Export Wizard.
7. Click Next on the wizard welcome page and then on the Export Private Key page click Next.
8. On the Export File Format page, ensure that the DER encoded binary X.509 (.CER) format option is selected, and then click Next.
9. On the File to Export page, type C:\rca.cer and click Next, review the information presented, and then click Finish.

Note   A confirmation message will appear saying the certificate export was successful.

Task 2: Import the Certificate to the Local Computer's Trusted Root Certification Authorities Certificate Store

Complete the following steps to install the root CA certificate on the server running IIS that hosts the Sales and Contacts application for Contoso.

To import the certificate to the local computer's Trusted Root Certification Authorities certificate store

1. Click Start, Run, and then at the Open prompt type mmc and click OK.
2. On the File menu, click Add/Remove Snap-in, and then click Add.
3. From the Snap-in list, double-click Certificates, select Computer account, and then click Next.
4. Select Local computer, click Finish, and then click Close and OK to exit the wizard.
5. Double-click Trusted Root Certification Authorities, right-click Certificates, and then click All Tasks and Import to start the Certificate Import Wizard.
6. On the wizard welcome page, click Next and Browse to select the exported certificate you created in the previous procedure, and then click Open.
7. Click Next, and then on the certificate store page of the wizard verify that the Place all certificates in the following store check box is selected, and also that the Certificate Store box lists the Trusted Root Certification Authorities.
8. Click Next, and then Finish to exit the wizard.

Task 3: Import the Certificate to the Local Computer's Intermediate Certification Authorities Certificate Store

Complete the following steps to install the intermediate CA certificates on the server running IIS that hosts the Sales and Contacts application for Contoso.

To import the certificate to the local computer's Intermediate Certification Authorities certificate store

1. Click Start, Run, and then at the Open prompt type mmc and click OK.
2. On the File menu, click Add/Remove Snap-in, and then click Add.
3. From the Snap-in list, double-click Certificates, select Computer account, and then click Next.
4. Select Local computer, click Finish, Close, and then click OK to exit the wizard.
5. Double-click Intermediate Certification Authorities, right-click Certificates, click All Tasks, and then click Import to start the Certificate Import Wizard.
6. On the wizard welcome page click Next, Browse to select the exported certificate you created in the previous procedure, and click Open.
7. Click Next, and on the certificate store page of the wizard, verify that the Place all certificates in the following store check box is selected, and also that the Certificate Store box lists the Intermediate Certification Authorities.
8. Click Next, and then Finish to exit the wizard.

Enabling Active Directory Mapper in IIS 6.0

Contoso wants to use its existing Active Directory and digital certificate infrastructure to map user certificates to corresponding user accounts in Active Directory for authentication to the Sales and Contacts application. To do this, Contoso must first configure Active Directory Mapper.

Configuration Overview

Contoso used the following tasks to enable Active Directory mapping in IIS 6.0. You can tailor these tasks to meet the requirements of your organization.

• Task 1: Enable Active Directory Mapper in the Web Server Hosting the Sales and Contacts Application
• Task 2: Enable Client Certificate Mapping in the Sales and Contacts Application
• Task 3: Verify That Client Certificates Map to Corresponding Users in Active Directory

Task 1: Enable Active Directory Mapper in the Web Server Hosting the Sales and Contacts Application

Complete the following steps to enable Active Directory Mapper in IIS 6.0.

To enable Active Directory Mapper in the Web server hosting the Sales and Contacts application

1. Open IIS Manager, and expand local computer in the console tree.
2. Right-click Web Sites, click Properties, and then click the Directory Security tab.
3. Select the Enable the Windows directory service mapper check box, and then click OK to complete this procedure.

Task 2: Enable Client Certificate Mapping in the Sales and Contacts Application

In addition to enabling Active Directory Mapper in IIS 6.0, you must also ensure that the option for client certificate mapping is enabled in your B2E application. Contoso completed the following steps to verify this in the Sales and Contacts application.To enable client certificate mapping in the Sales and Contacts application

1. Open IIS Manager, right-click the virtual directory of the Sales and Contacts application, and then click Properties.
2. Click the Directory Security tab and then in the Secure communications area click Edit.
3. In the Client certificates area, click Require client certificates, and then verify that the Enable client certificate mapping check box is selected. If it is not, select it.

Task 3: Verify That Client Certificates Map to Corresponding Users in Active Directory

The next task requires mapping the client certificate to the corresponding extranet Active Directory user. You can either do this manually or automate the task using MIIS 2003 with SP1. Contoso used MIIS 2003 with SP1 for its new hire process (see the "Identity Aggregation and Synchronization" paper in this series for details on this process), which automatically maps certificates to the company's employees.

To verify that client certificates map to corresponding users in Active Directory

1. Log on to the extranet Active Directory as an administrator, open Active Directory Users and Computers, and right-click the Contoso domain.
2. Click View and then Advanced Features.
3. Click the Accounts organizational unit (OU), and then the Employees OU where the sales user account resides.
4. Right-click the user account you wish to map and then click Name Mapping.
5. Click the X-509 Certificates tab and then ensure in this tab area that the certificate mapping is defined.
6. Click the certificate for the user account and then click Edit.
7. Identify the certificate properties, including its attributes and values and then ensure that the Use Subject for alternative security identity check box is selected.
8. Log on to the Contoso domain using the sales user account on a client computer.
9. Click the Start menu, click Run, and then at the Open prompt type certmgr.msc and click OK.
10. In Certificate Manager, click Personal Folder, then Certificates, and then double-click the certificate that the CA issued during logon.
11. Click the Details tab, and then Field Subject.
12. Ensure that the attributes and values in the Subject field match the information identified in Task 6 of the following "Configuring Authorization Manager" section.

Note   For instructions on manually mapping certificates to Active Directory accounts, see the Knowledge Base Article 272175, "HOW TO: Configure Active Directory Certificate Mapping".

Configuring Authorization Manager

In Windows Server 2003, Authorization Manager introduces a new model for application authorization. Authorization Manager provides an easy-to-use authorization framework for line-of-business (LOB) applications that you can use to provide access for users according to their role in your organization or application. Configuring Authorization Manager to work properly requires you to complete the following series of tasks in the order that they are presented here.

Configuration Overview

Contoso used the following tasks to configure Authorization Manager. You can tailor these tasks to meet the requirements of your organization.

• Task 1: Create the Sales Administrator Active Directory Account
• Task 2: Create the Program Data OU and Delegate Control
• Task 3: Create the Authorization Policy Store in Active Directory
• Task 4: Create the IIS 6.0 URL Authorization Application
• Task 5: Create an Operation
• Task 6: Create a Role Definition for Sales and Contacts Application Users

Task 1: Create the Sales Administrator Active Directory Account

The Sales Administrator user in Active Directory is responsible for configuring authorization policy in Authorization Manager and enabling Authorization Manager while logged on to the Web server.

To create a user account in Active Directory for Authorization Manager

1. Log on to the external Active Directory domain controller using an administrator account to create users and delegate administration of containers and OUs.
2. Open the Active Directory Users and Computers MMC snap-in.
3. Create a "Sales Admin" user under the Internal OU with the following information:

First name: Sales Admin

Full name: Sales Admin

User logon name: salesadmin@perimeter.contoso.com

1. Navigate to the Web server running IIS that hosts the Sales and Contacts application, and open the Computer Management MMC snap-in.
2. Open Local Users and Groups and then click Groups.
3. Right-click the IIS_WPG group and then click Add to Group.
4. Click Add, and then in the Enter the object names to Select box, type salesadmin and click OK twice to complete this procedure.

Task 2: Create the Program Data OU and Delegate Control

Authorization Manager requires a "container" to hold its policy information. There are two choices for storing this information: in an Active Directory container, or in an Extensible Markup Language (XML) file. Because Contoso plans to use Active Directory as the company's centrally accessible authorization store, the company chose to create an Authorization Manager policy storage container in Active Directory.

Note   The Active Directory Service Interfaces (ADSI) Edit snap-in does not install in Windows Server 2003 by default. If this snap-in is not installed on your server, you must install the ADMINPAK.msi file for the Windows Server 2003 Administration Pack located on your installation CD.

For detailed instructions on installing the administration pack, download the Windows Server 2003 Administration Tools Pack.

To create an Authorization Manager policy storage container in Active Directory

1. Log on to the external Active Directory using an account with administrative privileges to create containers.
2. Click Start, click Run, and then at the Open prompt, type adsiedit.msc and click OK.
3. Click Domain [perimeter.contoso.com],DC=perimeter,DN=contoso,DN=com, and then right-click Program Data.
4. Click New, and then Object.
5. Under Select a class, click container, and then click Next.
6. Click Create Object, type Contoso and click Next, and then click Finish.
7. Open Active Directory Users and Computers.
8. Open the Program Data folder, right-click the Contoso folder, and then click Delegate Control.

Note   If you cannot view this folder, click View, and then Advanced Features from the main menu.

1. After the Delegation of Control wizard launches, click Next.
2. Click Add, type salesadmin and click OK, and then click Next.

Figure 5.2. The Tasks to Delegate page in the Delegation of Control Wizard

1. Select all of the tasks in Delegate the following common tasks area and then click Next.
2. Right-click the Contoso folder, click Properties, the Security tab, and then click Add.
3. In the dialog box under the Enter the object name to select area, type salesadmin and click OK, and then in the Permissions for Sales Admin box under Allow select the checkbox for Full Control.

Figure 5.3. The assigned permissions for the Sales Admin group on the Security tab for Contoso properties

Task 3: Create the Authorization Policy Store in Active Directory

Because Contoso is using Active Directory as its central authorization store, the company chose to create its Authorization Manager store in Active Directory. An authorization store is a database that contains the authorization policy in Authorization Manager.

To create the authorization policy store in Active Directory

1. Log on to the Web server host machine as <domainname>/salesadmin.
2. Click Start, click Run, and than at the Open prompt, type azman.msc and click OK to open Authorization Manager.
3. Right-click Authorization Manager, click Option, and then Developer mode.
4. Right-click Authorization Manager, and then click New Authorization Store.
5. Click Active Directory to define the authorization store type.

The distinguished name (DN) of the Program Data will appear under Store Name.

1. In the Store name box, type the DN and common name (CN) for your authorization store.

In this scenario, the following were used.

CN=ContosoStore,CN=Contoso,CN=Program Data,DC=perimeter,DC=contoso,DC=com.

Figure 5.4. Using the New Authorization Store dialog box to create a new authorization store in Active Directory

Task 4: Create IIS 6.0 URL Authorization Application

IIS 6.0 integrates with Authorization Manager to implement IIS 6.0 URL Authorization, a new feature in Windows Server 2003. Creating an Authorization Manager "application" is the first step in using Authorization Manager to protect your Web-based application. An Authorization Manager application identifies the operations or tasks that the application can perform by declaring them in the authorization store at the time you install the application.

Contoso is protecting Web-based applications on the Web server running IIS. For this reason, the company needs to create and define a specific IIS Authorization Manager application name to hold all IIS – based resources that Authorization Manager will protect.

To create an application name in IIS 6.0

1. Log on to your Web server as <domainname>/salesadmin.
2. Open Authorization Manager, right-click ContosoStore, and then click New Application.
3. In the Name box, type IIS 6.0 URL Authorization (Filling out the Description and Version text boxes is optional.)

   Note   You must type IIS 6.0 URL Authorization exactly as shown in the following figure in the Name box of the New Application dialog box or Authorization Manager will not operate with IIS 6.0.

Figure 5.5. Using the New Application dialog box to create a new application

Task 5: Create an Operation

An operation is a low-level permission that a resource manager uses to identify security procedures. A meaningful task may require several operations. Operations are often not exposed or meaningful to administrators. An example of an operation could be WriteAttributes or ReadAttributes. Contoso created an operation definition to allow access to the Sales and Contacts application URL for its sales employees. This operation definition links to an IIS directory (or virtual directory) when the Microsoft Visual Basic® script for SetUrlAuth is run later in this chapter.

To create an operation

1. Open Authorization Manager and double-click IIS 6.0 URL Authorization.
2. Double-click Definitions, right-click Operation Definitions, and then click New Operation Definition.
3. In the New Operation Definition area, type AccessURL in the Name box. Then in the Operation number text box, type 1 to indicate URL authorization.

Important   It is critical that you type AccessURL exactly in the Name box and 1 in the Operation number box of the New Operation Definition dialog box as shown in the following figure.

Figure 5.6. Using the New Operation Definition dialog box to create an operation definition

Task 6: Create a Role Definition for Sales and Contacts Application Users

In Authorization Manager, a role definition is a collection of permissions for a particular role. Permissions for the role can be tasks or operations. Because Contoso is using operations to define permissions, that is how the roles in this scenario are configured.

To create a role definition

1. Open Authorization Manager, double-click the IIS 6.0 URL Authorization folder, double-click the Definitions folder, and then right-click Role Definitions and click New Role Definition.
2. In the Name box, type Viewer and then click OK.

Figure 5.7. Using the Role Definition dialog box to create a role definition

1. In the console tree, double-click Role Definitions, and then in the details pane, right-click Viewer, click Properties, click the Definition tab, click Add, and then the Operations tab.
2. Under Select the operation definitions to add, select the AccessURL check box, and then click OK.

Figure 5.8. Using the Add Definition dialog box to define a role

Configuring Authorization Manager for the Sales and Contacts Application

Now you are ready to create an Authorization Manager scope and role assignment for the Sales and Contacts application. Use the following tasks to accomplish this.

• Task 1: Add the Sales Admin User to the Local Administrators Group on the Web Server
• Task 2: Create an Authorization Manager Scope
• Task 3: Create an Authorization Manager Role Assignment

Task 1: Add the Sales Admin User to the Local Administrators Group on the Web Server

In addition to creating the authorization policy store in Active Directory, the Sales Administrator also must configure the server running IIS 6.0. To do this, the Sales Admin user in Active Directory must be a member of the Local Administrators group on the Web server.

To add the Sales Admin user to the Local Administrators Group

1. Log on to the Web server host computer using an account that can add users to the Local Administrators group (for example, as an administrator).
2. Open the Computer Management MMC snap-in and then click Local Users and Groups.
3. Expand the Groups folder, right-click the Administrator group, click Add to group, and then click Add.
4. In the box under the Enter the object name to select area, type salesadmin and then click OK.

Task 2: Create an Authorization Manager Scope

Authorization Manager scopes exist directly under Authorization Manager applications in the Active Directory console tree. A scope allows an administrator to collect similar resources within an authorization policy. These collections map the requested resource to its scope when the application validates an employee's access rights. A scope can represent a physical collection, such as a folder, or a more flexible collection of resources, such as Active Server Pages (ASP). Applications use scope as necessary to group similar resources.

Note   IIS 6.0 URL Authorization scopes always map to virtual directories or URLs to protect Web applications.

To create a scope in Authorization Manager

1. Open Authorization Manager and then double-click ContosoStore.
2. Right-click IIS 6.0 URL Authorization and click New Scope.
3. In the Name: text box, type B2E and click OK.

Figure 5.9. Using the New Scope dialog box to create a new scope

Task 3: Create an Authorization Manager Role Assignment

Creating an Authorization Manager role assignment simply requires linking the role created in Authorization Manager to a subset of users in the external Active Directory.

You can do this in one of two ways:

• Assign Active Directory users to an Authorization Manager role based on Active Directory group membership.
• Create an application group in Authorization Manager and assign users statically or with a Lightweight Directory Access Protocol (LDAP) query. An application group in Authorization Manager is a container that can hold static users, an LDAP query based on user attributes, Active Directory groups, or a combination of the three.

Contoso used the first approach, assigning Active Directory users to an Authorization Manager role based on Active Directory group membership.

To link a role to a group in Active Directory

1. Open Authorization Manager, double-click IIS 6.0 URL Authorization, double-click B2E, right-click Role Assignments, click Assign Roles, and then select Viewer.
2. Right-click Viewer and then click Assign Windows Users and Groups.
3. In the Enter the object names to select (examples) text box, type sales and then click Check Names to ensure the object exists in Active Directory.

Note   A dialog box will prompt you to select the salesadmin account or the Sales group. Ensure that you select the Sales group.

Figure 5.10. Using the Select Users, Computers, or Groups dialog box to create a role assignment

Configuring the Sales and Contacts Application to Use Authorization Manager

After Authorization Manager is configured, the final step is to associate the Sales and Contacts application with it to perform authorization. To complete this task, you need to make some configuration changes to ensure that IIS 6.0 can communicate with Authorization Manager, and that a specific URL (or directory) is associated with the Scope and Operation created in Authorization Manager.

Installation and Configuration Overview

Contoso completed the following tasks to configure the Sales and Contacts application. You can tailor these tasks to the requirements of your organization.

• Task 1: Install the Sales and Contacts Application
• Task 2: Create an Application Pool in IIS Manager for Authorization Manager
• Task 3: Change the Account Under Which an Application Pool Runs
• Task 4: Assign the Application Pool to the Virtual Directory of the B2E Application
• Task 5: Add the IIS Worker Process to the Authorization Manager Store Reader Role
• Task 6: Set the Web Application Configuration Properties to Point to URLAuth.dll
• Task 7: Add URLAUTH.dll as a New Web Service Extension
• Task 8: Install and Run Metabase Explorer to Find the Application URL
• Task 9: Use SetURLAuth.vbs (VBscript) to Assign Policy to the Web Application Virtual Directory

Task 1: Install the Sales and Contacts Application

There is a simple sample Web page that has been included with this document that represents the real Sales and Contacts application in the Contoso environment. This sample application must be installed and configured before completing the remainder of the tasks in this scenario.

To install the sample Sales and Contacts application

1. Create a file system directory on the Web server, typically \Inetpub\wwwroot\SalesApp.
2. Copy the default.asp file from the B2E Extranet Access Example folder of the Tools and Templates for this paper to the directory created in step 1.
3. Open IIS Manager, right-click Default Web Site, point to New, and then click Virtual Directory.
4. In the Virtual Directory Creation Wizard, click Next, type SalesApp in the Alias textbox, and then click Next.
5. Click Browse, and then navigate to the location of the sample files determined in step 1.
6. Click OK, click Next twice, and then click Finish to complete this procedure.

Task 2: Create an Application Pool in IIS Manager for Authorization Manager

An application pool is configured to link one or more applications to a single worker process to isolate the process. Contoso associated an application pool with the virtual directory in which the Sales and Contacts application resides.

For reliability and security purposes, Contoso created an application pool on the IIS server to protect other Web applications. Selecting a security account for the application pool allows administrators to constrain the pool with more permissions control.

To create an application pool

1. Open IIS Manager, expand local computer, right-click Application Pools, point to New, and then click Application Pool.
2. In the Application pool ID box, type SalesAppPool

Figure 5.11. Using the Add New Application Pool dialog box to add a new application pool in IIS 6.0

1. In the Application pool settings area, click the Use default settings for new application pool option.

Task 3: Change the Account Under Which an Application Pool Runs

By default, application pools run under the Network Service account. For security purposes, Microsoft recommends selecting a different security account for the application pool than the one created in this scenario. You can use a domain account to constrain access to a greater degree than use of the Network Service account would allow.

To check your application pool for the user authority under which it runs

1. In IIS Manager, expand Local computer, expand Application Pools, right-click SalesAppPool, and then click Properties.
2. Click the Identity tab, and then click the Configurable option.
3. Click Browse, type salesadmin@contoso.com in the Enter the object names to select box, and then click OK.
4. In the Password box, type the password for the salesadmin account, click OK, re-enter the password to confirm it and then press OK.

Figure 5.12. Using the SalesAppPool Properties dialog box to change the account under which an application pool runs to a different domain security account.

Task 4: Assign the Application Pool to the Virtual Directory of the B2E Application

This procedure simply creates a link between the application pool created in Task 2 and the virtual directory for the Sales and Contacts application created in Task 1. The Contoso Sales and Contacts application runs exclusively under one virtual directory, but you can associate your application pool with more than one if necessary.

To assign an application pool to a virtual directory

1. In IIS Manager, right-click the virtual directory of the Sales and Contacts application, and then click Properties.
2. In the application's Properties dialog box, click the Virtual Directory tab, expand the Application Pool drop-down list, and then select the application pool to assign it to the Web-based application as shown in the following figure.

Note   If the Application Pool list is not available, click Create to create the application pool for the Contoso Sales and Contacts application.

Figure 5.13. Using the contacts Properties dialog box to assign an application pool to the virtual directory for a Web application

Task 5: Add the IIS Worker Process to the Authorization Manager Store Reader Role

As mentioned previously, IIS 6.0 runs under the Network Service account by default. Because you have reconfigured the service account that the application pool runs under, you must use this account for the Authorization Manager Reader role. This ensures that the service account will enforce the appropriate Authorization Policy.

Note   If you use a remote authorization store (such as Active Directory or a remote XML file-based store) and run IIS 6.0 in the default Network Service context, then you must add the Active Directory account of the Web server running IIS 6.0 to the Store Reader role.

To add the IIS Worker Process to the Authorization Manager Store Reader role

1. Open Authorization Manager.
2. In the console tree, right-click Authorization Manager, click Open Authorization Store, click Active Directory, and then click Browse.
3. Click CN=ContosoStore,CN=Contoso,CN=Program Data,DC=perimeter,DC=contoso,DC=com.
4. In the console tree, right-click ContosoStore, and then click Properties.
5. Click the Security tab, expand the Authorization Manager user role drop-down list, select Reader, and then click Add.

Figure 5.14. Using the Contosostore Properties dialog box to add the IIS Worker process to the Authorization Manager Store Reader role

1. Click Object Type, then in the Enter the object names to select box, type salesadmin@perimeter.contoso.com and click OK twice to complete this procedure.

Task 6: Add the Web Application Configuration Properties to Point to URLAuth.dll

When you configure an application, virtual directory, or URL to use IIS 6.0 URL Authorization, each request to a URL is routed to the URL Authorization Internet Server Application Programming Interface (ISAPI) interceptor. The IIS 6.0 URL Authorization ISAPI interceptor uses the Authorization Manager runtime to authorize access to the requested URL. To do this, the URL (application, virtual directory, or single URL) must be associated with an Authorization Manager policy store that contains the authorization policy for the URL. After the client has been authorized to access the URL, the IIS 6.0 URL Authorization ISAPI passes the request to the appropriate handler for the URL, such as ASP or the static file handler.

The name of the file that must execute as the URL Authorization ISAPI interceptor is URLAUTH.dll. You must associate this file with each virtual directory (or directory) that you want associated with Authorization Manager.

To associate the URLAuth.dll file with the Sales and Contacts application

1. In IIS Manager, right-click the virtual directory that contains the Sales and Contacts application, click Properties, and then click Configuration.
2. In the Wildcard application maps (order of implementation) area, click Insert.
3. Under Add/Edit Application Extension Mapping, click Browse, and then in the Files of type list select All files (*.*).
4. Browse to the %Systemroot%\System32\InetSrv folder, click URLAuth.dll, then Open, and then click OK three times to complete this procedure.

Note   If an error message appears that begins "This executable path is already used…" the URLAuth.dll file is already configured as a wildcard for application extension mapping.

Figure 5.15. Using the Application Configuration dialog box to set the Web application configuration properties to point to URLAuth.dll

Task 7: Add URLAuth.dll as a New Web Service Extension

You must allow the server running IIS to execute the Web service extension for URL authorization. This is required to use Authorization Manager for URL authorization.

To configure IIS to add URLAuth.dll as a new Web service extension

1. Open IIS Manager, expand Local computer in the console tree, and then right-click Web Service Extensions.
2. Click Add a new Web service extension.
3. Click Add, click Browse, and then navigate to the %Systemroot%\System32\InetSrv\ folder.
4. Click URLAUTH.dll, click Open, and then click OK.
5. In the Extension Name text box, type URL Authorization
6. Select the Set extension status to Allowed check box, and then click OK.

Task 8: Install and Run Metabase Explorer to Find the Application URL

The IIS 6.0 metabase is a database similar in structure to the Microsoft Windows® registry. The metabase is optimized for IIS to provide a hierarchal storage system and fast retrieval of IIS configuration properties for Web sites, virtual directories, and sites configured to use File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), and Network News Transfer Protocol (NNTP).

Each virtual directory is assigned a unique identifier. You can find this information easily using the Metabase Explorer utility. Use this utility when running the SetUrlAuth.vbs script in the following procedure.

To install and use Metabase Explorer

1. Install the Metabase Explorer utility that is supplied with the Internet Information Services (IIS) 6.0 Resource Kit Tools.
2. Click Start, All Programs, IIS Resources, Metabase Explorer, and then click Metabase Explorer.
3. Double-click LM, and then double-click W3SVC.
4. To find out the identifier that corresponds to your Web site, click the number located directly under W3SVC once in the folder tree, and then check the Data value of the ServerComments attribute in the right column.

The value should match the name of your Web site.

1. Locate the virtual directory path of the B2E application. For example, W3SVC/535085964/root/contacts.

Note   The virtual directory path will be used when you execute the SetUrlAuth.vbs script in Task 9.

Figure 5.16. The contact list view in IIS Metabase Explorer

Task 9: Use SetURLAuth.vbs (VBscript) to Assign Policy to the Web Application Virtual Directory

Contoso uses a Visual Basic script file to modify IIS metabase properties, which assign the appropriate Authorization Manager policy to the virtual directory. A sample script called SetURLAuth.vbs is included in the Tools and Templates folder that downloads with this paper. Complete the following steps to run the SetUrlAuth.vbs script.

To run the SetURLAuth.vbs script

1. Log on to your Web server running IIS 6.0 as <domain>/salesadmin.
2. Click Start, click Run, and then at the Open prompt, type cmd and press ENTER.
3. Copy the SetUrlAuth.vbs file to the \InetPub\AdminScripts directory.

Note   By default, the InetPub directory is in the root of the drive containing IIS 6.0.

1. At the command prompt, type the following:

   CScript SetUrlAuth.vbs <your virtual directory> B2E

   "msldap://CN=ContosoStore,CN=Contoso,CN=Program

   Data,DC=perimeter,DC=contoso,DC=com" true 1

2. Press ENTER.

IIS URL Authorization is now configured to run for the Sales and Contacts application in this scenario. Users assigned to the Viewer role can browse to pages within the application.

Note   The syntax for the SetUrlAuth.vbs file script is:

CScript SetUrlAuth.vbs <VirtualDirPath> <AuthMgrScopeName> <AuthMgrStoreName> <Enabled True/False> <ImpersonationLevel>

Business To Customer Extranet Access

Implementing the B2C extranet access solution for the Contoso Customer Trial application primarily requires configuring components previously installed with Windows Server 2003. As part of the implementation process for its solution, Contoso used infrastructure from Microsoft Passport for the authentication process, and Authorization Manager for the authorization process. Finally, the B2C solution for Contoso requires some minor modifications to the Customer Trial application.

Implementation Prerequisites

For these implementation details to work correctly, you need to have the basic Contoso infrastructure implemented as introduced in the "Platform and Infrastructure" paper in this series as described in Chapter 4, "Designing the Infrastructure," and Chapter 5, "Implementing the Infrastructure."

In particular, an extranet Active Directory forest is required. The forest should contain the provided Contoso OUs, Groups, and Users.

You also need to have access to the Microsoft Passport Web site.

Implementation Overview

The implementation activities for this solution scenario include the following:

• Configuring Passport integration with Active Directory and Authorization Manager.
• Configuring the Customer Trial application to use Authorization Manager.

Configuring Passport Integration with Active Directory and Authorization Manager

With Windows Server 2003 and IIS 6.0, you can integrate Passport authentication services into your solution to store user credentials in Active Directory. Contoso did this to offer users single sign on (SSO) features across multiple Passport-enabled Web sites.

Passport Integration with Active Directory Overview

You can tailor the following tasks in this section to the requirements of your organization. Contoso completed these tasks to integrate Passport with the B2C extranet access solution.

• Task 1: Verify the Current Installation Environment
• Task 2: Register Your Passport Site
• Task 3: Obtain a Passport Site ID and Encryption Key
• Task 4: Configure the Proper Site ID for Your Passport Implementation
• Task 5: Verify the Proper Site ID for Your Passport Implementation
• Task 6: Create a Trial Administrator Account and Trial User Group in Active Directory
• Task 7: Delegate Control of the Trial Users OU to the Customer Trial Application Administrator
• Task 8: Create the Program Data OU and Delegate Control
• Task 9: Add the Trial Administrator User to the Local Administrators Group on a Web Server
• Task 10: Enable Active Server Pages and ASP.NET in IIS 6.0
• Task 11: Enable Passport in IIS 6.0 for Mapping with Active Directory
• Task 12: Add the Trial Administrator to the Authorization Manager Policy.
• Task 13: Create an Authorization Manager Scope
• Task 14: Create an Authorization Manager Role Assignment

Task 1: Verify the Current Installation Environment

Verify that the following three environments exist while setting up Passport authentication for IIS 6.0:

• The default installation environment
• The preproduction (PREP) environment
• The production environment.

Use the following steps to verify that you are in the default installation environment.

To verify your server is in the default installation environment

1. Log on to the perimeter Web server using an account with administrative privileges.
2. Click Start, click Run, and then at the Open prompt, type msppcnfg and click OK to make the Passport Manager Administration utility open.
3. In the Passport Manager Administration utility, verify that the value in the Site ID field is 1.

Note   The value 1 indicates that the current Passport configuration is in the default installation environment. Any number other than 1 indicates that the current environment is in either the PREP environment or the production environment.

Task 2: Register Your Microsoft Passport Site

Before you can test and deploy Passport authentication on your site, you must register your server configuration and request a site ID and encryption key from Microsoft. After obtaining a site ID and encryption key, you can switch your environment to the PREP environment to test it against your preproduction servers without accessing live Passport services.

To request a Microsoft Passport site ID

1. Go to the Microsoft Services Manager Web Site.
2. Log in to your Passport account.
3. Click the Application tab, and then click the Create Application link.
4. Type a name into the Preproduction Application box, and then click Submit.
5. Click the Add Service link, select .NET Passport, and then click Next.
6. On the General .NET Passport Information page, complete the required fields using information similar to the following:

Web Site Title: Contoso Pharmaceuticals

Domain Name: www.contoso.com

Default Return URL: www.contoso.com/defaultreturn.html

Customer Support Phone number: <Optional field>

Customer Support email: <Optional field>

Privacy Policy URL: www.contoso.com/privacy.html

Note   This information provides examples of data you could type in the application at this point in the application process. The information you supply will be unique to your implementation of .NET Passport.

1. Click Next.
2. On the Cobranding Information page, complete the required field as follows:

Cobrand Image URL*: www.contoso.com/logo.gif

Other fields on this page are optional for you to complete according to your requirements.

1. On the Other .NET Passport Information page, complete the fields according to your requirements, and then click Next.
2. On the .NET Passport Single Sign-In Information page, complete the required field using information similar to the following:

Expire Cookie URL*: www.contoso.com/clearcookies.asp.

1. Complete the other optional fields on the page according to your requirements, and then click Submit.

Task 3: Obtain a Microsoft Passport Site ID and Encryption Key

After Microsoft approves your application, you will receive an e-mail from the Microsoft compliance team containing a site ID and a Passport encryption key for your Web site. Download and install the encryption key to promote your PREP environment.

Note   If IIS 6.0 is running on the same server you are configuring for Passport authentication, disable the IIS admin process before proceeding to the next step.

To install the encryption key and set up the Microsoft Passport site ID

1. Log on to the Microsoft Services Manager Web Site using your Passport account.
2. Click the Application tab, expand the Select an Application list, select your application, and then under Service, select Passport and click Next.
3. Click the Download Key link.
4. Expand the Operating System drop-down list, and then select Windows Server 2003.
5. Expand the Web Server drop-down list, select IIS, and then click Next.
6. After obtaining your encryption key from the e-mail notification, follow the instructions in the e-mail to download the encryption key installation program. The program is an executable file named PartnerXXXX_X.exe, where XXX_X corresponds specifically to your requested site ID.
7. Click Start, click Run, and then at the Open prompt type the following commands and press ENTER after each one:

Partner1000_1.exe /addkey

Partner1000_1.exe /makecurrent /t 0

Note   Site ID 1000_1 is an example. Make the file name specific to your site ID.

After you have installed the encryption key, use the following task to confirm that the site ID is properly set up and verify that your environment has switched to the PREP environment.

Task 4: Configure the Proper Site ID for Your Microsoft Passport Implementation

After you have installed your Passport encryption key, your site will be set up with a unique Passport site ID. It is a best practice to verify that the site ID is properly set up to ensure your server can communicate with the preproduction Passport servers.

To configure the proper setup of the site ID and encryption key

1. Stop IIS Admin Services.
2. Click Start and then click Run.
3. In the Open drop-down list, type msppcnfg to open the Passport Manager Administration utility.
4. In the Passport Manager Administration utility, enter the site ID you received from .NET Services Manager.
5. Click Commit Changes and then click OK.
6. Start IIS Admin Services.

Task 5: Verify the Proper Site ID for Your Passport Implementation

To verify the proper setup of the site ID and encryption key

1. Click Start, click Run, and then in the Open box, type msppcnfg
2. In the Passport Manager Administration utility, verify the site ID you received from .NET Services Manager.

Task 6: Create a Trial Administrator Account and Trial User Group in Active Directory

To create Passport users in Active Directory, Contoso created a domain with privileges to create child objects in the Trial Users OU. The Trial Administrator account serves as the IIS anonymous account to create users in Active Directory.

To create the account in Active Directory

1. Log on to your external Active Directory account with Administrator privileges.
2. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
3. Click the Accounts OU, right-click Trial Users, and then click New and User.
4. In the box for First name, type trial admin; in the box for User Logon Name, type trialadmin, and then click Next.
5. Create a password for this account, click Next, and then Finish.

To create the group in Active Directory and delegate rights

1. Log on to your external Active Directory account with Administrator privileges.
2. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
3. On the View menu, ensure that Advanced Features is selected.
4. Click the Accounts OU, right-click Trial Users, and then click New and Group.
5. In the box for Group name, type trial user, under Group Scope click Domain Local, and then under Group Type click Security, and click OK.
6. Right-click the Trial User group and click Properties.
7. Click the Security tab, and then click the Add button.
8. In the Select Users, Computers, or Groups dialog box, type trialadmin in the Enter the object names to select (examples) box, and then click OK.
9. In the Trial User Properties dialog box, select trialadmin from the Group or user names list, select the option for Full Control under Permissions for trialadmin, and then click OK.

Task 7: Delegate Control of the Trial Users OU to the Trial Customer Application Administrator

For the trialadmin account to create users in the Trial User OU, you must configure the security setting for the Trial Users OU container.

To delegate control of the Trial Users OU

1. Right-click the Trial Users OU, and then click Properties.
2. Click the Security tab, click Add, and then type trialadmin in the Enter the object names to add box and click OK.
3. Assign the Read and Create All Child Objects permissions to the trialadmin account, and then click OK.

Figure 5.17. Assigning security permissions for the Trial Users OU

Task 8: Create the Program Data OU and Delegate Control

In addition to creating users in the Trial Users OU, the Customer Trial administrator is also responsible for managing the authorization policy store in Active Directory.

To delegate control of the Program Data OU to the Customer Trial Application Administrator

1. Open Active Directory Users and Computers.
2. Open the Program Data folder, right-click the Contoso folder, and then click Delegate Control to launch the Delegation of Control Wizard

Note   If you cannot view the Contoso folder, from the main menu click View, and then click Advanced Features.

1. Click Next, click Add, and then type trialadmin
2. Under the Delegate the following common tasks section of the Tasks to Delegate page, select each task individually, click Next, and then Finish.
3. Right-click the Contoso folder, click Properties, the Security tab, and then click Add.
4. In the Enter the object name to select field, type trialadmin and click OK. Then, under Allow, select the option for Full Control.

Task 9: Add the Trial Administrator User to the Local Administrators Group on a Web server

The Trial Administrator also needs to configure the IIS 6.0 server. For this reason, the trialadmin user in Active Directory must be a member of the Local Administrators group on the server running IIS.

To add the Trial Administrator user to the Local Administrators group

1. Log on to the Web server host machine as <domain>/trialadmin.
2. Open Computer Management, and then click Local Users and Groups.
3. Click Group, and then add <domainname>/trialadmin to the Administrators group.

Task 10: Enable Active Server Pages and ASP.NET in IIS 6.0

Active Server Pages (ASP) and ASP.NET are not enabled by default in IIS 6.0. Because you will be using ASP to map Passport accounts with Active Directory, you must allow ASP and ASP.NET to run Web extensions on the IIS 6.0 Server.

To enable ASP and ASP.NET Web Extensions on IIS 6.0

1. Log on to the Web server host machine as <domain>/trialadmin.
2. Open IIS 6.0 Manager, expand local computer, and then click Web Service Extensions.
3. Right-click Active Server Pages, and then click Allow.
4. Right-click ASP.NET v1.1.4322 (or later), and then click Allow.

Task 11: Enable Passport in IIS 6.0 for Mapping with Active Directory

To integrate Passport with Active Directory, you must map the PUID (a unique identifier in a Passport account) to a corresponding account in Active Directory. The ASP files map Passport users in Active Directory using the Active Directory Service Interfaces (ADSI) API.

Note   The default.asp and subscribe.asp files that are included in the Tools and Templates folder are sample ASP files you can use to demonstrate mapping the Passport PUID to Active Directory. You can customize this code based on how you implement Passport.

Table 5.3.ASP for PUID Mapping with Active Directory

To enable mapping Passport users to Active Directory

1. Open IIS 6.0 Manager and create a new virtual directory called trialentry.
2. Copy all of the files and folders to the trialentry directory except the subscribe.asp file.
3. Right-click the trialentry directory, and then click the Properties tab.
4. Click the Directory Security tab, and then under Authentication and access control click Edit.
5. Select the Enable anonymous access check box (if it is not already selected) and then click .NET Passport authentication.

Note   Configuring Passport authentication for a virtual directory disables all other authentication methods for that virtual directory.

1. Enter the domain name perimeter.contoso.com in the Default domain box, and then click OK twice.
2. Create another virtual directory called subscribe.
3. Copy the subscribe.asp file to the subscribe virtual directory.
4. Right-click the subscribe directory, and then click Properties.
5. Click the Directory Security tab, and then under Authentication and access control click Edit.
6. Select the Enable anonymous access check box, and then click .NET Passport authentication.
7. Enter the domain name perimeter.contoso.com in the Default domain box.
8. Configure the account used for anonymous access, type trial admin in the box that appears, and then click OK.
9. At the password prompt, enter the password for the trial admin user, click OK, and then re-enter the password to confirm it.

Note   Make sure you update the hyperlink to the B2C application on the main page so that your company will point to the default.asp file in the trialentry directory. For example, in this scenario for Contoso, the hyperlink would be www.contoso.com/trialentry/default.asp.

To configure Passport authentication on the Customer Trial application

1. Open IIS 6.0 Manager, and then click the virtual directory containing the Customer Trial application.
2. Right-click the Customer Trial application's virtual directory and click Properties.
3. Click the Directory Security tab, and then under Authentication and access control click Edit.
4. Clear the Enable anonymous access check box (if it is selected), and then click Passport authentication.
5. Enter the domain name perimeter.contoso.com in the Default domain box.

Based on the settings of the trialentry directory, the default.asp file challenges the user to authenticate using Passport. After Passport authenticates the user, the default.asp file attempts to map the PUID to Active Directory.

If the PUID is not mapped (that is, the user account is not created in Active Directory), information in the default.asp file is used to offer the user a link to the subscribe.asp file (in the subscribe virtual directory) that displays information the user can use to define a Passport profile. The subscribe.asp file prompts the user for information that Passport requires (for example, e-mail address), and then uses ADSI to create the account in Active Directory.

After the PUID is mapped, IIS creates an impersonation token for the user. IIS will run in the impersonation context of the user, which allows Authorization Manager to authorize user access.

Task 12: Add Trial Administrator to the Authorization Manager Policy

The Trial Administrator account needs to be able to view and modify the ContosoStore Authorization Manager policy, which is accomplished by adding them to the Administrator role.

Note   This B2C solution scenario requires an Authorization Manager store and policy. If you have not already completed the previous B2E solution scenario or do not have an Authorization Manager policy in place, follow the instructions for Configuring Authorization Manager in the above B2E solution scenario, replacing the SalesAdmin account with TrialAdmin before completing this task.

To add the Trial Administrator account to the Administrator role

1. Log on to the Web server with Sales Admin credentials and open Authorization Manager.
2. In the console tree, right-click Authorization Manager, click Open Authorization Store, click Active Directory, and then Browse.
3. Click CN=ContosoStore,CN=Contoso,CN=Program Data,DC=perimeter,DC=contoso,DC=com.
4. In the console tree, right-click ContosoStore and then click Properties.
5. Click the Security tab, expand the Authorization Manager user role drop-down list, select Administrator, and then click Add.
6. Click Object Type, and in the Enter the object names to select box, type trialadmin@perimeter.contoso.com and then click OK twice.
7. Log off from the Web server.

Task 13: Create an Authorization Manager Scope

Previously in this chapter you created an authorization store in Active Directory, the IIS 6.0 URL Authorization Application, and an operation definition based on the B2E scenario. After installing and configuring the components for the B2E scenario, the remaining tasks to complete the solution configuration for the B2C scenario are as follows:

• Create a new scope.
• Define a role assignment.
• Modify the security settings for ContosoStore with an administrative account on that store in Authorization Manager to set the Trial Admin permissions on ContosoStore.

Complete the following steps to create a new scope for the B2C extranet access scenario.

To create a new scope

1. Log on to your Web server as <domain>/trialadmin.
2. Open the Authorization Manager MMC snap-in, and then double-click Authorization Manager.
3. Select the Active Directory option and then click the ContosoStore URL.
4. Under Authorization Manager, you will see the name of your authorization store.
5. Double-click ContosoStore, right-click IIS 6.0 URL Authorization, and then click New Scope.
6. In the Name box, type B2C and then click OK.
7. Navigate to the B2C folder, and then double-click the folder to open it.
8. In the console tree, right-click Role Assignments, click Assign Roles, select the Viewer check box, and then click OK.

Task 14: Create an Authorization Manager Role Assignment

Creating an Authorization Manager role assignment simply requires linking the role created in Authorization Manager to a subset of users in the external Active Directory account. You can accomplish this in one of two ways: The first way to do this is to link Authorization Manager roles manually to a group in Active Directory. The second way is to create an application group in Authorization Manager, and then assign users statically or dynamically using an LDAP query. Contoso used the first method for this scenario.

To link a role to a group in Active Directory

1. Log on to your Web server as <domain>/trialadmin.
2. In the Authorization Manager MMC snap-in, click IIS 6.0 URL Authorization, and then click B2C.
3. Right-click Role Assignment, click Assign Roles, and then click Viewer.
4. Under B2C, click Role Assignments, right-click Viewer, and then click Assign Windows Users and Groups.
5. In the Enter the object names to select (examples) box, type Trial User and then select the check box for Check Name to ensure that the object exists in Active Directory and click OK to complete this procedure.

Configuring the Customer Trial Application to Use Authorization Manager

After Authorization Manager is set up, the final step is to associate the Customer Trial application with Authorization Manager to perform authorization. To complete this task, you must configure some settings to ensure that IIS will communicate with Authorization Manager and that a specific URL (or directory) is associated with the appropriate authorization scope.

Installation and Configuration Overview

Contoso completed the following tasks to install and configure the Customer Trial application. You can tailor these tasks to the requirements of your organization.

• Task 1: Create the Application Pool Using the LocalSystem Account
• Task 2: Assign the Application Pool to the Virtual Directory of the Customer Trial Application
• Task 3: Add the IIS Worker Process to the Authorization Manager Store Reader Role
• Task 4: Set the Web Application Configuration Properties to Point to the URLAuth.dll File
• Task 5: Add URLAuth.dll as a New Web Service Extension
• Task 6: Run Metabase Explorer to Find the Application URL
• Task 7: Run the SetURLAuth.vbs (VBscript) File to Assign Policy to the Web Application Virtual Directory.
• Task 8: Deploy the Live Passport-enabled Web Site

Task 1: Create the Application Pool Using the LocalSystem Account

By default, application pools run under the Network Service account on the server running IIS. However, to make Passport authentication work, you need to use the LocalSystem account to run application pools. Doing so ensures that IIS has the appropriate rights to create impersonation tokens for authenticated users. IIS uses these tokens when requesting authorization from Authorization Manager. Complete the following steps to accomplish this task.

To create an application pool using the LocalSystem account

1. Open IIS Manager, expand Local Computer, right-click Application Pools, point to New, and then click Application Pool.
2. In the Application Pool ID box, type LocalSysAppPool
3. Under Application Pool settings, select the Use default settings for new application pool check box, and then click OK.
4. Right-click LocalSysAppPool, click the Properties tab, and then the Identity tab.
5. Under Select a security account for the application pool, click Predefined and then Local system.
6. Click Yes to dismiss the warning on using the Local System account to run the application pool.

Task 2: Assign the Application Pool to the Virtual Directory of the Customer Trial Application

This task creates a link between the application pool created in an earlier procedure and the virtual directory associated with it. The Contoso Customer Trial application runs exclusively under one virtual directory, but you can select more than one if necessary.

To assign an application pool to a virtual directory

1. In IIS 6.0 Manager, right-click the virtual directory for the Customer Trial application (for example, the virtual directory for Contoso is called trial), and then click Properties.
2. Click the Virtual Directory tab, expand the Application pool drop-down list, select LocalSysAppPool, and then click OK.

Note    If the Application Pool list is not available, click Create to create the application.

1. Right-click the trialentry virtual directory and then click Properties.
2. Expand the Application Pool drop-down list, select LocalSysAppPool, and then click OK.
3. Right-click the subscribe virtual directory and then click Properties.
4. Expand the Application Pool drop-down list, select LocalSysAppPool, and then click OK.

Note   To enable a Windows XP client to sign in to a Passport Preproduction (PREP) mode, see the instructions in the following Microsoft Knowledge Base article, "A User Cannot Sign in to Microsoft Passport by Using Microsoft Windows XP in the Preproduction Environment".

Task 3: Add the IIS Worker Process to the Authorization Manager Store Reader Role

As mentioned in Task 1, IIS application pools run under the Network Service account by default. Now that you have changed the service account that the application pool runs under to the LocalSystem account, you also must make this account a member of the Authorization Manager Reader role. This task ensures that the service account can read the appropriate Authorization Policy.

To add the IIS Worker Process to the Authorization Manager Store Reader role

1. Open Authorization Manager.
2. In the console tree, right-click Authorization Manager, click Open Authorization Store, click Active Directory, and then click Browse.
3. Click CN=ContosoStore,CN=Contoso,CN=Program Data,DC=perimeter,DC=contoso, DC=com.
4. In the console tree, right-click ContosoStore and then click Properties.
5. Click the Security tab, and then under Authorization manager user role list, select Reader and click Add.

Figure 5.18. Using the ContosoStore Properties dialog box to add the IIS Worker process to the Authorization Manager Store Reader role

1. Click Object Type, and then in the Enter the object names to select box, type <domainname>\hostname$ (for example, domainname\WEB-01$) and click OK to complete this procedure.

Task 4: Set the Web Application Configuration Properties to Point to the URLAuth.dll File

When you configure an application, virtual directory, or URL to use IIS 6.0 URL Authorization, each request to a URL is routed to the URL Authorization ISAPI interceptor. The IIS 6.0 URL Authorization ISAPI interceptor uses the Authorization Manager runtime to authorize access to the requested URL. To do this, the URL (application, virtual directory, or single URL) must be associated with an Authorization Manager policy store that contains the authorization policy for the URL. After the client has been authorized to access the URL, the IIS 6.0 URL Authorization ISAPI interceptor passes the request to the appropriate handler , such as ASP or the static file handler.

The name of the file that must execute as the URL Authorization ISAPI interceptor is URLAuth.dll. You must associate this file with each virtual directory (or directory) that you want to associate with Authorization Manager.

To associate the URLAuth.dll file with the Customer Trial application

1. In IIS Manager, right-click the virtual directory containing the Customer Trial application, click Properties, click the Virtual Directory tab, and then click Configuration.
2. In the Wildcard application maps (order of implementation) area, click Insert.
3. In the Add/Edit Application Extension Mapping dialog box, click Browse, and then expand the Files of type list to select All files (*.*).
4. Browse to the %Systemroot%\System32\InetSrv folder, click URLAuth.dll, click Open, and then click OK three times to complete this procedure.

Note   If an error message appears that starts with "This executable path is already used…", the URLAuth.dll file is already configured to map wildcard application extensions.

Task 5: Add the URLAuth.dll File as a New Web Service Extension

You must configure IIS 6.0 to execute files that have a dynamic link library (.dll) extension.

To configure IIS 6.0 to execute .dll extension files

1. Open IIS manager, expand Local Computer, right-click Web Service Extensions, and then click Add a new Web service extension.
2. Click Add, click Browse, navigate to %Systemroot%\System32\InetSrv\, and then click the URLAuth.dll file, click Open, and then OK.
3. In the Extension Name box, type URL Authorization.
4. Select the Set extension status to Allowed check box and click OK.

Task 6: Run Metabase Explorer to Find the Application URL

The IIS metabase is a database similar in structure to the Microsoft Windows registry. The metabase is optimized for IIS to provide hierarchal storage and fast retrieval of IIS configuration properties for Web sites and virtual directories, including Web sites that use FTP, SMTP, and NNTP.

Each virtual directory is assigned a unique identifier that you can find easily using the Metabase Explorer. Use this identifier when running the SetUrlAuth.vbs script in the following task. To install Metabase Explorer, follow the steps in the B2E scenario under Task 8: Install and Run Metabase Explorer to Find the Application URL.

To use the Metabase Explorer

1. Log on to your Web server running IIS 6.0 as trialadmin.
2. Click Start, click All Programs, click IIS Resources, click Metabase Explorer and then click Metabase Explorer.
3. Browse to W3SVC to locate the B2C application virtual directory.
4. Identify the virtual directory path, for example, W3SVC/535085964/root/Customer Trial application.

Figure 5.19. The IIS 6.0 metabase properties in the IIS Metabase Explorer

Task 7: Run the SetURLAuth.vbs (VBscript) File to Assign Policy to the Web Application Virtual Directory

Contoso uses a Visual Basic script file to modify IIS metabase properties by assigning the appropriate Authorization Manager policy to the virtual directory. A sample script, called SetURLAuth.vbs, is included in the Tools and Templates folder that downloads with this series. Use the following procedure to run the SetUrlAuth.vbs script.

To run the SetURLAuth.vbs script file

1. Log on to your Web server running IIS 6.0 as <domain>/trialadmin.
2. Click Start, click Run, and then at the command prompt, type cmd and press ENTER.
3. Copy the SetUrlAuth.vbs file to the \InetPub\AdminScripts directory.

Note   By default the InetPub directory is in the root of the drive containing IIS 6.0.

1. At the command prompt, type the following:

   CScript SetUrlAuth.vbs <your virtual directory> B2C

   "msldap://CN=ContosoStore,CN=Contoso,CN=Program

   Data,DC=perimeter,DC=contoso,DC=com" true 1

2. Press ENTER.

IIS URL Authorization is now configured to run for the Customer Trial application in this scenario. Users in the Viewer role can browse to pages within the application.

Note   The syntax for the SetUrlAuth.vbs script is:

CScript SetUrlAuth.vbs <VirtualDirPath> <AuthMgrScopeName> <AuthMgrStoreName> <Enabled True/False> <ImpersonationLevel>

Task 8: Deploy the Live Microsoft Passport-Enabled Web Site

Before deploying a Passport-enabled Web site, participating sites must sign the Passport License and Service Agreement.

For more information about the Passport License and Service Agreement, see the Passport License and Service Agreement page on Microsoft MSDN®.

Chapter 6: Testing the Solution

This chapter describes how to validate the implemented solution scenarios from the previous chapter. It also provides some troubleshooting steps to help with common implementation challenges. Comprehensive guidance for testing the end-to-end user and administrator experience is not provided.

Business to Employee Extranet Access

After the B2E extranet access scenario implementation is complete, you are ready to validate your implementation to ensure that the B2E Web single sign on (SSO) application meets the requirements for Contoso.

Validating the Implementation Prerequisites

Before testing the implementation guidance in this paper, there are a few basic verification tests that you should perform to ensure that you have correctly configured the required infrastructure for the solution. Use the following tests to validate these prerequisites.

Tests to validate the prerequisites include:

• Basic Test 1: Verify Auto-enrollment Works in the Contoso Intranet Domain
• Basic Test 2: Verify Intranet User Access to the Contoso Extranet Web Page
• Basic Test 3: Verify Extranet Users Can Access the Contoso Web Page
• Basic Test 4: Verify Intranet and External Users Can Access the CRL Site
• Basic Test 5: Verify the CRL Is Updated on the Perimeter Web Server
• Basic Test 6: Verify the Contoso B2E Application Can Use HTTPS
• Basic Test 7: Verify the Sales and Contacts Application Runs Correctly
• Basic Test 8: Verify User Provisioning in the Extranet Active Directory
• Basic Test 9: Verify Sales Group User Accounts Are Mapped to Certificates

Basic Test 1: Verify Auto-enrollment in the Contoso Intranet Domain

Complete the following steps to verify that the sales users in the intranet Contoso domain will receive user authentication certificates through auto-enrollment.

To verify auto-enrollment for sales users in the Contoso intranet domain

1. Ensure that the public key infrastructure (PKI) is in place and configured for auto-enrollment with a user certificate template.
2. Create a new user who is a domain member in the Contoso domain.
3. Have the user log on to the intranet domain using their domain credentials.

These steps should confirm that the domain user received the user authentication certificate through auto-enrollment from the Contoso issuing certification authority (CA).

Basic Test 2: Verify Intranet User Access to the Contoso Extranet Web Page

Complete the following steps to verify that members of the intranet domain can access the Contoso extranet Web page.

To verify intranet domain users can access the Contoso extranet Web page

1. Log on to the intranet as a member of the domain.
2. Open Microsoft® Internet Explorer.
3. In the Address bar for the browser, type www.contoso.com and then click Go to test user access to the Web page.

This test should confirm that the user can view the Contoso HTML page in the browser.

Basic Test 3: Verify Extranet Users Can Access the Contoso Web Page

Complete the following steps to verify that extranet users via the Internet can access the Contoso Web page.

To verify extranet users via the Internet can access the Contoso Web page

1. Open Internet Explorer.
2. In the Address bar for the browser, type www.contoso.com and then click Go to test user access to the Web page.

This test should confirm that the user can view the HTML page in the browser.

Basic Test 4: Verify Intranet and Extranet Users Can Access CRL Site

Complete the following steps to verify that intranet and extranet users can access the certificate revocation list (CRL) site on the Contoso perimeter Web server.

To verify that intranet and extranet users can access the CRL site

1. Open Internet Explorer.
2. In the Address bar for the browser, type dp1.pki.contoso.com/pki and then click Go to access to the Web site.

This test should confirm that users in the Contoso intranet domain and extranet users can view the CRL site on the perimeter Web server.

Basic Test 5: Verify the CRL Is Updated on the Perimeter Web Server

Complete these steps to verify that the CRL is updated on the perimeter Web server.

To verify that the CRL is updated on the perimeter Web server

1. Open Internet Explorer.
2. In the Address bar for the browser, type dp1.pki.contoso.com/pki and then click Go to access to the Web site.
3. Open the CRL from the issuing CA to verify the next update field in the details pane.

This test should confirm that the CRL on the issuing CA has not expired, and that it is the latest list.

Basic Test 6: Verify the Contoso B2E Application Can Use HTTPS

Complete the following steps to verify that the Contoso B2E application is enabled to use Hypertext Transfer Protocol, Secure (HTTPS).

To verify the Contoso B2E application is enabled to use HTTPS

1. Install the B2E application on the extranet Web server and provide links for it on the Contoso home page.
2. Install the Web server certificate on the extranet server running Microsoft Internet Information Server (IIS 6.0), and then enable HTTPS on the B2E virtual directory.
3. From a client computer running Microsoft Windows® XP Professional, access the B2E link from the Contoso home page at: https://www.contoso.com/b2e.

This test should enable the client computer on the Internet to access the B2E Web page using the HTTPS protocol.

Basic Test 7: Verify the Sales and Contacts Application Runs Correctly

Complete the following steps to verify that the Sales and Contacts application runs correctly.

To verify that the Sales and Contacts application runs correctly

1. Open Internet Explorer.
2. In the Address bar for the browser, type https://www1.contoso.com and then click Go to test user access to the Web page.
3. Click the Sales and Contacts application URL and verify that the HTTPS protocol appears in the Address bar at the beginning of this URL.
4. Enter a sales user's user name and password.
5. Run the application.

This test should confirm that the Sales and Contacts application runs on the extranet Web server.

Basic Test 8: Verify Provisioning in the Extranet Active Directory

Complete the following steps to verify that the Sales and Contacts application users are provisioned in the extranet Microsoft Active Directory® directory service.

To verify these users are provisioned in the extranet Active Directory

• Use the DSA.msc file to verify that sales users are created and provisioned in the Sales group at: OU=Employees,OU=Accounts,DC=perimeter,DC=Contoso,DC=com.

This test should confirm that Sales and Contacts application users are provisioned in the extranet Active Directory.

Basic Test 9: Verify Sales Group User Accounts Are Mapped to Certificates

Complete the following steps to verify that users in the Sales group provisioned in the extranet Active Directory have their accounts mapped to their user certificates.

To verify Sales group user accounts are mapped to their user certificates

1. Use the DSA.msc file to verify that users are created and provisioned in the Sales group at: OU=Employees,OU=Accounts,DC=perimeter,DC=Contoso,DC=com in the extranet Active Directory.
2. Use the ADSIEDIT.msc file to locate the specific user object, and then right-click the object to view its properties.

Performing this test should confirm that the value in altSecurityIdentities matches the subject value in the user's authentication certificate. For example:altSecurityIdentities equals X509<I>DC=com,DC=contoso,DC=corp,DC=na,CN=Users,CN=user01,E=user01@corp.contoso.com.

Validating the Implementation

You can use the information in the following sections to test the B2E access management scenario and validate your implementation of the guidance.

Tests to validate the implementation include:

• Test 1: Verify SSO Access to the Sales and Contacts Application
• Test 2: Verify Non-Sales Group Employees Cannot Access the Application
• Test 3: Verify the Extranet Web Server Intercepts Authentication Requests
• Test 4: Verify Certificate Revocation Works Correctly
• Test 5: Verify Authenticated Users with the Authorization Manager Application
• Test 6: Verify Authenticated, But Unauthorized Users Are Denied Access
• Test 7: Verify Sales Group User Access Via the Contoso Intranet
• Test 8: Verify Deprovisioned Users Cannot Access the Application

Test 1: Verify SSO Access to the Sales and Contacts Application

Complete the following steps to verify that a sales employee can access the Sales and Contacts application via the Internet using SSO.

To verify SSO access to the Sales and Contacts application

1. Log on to the Internet on a client computer running Windows XP Professional using the cached credentials of a user who has membership in the domain.
2. Access the Contoso Web page, and then click the link for the Sales and Contacts application.
3. Verify that a message appears prompting the user to choose a user certificate from his or her user account certificate store.

This test should confirm that the user can successfully access the Sales and Contacts application using his or her user certificate.

Test 2: Verify Non-Sales Group Employees Cannot Access the Application

Complete the following steps to verify that employees who are not in the Sales group cannot access the Sales and Contacts application via the Internet.

To verify non-Sales Group employees cannot access the application

1. Log on to the Internet on a client computer running Windows XP Professional using the cached credentials of a user who has membership in the domain.
2. Access the Contoso Web page, and then click the link to the Sales and Contacts application.
3. Verify that a message appears prompting the user to choose a user certificate from his or her user account certificate store.

This test should confirm that this user cannot access the Web page for the Sales and Contacts application.

Test 3: Verify the Extranet Web Server Intercepts Authentication Requests

Complete the following steps to verify that the extranet Web server intercepts Sales employee authentication requests via HTTPS, and that the server uses client authentication certificates from the issuing CA to authenticate users to the extranet Active Directory.

To verify the extranet Web server intercepts authentication requests via HTTPS

1. Ensure the client has a valid user authentication certificate, and that the account maps correctly in the extranet Active Directory.
2. Log on to the extranet domain using cached credentials.
3. Access the Contoso Web page at https://www.contoso.com, and then click the link for the Sales and Contacts application to test it.
4. Verify that a message appears prompting you to specify a user certificate.

This test should confirm that the Web server intercepts the authentication request, and then displays a message prompting for a user certificate.

Test 4: Verify Certificate Revocation Works Correctly

Complete the following steps to verify that Sales employee authentication requests fail when users attempt to authenticate from the Web server to the extranet Active Directory, and that the user certificates are revoked.

To verify Sales employee attempts to authenticate from the Web server fail

1. Open the CA Microsoft Management Console (MMC) snap-in and navigate to the Issued Certificates folder. Revoke a certificate for a sales user who has access privileges to the Contoso Sales and Contacts application Web page.
2. Publish a new CRL from the Contoso issuing CA, and then update it to both the internal and external HTTP CRL locations.
3. Wait 24 hours for the CRL to refresh in the cached memory of the issuing CA.
4. Attempt to authenticate against the Web page at www.contoso.com using the link for the Sales and Contacts application and the same user name.

This test should confirm that the user receives an error message saying that his or her certification has been revoked, and that the user cannot access the Sales and Contacts application Web page.

Test 5: Verify Authenticated Users with the Authorization Manager Application

Complete the following steps to verify that authenticated users attempting to access the Sales and Contacts application are authorized based on their membership profile for the User, Group, Roles, and Application Objects in the extranet Active Directory using the Authorization Manager application.

To verify authenticated users with the Authorization Manager application

1. Ensure the client has a valid user authentication certificate, and that his or her account maps correctly to the extranet Active Directory. Also ensure the user ID is added to the Sales User group.
2. Log on to the extranet domain using cached credentials.
3. Access the Contoso Web page at www.contoso.com, and then click the link to the Sales and Contacts application.

This test should confirm that the user can access the Sales and Contacts Web page, unless he or she specifies a valid user certificate.

Test 6: Verify Authenticated But Unauthorized Users Are Denied Access

Complete the following steps to verify that authenticated but unauthorized users attempting URL access to the Sales and Contacts application are denied access based on their membership profile for User, Group, Roles and Application Objects in the extranet Active Directory using the Authorization Manager application.

To verify authenticated but unauthorized users are denied access

1. Log on to a client computer as a user who is not a member of the Sales group.
2. Access the Contoso Web page at www.contoso.com, click the link for the Sales and Contacts application, and attempt to log on.

This test should confirm that the user cannot log on to the site because he or she is not a member of the Sales group.

Test 7: Verify Sales Group User Access Via the Contoso Intranet

Complete the following steps to verify that users in the Sales group can access the Sales and Contacts application from the Contoso intranet.

To verify Sales Group user access via the Contoso intranet

1. Log on to the intranet domain as a member of the Sales group.
2. Open the CERTMGR.msc file and verify that the user has a client authentication certificate.
3. Access the Sales and Contacts application using the following address via the Microsoft Internet Security and Acceleration (ISA) proxy Server: www.contoso.com/sales.

This test should confirm that the user can access the Sales and Contacts application on the organization's extranet Web server from the internal network with no issues.

Test 8: Verify Deprovisioned Users Cannot Access the Application

Complete the following steps to verify that deprovisioned users in the Sales group cannot access the Sales and Contacts application from the Internet.

To verify deprovisioned users cannot access the application

1. Log on to the intranet domain on a computer running Windows XP Professional as a domain user who is a member of the Sales group.
2. Open the CERTMGR.msc file and verify that the sales user has a client authentication certification.
3. After the user account has been deprovisioned by Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1), attempt to log on as this user to his or her former computer via the Internet using cached credentials.
4. Then, if the user could log on, attempt to access the Sales and Contacts application as the user by typing the following address into Internet Explorer: https://www.contoso.com/b2c.

This test should confirm that the user is blocked from accessing the site, the application, and cannot view the page.

Troubleshooting

This section of the chapter provides information about some common errors that you may encounter while testing this scenario and how to most likely resolve them. However, the information in the following table is not an exhaustive list of errors and troubleshooting procedures.

Table 6.1. Troubleshooting Information for the B2E Extranet Access Scenario

Business to Customer Extranet Access

After the implementation section for the B2C extranet access scenario is complete, you are ready to validate your implementation to ensure that the B2C Web SSO application meets the requirements for Contoso.

Validating the Implementation Prerequisites

Before testing the implementation guidance in this paper, there are a few basic verification tests that you should perform to ensure that you have correctly configured the required infrastructure for the solution.

Tests to validate the prerequisites include:

• Basic Test 1: Verify Extranet Users Can Access the Contoso Web Page
• Basic Test 2: Verify the Contoso B2C Application Uses the HTTPS Protocol

Basic Test 1: Verify Extranet Users Can Access the Contoso Web Page

Complete the following steps to verify that extranet users via the Internet can access the Contoso Web page.

To verify extranet users can access the Contoso Web page

1. Open Internet Explorer.
2. In the Address bar for the browser, type www.contoso.com and then click Go to test user access to the Web page.

This test should confirm that the user can view the HTML page in the browser.

Basic Test 2: Verify the Contoso B2C Application Uses the HTTPS Protocol

Complete the following steps to verify that the Contoso B2C application is enabled to use the HTTPS protocol.

To verify the Contoso B2C application is configured to use the HTTPS protocol

1. Install the B2C application on the extranet Web server and provide links for it on the Contoso home page.
2. Install the Web server certificate on the perimeter server running IIS and enable HTTPS on the B2C virtual directory.
3. From a client computer running Windows XP on the Internet, access the B2C link from the Contoso home page (for example, https://www.contoso.com/b2c).

This test should confirm that the client computer on the Internet can access the B2C Web page using the HTTPS protocol.

Validating the Implementation

You can use the information in the following sections to test the B2C extranet access scenario and validate your implementation of this guidance.

Tests to validate the implementation include:

• Test 1: Verify New Customers Can Self-register for PPE Accounts
• Test 2: Verify the PPE Self-registration Process Completes Successfully
• Test 3: Verify Customers Have a Preproduction Passport Account
• Test 4: Verify Information is Provisioned in the Extranet Active Directory
• Test 5: Verify the Self-registration Process Generates Required Information
• Test 6: Verify the Extranet Web Server Intercepts Requests Via HTTPS
• Test 7: Verify with Authorization Manager Authenticated Customers Have Access
• Test 8: Verify Authenticated, But Unauthorized Customers Have No Access
• Test 9: Verify the Root User Can Log On to the UNIX Workstation
• Test 10: Verify UNIX Users Cannot Log On Using Local Account Credentials

Test 1: Verify New Customers Can Self-register for PPE Accounts

Complete the following steps to verify that a new customer participating in the Contoso Customer Trial undergoes a self-registration process to obtain a new Preproduction Passport Environment (PPE) account.

To verify new customers can self-register for PPE accounts

1. Ensure that the customer can access the Contoso home page via the Internet.
2. Instruct the customer to click the link for the Customer Trial application at https://www.contoso.com/b2c.
3. The customer's browser should display the welcome page for the Customer Trial application.
4. Instruct the customer to click the Sign-In icon.

This test should confirm that the new customer undergoes a self-registration process to obtain a PPE account that he or she can use to access the Contoso Customer Trial application.

Test 2: Verify the PPE Self-registration Process Completes Successfully

Complete the following steps to verify that verify that the PPE self-registration process completes, that the Web SSO application's default.asp and subscribe.asp files create a customer user account in the external Active Directory under the Trial Users OU (OU=Trial Users,OU=Accounts,DC=perimeter,DC=Contoso,DC=com), and that the user account is added as a member of the Trial Users group.

To verify the PPE self-registration process completes successfully

1. Ensure that a customer can access the Contoso home page via the Internet.
2. Instruct the customer to click the link to the Customer Trial application at https://www.contoso.com/b2c.
3. The customer's browser should display the welcome page for the Customer Trial application.
4. Instruct the customer to click the Sign-In icon, complete the PPE registration process, and then click Submit on the subscribe.asp page.
5. Use the Lightweight Directory Access Protocol (LDAP) utility ldp.exe or the ADSIEDIT.msc or DSA.msc files to verify that a new account for the user has been created in Active Directory.

Test 3: Verify Customers Have a Preproduction Passport Account

Complete the following steps to verify that a customer participating in the Contoso Customer Trial requires a Preproduction Microsoft Passport account to access the Customer Trial application Web page.

To verify customers require a Preproduction Passport account

1. Ensure that the customer can access the Contoso home page via the Internet.
2. The customer clicks the link for the Customer Trial application at https://www.contoso.com/b2c.
3. The customer's browser should display the welcome page for the Customer Trial application.

This test should confirm that on the welcome page, the customer is required to sign in to their preproduction Passport account before they can access the Customer Trial application.

Test 4: Verify Information is Provisioned in the Extranet Active Directory

Complete the following steps to verify that the following information is provisioned in the extranet Active Directory for the trial user from the Preproduction Passport database:

• First Name
• Last Name
• Telephone Number
• User Logon Name

To verify information is provisioned in the extranet Active Directory

1. Instruct the customer to complete the PPE self-registration process and click Submit on the subcribe.asp page.
2. On an extranet domain controller, open the Active Directory Users and Computers MMC snap-in.
3. Navigate to the Trial Users OU, and then right-click the user account to open it.

This test should confirm that the user account in the extranet Active Directory is provisioned with the information details retrieved from the user's PPE account.

Test 5: Verify Self-registration Process Generates Required Information

Complete the following steps to verify that the self-registration process generates the following information for users:

• sAMAccountName equals Passport User ID (PUID), a numerical value that must be distinct within the external domain that is generated through the provisioning process.
• The cn value is the same as sAMAccountName.
• The user's password is a 12 character string containing random characters that is not set to expire.

To verify the self-registration process generates the required information

1. Use LDP.exe, the ADSIEDIT.msc, or the DSA.msc file to browse to the Trial Users OU, and then to the Trial Users group.
2. Click the user account and open its properties.

This test should confirm that the user's password property is not set to expire, and that the user's PUID sets the value for sAMAcountName and cn.

Test 6: Verify the Extranet Web Server Intercepts Requests Via HTTPS

Complete the following steps to verify that the extranet Web server intercepts customer authentication requests via HTTPS, and that it uses Passport to authenticate customers to the extranet Active Directory.

To verify the extranet Web Server intercepts requests via HTTPS

1. Instruct a new customer to access the Contoso Web page via the Internet.
2. Instruct the customer to click the link to the Customer Trial application on the Contoso Web page.

This test should confirm that the page redirects the customer to the Passport site because the customer cannot access the Contoso site without a valid Passport account.

Test 7: Verify with Authorization Manager Authenticated Customers Have Access

Complete the following steps to verify that authenticated customers are authorized to access the Customer Trial application based on their User, Group, and Roles and Application Objects profile in the extranet Active Directory using Authorization Manager.

To verify authenticated customers have access with Authorization Manager

1. Obtain a valid Preproduction Passport account.
2. Ensure that the account is a valid Active Directory account that is a member of the Trial Users group.
3. Click the link for the Customer Trial application on the Contoso home page.

This test should confirm that the account can access the Customer Trial application page seamlessly.

Test 8: Verify Authenticated, But Unauthorized Customers Have No Access

Complete the following steps to verify that authenticated but unauthorized customers attempting URL access to the Customer Trial application are denied access based on their User, Group, Roles and Application Objects profile in the extranet Active Directory using Authorization Manager.

Verify that authenticated, but unauthorized customers have no access

1. Ensure that the customer account for this test has obtained a valid Passport account.
2. Ensure that the customer account is not a valid Active Directory account in the Trial Users group.
3. Click the link on the Contoso home page to access the Customer Trial application.

This test should confirm that the customer account cannot access the page because it is not a member of the Trial Users group.

Test 9: Verify the Root User Can Log On to the UNIX Workstation

Complete the following steps to verify that the Root user can successfully log in to the UNIX workstation using his or her local account password.

To verify the root user can log on to the UNIX Workstation

1. On the NA domain controller, open a command prompt.
2. Telnet to the UNIX workstation using the fully qualified domain name (FQDN) of the workstation.
3. At the login prompt, type root and then press ENTER.
4. At the password prompt, enter the root user's local account password.

This test should confirm that the Root user can successfully log on to the workstation using his or her local account.

Test 10: Verify UNIX Users Cannot Log On Using Local Account Credentials

Complete the following steps to verify that logon fails for UNIX users if they enter local account credentials while logging on to the UNIX workstation.

To verify UNIX users cannot log on using local account credentials

1. From the NA domain controller, open a command prompt.
2. Telnet to the UNIX workstation using the FQDN of the workstation.
3. At the login prompt, enter a local user account ID.
4. At the password prompt, enter the local user account password and press ENTER.

This test should confirm that users cannot log on to their UNIX workstations using their local account credentials.

Troubleshooting

This section provides information about some common errors that you may see while testing this scenario and how you can likely resolve them. However, the information in the following table is not an exhaustive list of errors and troubleshooting procedures.

Table 6.2. Troubleshooting Information for the B2C Extranet Access Scenario

Chapter 7: Operational Considerations

After the provided solution scenarios have been implemented and validated, a number of ongoing operational activities must happen to ensure continued success. The "Platform and Infrastructure" paper in this series provides information and references for how each service in the infrastructure should be operated. This chapter introduces a few additional operational considerations for the specific solution scenarios in this paper.

Business to Employee Extranet Access

The business-to-employee (B2E) extranet access scenario needs to manage the public key infrastructure (PKI) in addition to the general operational considerations described in this chapter.

Public Key Infrastructure

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

Microsoft recommends backing up all certification authorities (CA) regularly to ensure that the CA database, the 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 in the Windows Event log. Review these logs regularly to track CA activity, particularly for issued certificates, and for 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 Microsoft® Internet Information Services (IIS 6.0) certificates are maintained, current, and reissued at regular intervals so that users are not locked out from the services they need to access.

For more information about maintaining a PKI in your environment, see the Windows Server 2003 PKI Operations Guide on Microsoft TechNet.

Business to Customer Extranet Access

The business-to-customer (B2C) extranet access scenario needs to manage Microsoft Passport in addition to the general operational considerations described in this chapter.

Microsoft Passport

You can monitor the Microsoft Passport system using a combination of the Microsoft Windows Event log and performance counters. The Event log contains the system level events (Passport start and stop events), and you can use the Performance Monitor to track more comprehensive statistics such as the number of login attempts (failed or successful) on a total and per-second basis.

Tracking Passport activity will enable administrators in your organization to:

• Monitor and review site activity, paying particular attention to the number and activity periods for failed login attempts. These failures could signal attempts by hackers to gain access to the application, and may also highlight other problems within the site that prevent legitimate users from accessing resources.
• Ensure that Passport is functioning correctly to service client requests properly.

---