Академический Документы
Профессиональный Документы
Культура Документы
Table of Contents
iii
2006 Microsoft Corporation. This work is licensed under the Creative Commons Attribution-NonCommercial License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/2.5/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.
Table of Contents
iii
Contents
Chapter 1: Introduction to the Extranet Access Management Paper.....1 Executive Summary.............................................................................1 Business Challenge........................................................................1 The Business Benefits.....................................................................1 Who Should Read This Paper...........................................................2 Reader Prerequisites......................................................................2 Feedback......................................................................................2 Paper Overview...................................................................................2 Solution Scenarios.........................................................................3 Chapter 2: Approaches to Extranet Access Management......................5 Extranet Considerations........................................................................5 VPN or Web Access........................................................................5 Directory Service Selection..............................................................7 Existing Applications.......................................................................7 Identity Life-Cycle Management.......................................................8 Password Security..........................................................................8 Authentication Methods........................................................................9 SSL and TLS Authentication.............................................................9 Microsoft Passport........................................................................11 Digest and Basic Authentication.....................................................12 Forms-based Authentication..........................................................14 Security Assertion Markup Language...............................................14 XML Web Services........................................................................15 Summary....................................................................................17 Authorization Techniques....................................................................17 Trust Techniques................................................................................18 Using Windows Trusts...................................................................18 Shadow Accounts.........................................................................18 PKI Trusts...................................................................................19 Trusting Passport or Other Identity Stores.......................................19 Federation...................................................................................19 Personalization Techniques..................................................................19 Independent Software Vendor Solutions................................................20 Chapter 3: Issues and Requirements..................................................21 Business to Employee Extranet Access..................................................21 Background.................................................................................21
iv
Business Issues...........................................................................22 Technical Issues...........................................................................22 Security Issues............................................................................22 Solution Requirements..................................................................23 Business to Customer Extranet Access..................................................23 Background.................................................................................23 Business Issues...........................................................................23 Technical Issues...........................................................................24 Security Issues............................................................................24 Solution Requirements..................................................................24 Chapter 4: Designing the Solution.......................................................25 Business to Employee Extranet Access..................................................25 Solution Concept..........................................................................25 Solution Prerequisites...................................................................26 Solution Architecture....................................................................27 How the Solution Works................................................................28 Extending the Solution..................................................................29 Business to Consumer Extranet Access.................................................30 Solution Concept..........................................................................30 Solution Prerequisites...................................................................30 Solution Architecture....................................................................30 How the Solution Works................................................................31 Chapter 5: Implementing the Solution................................................33 Tools and Templates...........................................................................33 Folder: B2E Extranet Access Example.............................................34 Folder: B2C Extranet Access Example.............................................34 Business to Employee Extranet Access..................................................34 Implementation Prerequisites........................................................34 Implementation Overview.............................................................35 Establishing User Certificate Auto-Enrollment...................................35 Configuring Authentication Using X.509 Certificates and Active Directory .................................................................................................35 Configuring Authorization Manager.................................................39 Configuring Authorization Manager for the Sales and Contacts Application..................................................................................47 Configuring the Sales and Contacts Application to Use Authorization Manager.....................................................................................49 Business To Customer Extranet Access.................................................57 Implementation Prerequisites........................................................57
Table of Contents
Implementation Overview.............................................................57 Configuring Passport Integration with Active Directory and Authorization Manager.....................................................................................57 Configuring the Customer Trial Application to Use Authorization Manager .................................................................................................66 Chapter 6: Testing the Solution...........................................................72 Business to Employee Extranet Access..................................................72 Validating the Implementation Prerequisites....................................72 Validating the Implementation.......................................................76 Troubleshooting...........................................................................79 Business to Customer Extranet Access..................................................80 Validating the Implementation Prerequisites....................................80 Validating the Implementation.......................................................81 Troubleshooting...........................................................................86 Chapter 7: Operational Considerations...............................................87 Business to Employee Extranet Access..................................................87 Public Key Infrastructure...............................................................87 Business to Customer Extranet Access..................................................88 Microsoft Passport........................................................................88 Links....................................................................................................89 Acknowledgments...............................................................................91
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 lessenjoyable user experience.
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.
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).
Feedback
Please direct questions and comments about this guide to secwish@microsoft.com.
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.
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.
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.
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.
For more information about IAS, see the Internet Authentication Service page. The remainder of this paper focuses on providing Web-based extranet access solutions.
Some of the advantages of Active Directory over ADAM for extranet use include:
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.
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. 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.
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 servers 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.
10
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.
11
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).
12
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 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.
13
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.
14
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 Formsbased 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.
15
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.
Web ServicesSecurity
WSSecurity is a multi-vendor open specification for implementing security in Web services. WSSecurity Version 1.1 is now an OASIS standard. Related specifications such as WSTrust, WSFederation and WSSecureConversation 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 ServicesFederation
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. WSFederation builds on the foundations and mechanisms specified in WSSecurity, WSPolicy, and WSTrust, by using the concepts of claims and security tokens to enable richer trust realm mechanisms across and within federations. For more information about the WSFederation definition, see "Web Services Federation Language", on the MSDN Web site.
Single Sign On
WSSecurity and WSFederation 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.
16
For more information about ADFS, see "Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2".
17
Summary
The following table summarizes the extranet authentication techniques discussed above. Table 2.1. Summary of Extranet Scenarios and Authentication Techniques Authentication Method SSL and TLS X.509 Client Authentication Passport Services Digest Basic (over SSL) Forms-based (over SSL) WS Security and WS Federation through ADFS Legend: B2E B2B B2C SSO x-Platform Browsers
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.
18
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.
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.
19
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.
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 rolesbased authorization mechanism such as Windows Server Authorization Manager or ASP.NET roles.
20
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
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
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.
22
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
23
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).
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.
24
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.
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
26
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.
27
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.
28
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
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
29
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.
30
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
31
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.
32
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.
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.
34
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.
35
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
36
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.
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
37
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 9. Click Start, Run, and then at the Open prompt type mmc and click OK. 10. On the File menu, click Add/Remove Snap-in, and then click Add. 11. From the Snap-in list, double-click Certificates, select Computer account, and then click Next. 12. Select Local computer, click Finish, Close, and then click OK to exit the wizard. 13. Double-click Intermediate Certification Authorities, right-click Certificates, click All Tasks, and then click Import to start the Certificate Import Wizard. 14. On the wizard welcome page click Next, Browse to select the exported certificate you created in the previous procedure, and click Open. 15. 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. 16. Click Next, and then Finish to exit the wizard.
38
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 4. Open IIS Manager, right-click the virtual directory of the Sales and Contacts application, and then click Properties. 5. Click the Directory Security tab and then in the Secure communications area click Edit. 6. 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
39
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 doubleclick 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".
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
40
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.
41
Note If you cannot view this folder, click View, and then Advanced Features from the main menu.
9. After the Delegation of Control wizard launches, click Next. 10. 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 11. Select all of the tasks in Delegate the following common tasks area and then click Next.
42
12. Right-click the Contoso folder, click Properties, the Security tab, and then click Add. 13. 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
43
5. Click Active Directory to define the authorization store type. The distinguished name (DN) of the Program Data will appear under Store Name. 6. 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
44
Figure 5.5. Using the New Application dialog box to create a new application
45
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.
46
Figure 5.7. Using the Role Definition dialog box to create a role definition 3. In the console tree, double-click Role Definitions, and then in the details pane, rightclick Viewer, click Properties, click the Definition tab, click Add, and then the Operations tab. 4. 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
47
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.
48
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
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.
49
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
50
Figure 5.11. Using the Add New Application Pool dialog box to add a new application pool in IIS 6.0
51
3. In the Application pool settings area, click the Use default settings for new application pool option.
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.
52
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,
53
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 6. 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.
54
Figure 5.15. Using the Application Configuration dialog box to set the Web application configuration properties to point to URLAuth.dll
55
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.
56
5. 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.
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.
4.
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 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.
5. Press ENTER.
Note
57
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.
58
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
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.
59
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.
7. Click Next. 8. 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. 9. On the Other .NET Passport Information page, complete the fields according to your requirements, and then click Next. 10. 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. 11. Complete the other optional fields on the page according to your requirements, and then click Submit.
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.
60
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.
61
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.
62
3. Assign the Read and Create All Child Objects permissions to the trialadmin account, and then click OK.
3. Click Next, click Add, and then type trialadmin 4. Under the Delegate the following common tasks section of the Tasks to Delegate page, select each task individually, click Next, and then Finish. 5. Right-click the Contoso folder, click Properties, the Security tab, and then click Add. 6. In the Enter the object name to select field, type trialadmin and click OK. Then, under Allow, select the option for Full Control.
63
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 File name default.asp Description The default.asp file resides in a virtual directory, and is used by Passport to protect applications by default. When users successfully authenticate to Passport, the default.asp file invokes the Passport Manager API to retrieve and display user profile information. The subscribe.asp file also invokes the Passport Manager API to obtain user passport information. The Passport Manager API generates a page that prompts the user for information, which ADSI then uses to create user profiles in Active Directory.
subscribe.asp
To enable mapping Passport users to Active Directory 1. Open IIS 6.0 Manager and create a new virtual directory called trialentry.
64
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.
6. Enter the domain name perimeter.contoso.com in the Default domain box, and then click OK twice. 7. Create another virtual directory called subscribe. 8. Copy the subscribe.asp file to the subscribe virtual directory. 9. Right-click the subscribe directory, and then click Properties. 10. Click the Directory Security tab, and then under Authentication and access control click Edit. 11. Select the Enable anonymous access check box, and then click .NET Passport authentication. 12. Enter the domain name perimeter.contoso.com in the Default domain box. 13. Configure the account used for anonymous access, type trial admin in the box that appears, and then click OK. 14. 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.
65
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.
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.
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.
66
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.
67
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 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.
3. Right-click the trialentry virtual directory and then click Properties. 4. Expand the Application Pool drop-down list, select LocalSysAppPool, and then click OK.
68
5. Right-click the subscribe virtual directory and then click Properties. 6. 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
69
6. 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.
70
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.
71
4. 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 5. 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:
73
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.
74
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.
75
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.
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.co ntoso.com.
76
77
78
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 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.
79
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 Error HTTP Error 401.1 Unauthorized: Access is denied due to invalid credentials. Troubleshooting procedure Verify the Internet user accessing the Sales and Contacts application is a member of the Sales Group in the extranet Active Directory. Verify the mapping between the altsecurityIdentities account attribute in Active Directory and the user's subject name in the certificate is correct. Verify that client certificates is set to the option for Require client certificates in the Sales and Contacts application's virtual directory. To browse to this location, click Properties on the virtual directory, click Directory Security, click Secure communications, and then click Edit to verify the information. Verify the Sales group has been added as a Viewer role in the B2C role assignments in the Azman.msc file. To browse to this location, open the Azman.msc file and then under ContosoStore, click IIS 6.0 URL Authorization, click B2C, click Role Assignments, and then click Viewer. Verify that Internet users can access the CRL hosted on the Contoso extranet Web server. Also verify that the user's authentication certificate is not revoked by the issuing CA.
80
Error HTTP Error 403.7 Forbidden: SSL client certificate is required. HTTP Error 403.7 Forbidden: Client certificate is ill formed or is not trusted by the Web server. Service Unavailable.
Troubleshooting procedure Verify that the user has a valid Contoso user authentication certificate in the user account certificate store. Verify that the steps given in the "Establishing Certificate Authority Trust in IIS 6.0" section have been followed correctly. Restart IIS on your Web server.
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.
81
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.
82
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.
83
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.
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.
84
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.
85
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.
86
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 Error HTTP Error 401.1 Unauthorized: Access is denied due to invalid credentials. Troubleshooting procedure Verify that the Trial Users group has been added in the Viewer role of B2E Role Assignments. To verify this, open the AZMAN.msc file, navigate to ContosoStore, click IIS 6.0 URL Authorization, click B2E, click Role Assignments, and then click Viewer properties. Verify that the check box for Passport Authentication is selected in the customer application virtual directory. To verify this information, open the IIS MMC snap-in, browse to the Customer Trial feedback application virtual directory, rightclick and select Properties, click Directory Security, click Authentication and access control, and then click Authentication methods. HTTP Error 403.20 Forbidden: Passport logon failed. The user on the Internet fails to see the Passport logon wizard prompt when he or she accesses the Contoso Customer Trial feedback application Web site at https://www.contoso.com/b2c. Verify that the user trying to access the site has a valid Passport account. Verify that the instructions have been followed, and that the suggested registry settings have been configured according to the instructions in Microsoft Knowledge Base article 816417, "A User Cannot Sign in to Microsoft Passport by Using Microsoft Windows XP in the Preproduction Environment". Verify that the user's Passport profile information can be used by other applications on the Passport registration site. In the Passport Manager Administration utility, verify the site ID you received from .NET Services Manager. Repeat the steps to obtain a Passport site ID and Encryption Key in Chapter 5, "Implementing the Solution."
The first name, last name and e-mail address fields on the Subscribe.asp page are blank. The page does not appear.
The user does not receive an encryption key to the site after registering for one to the site at .NET Services Manager.
88
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.
Links
Microsoft Identity and Access Management Series http://go.microsoft.com/fwlink/?LinkId=14841 Internet Authentication Service http://go.microsoft.com/fwlink/?linkId=67764 Step-by-Step Guide to Mapping Certificates to User Accounts http://go.microsoft.com/fwlink/?linkId=66850 Windows XP Security Guide http://go.microsoft.com/fwlink/?linkid=14839 The Microsoft .NET Passport Review Guide http://go.microsoft.com/fwlink/?linkId=67766 Microsoft .NET Passport for Developers http://go.microsoft.com/fwlink/?linkId=67769 Setting Up .NET Passport in IIS 6.0 (IIS 6.0) http://go.microsoft.com/fwlink/?linkId=67770 Request For Comments (RFC) 2965 http://www.faqs.org/rfcs/rfc2965.html Request For Comments (RFC) 2617 http://www.faqs.org/rfcs/rfc2617.html Organization for the Advancement of Structured Information Standards (OASIS) http://www.oasis-open.org Web Services and Other Distributed Technologies http://go.microsoft.com/fwlink/?linkId=67772 New Technologies Help You Make Your Web Services More Secure http://go.microsoft.com/fwlink/?linkId=67773 Web Services Federation Language http://go.microsoft.com/fwlink/?linkId=66833 Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2 http://go.microsoft.com/fwlink/?linkId=66852 Role-Based Access Control for Multi-tier Applications Using Authorization Manager http://go.microsoft.com/fwlink/?linkId=67812 Federation Service http://go.microsoft.com/fwlink/?linkId=67776 Internet Explorer Does Not Support Kerberos Authentication With Proxy Servers http://go.microsoft.com/fwlink/?linkId=67777 Setting Up Security Zones http://go.microsoft.com/fwlink/?linkId=67781 BMC Software http://www.bmc.com
90
Computer Associates http://www.ca.com Oracle http://www.oracle.com Proginet http://www.proginet.com RSA Security http://www.rsasecurity.com Installing a New Certificate with Certificate Wizard for Use in SSL/TLS http://go.microsoft.com/fwlink/?LinkID=67783 How to Set Up an HTTPS Service in IIS http://go.microsoft.com/fwlink/?linkId=67787 Determining Application Compatibility with Worker Process Isolation Mode (IIS 6.0) http://go.microsoft.com/fwlink/?linkId=67788 HOW TO: Configure Active Directory Certificate Mapping http://go.microsoft.com/fwlink/?linkId=67789 Windows Server 2003 Administration Tools Pack Download http://go.microsoft.com/fwlink/?linkId=67587 Internet Information Services (IIS) 6.0 Resource Kit Tools Download http://go.microsoft.com/fwlink/?linkId=67790 Microsoft Services Manager Web site http://www.netservicesmanager.com A User Cannot Sign in to Microsoft Passport by Using Microsoft Windows XP in the Preproduction Environment http://go.microsoft.com/fwlink/?linkId=67791 Passport License and Service Agreement http://msdn.microsoft.com/library/default.asp?url=/library/enus/passport25/serviceguide/policy/Sign_Agreement.asp Windows Server 2003 PKI Operations Guide http://go.microsoft.com/fwlink/?linkid=67373
Acknowledgments
Microsoft Solutions for Security (MSS) would like to acknowledge and thank the people that were directly responsible or made a substantial contribution to writing and reviewing this paper in the Microsoft Identity and Access Management Series.
Release Manager
Karl Seng, Siemens Agency Services
Testers
Gaurav Singh Bora, Infosys Technologies Prathiraj Chakka, Infosys Technologies Mehul Mediwala, Infosys Technologies Simon Biles, Content Master
Editors
John Cobb, Volt Information Sciences Steve Wacker, Volt Information Sciences Wendy Cleary Prowell, Content Master Marty Hale-Evans, Content Master
Program Managers
Derick Campbell Alison Woolford, Content Master