Implementing an ADFS Solution for Microsoft...

Security

Microsoft Dynamics CRM 4.0

Implementing an ADFS Solution for Microsoft Dynamics CRM by Using Intelligent Application Gateway (IAG)White Paper

Date: July 2009

AcknowledgementsInitiated by the Microsoft Dynamics CRM Engineering for Enterprise (MS CRM E2) Team, this document was developed with support from across the organization and in direct collaboration with the following:Key ContributorsIdan Plotnik (MVP, IAGserver.ORG)Meir Mendelovich (Microsoft)Chen Kirsch (Microsoft)Eli Tovbeyn (Microsoft)

Technical ReviewersMahesh Hariharan (Microsoft)Monika Borgaonkar (Microsoft)Ip Sam (Microsoft)

The MS CRM E2 Team recognizes their efforts in helping to ensure delivery of an accurate and comprehensive technical resource in support of the broader CRM community.MS CRM E2 ContributorsAmir Jafri, Program ManagerJim Toland, Content ManagerFeedbackPlease send comments or suggestions about this document to the MS CRM E2 Team feedback alias (entfeed@microsoft .com ).

2IMPLEMENTING AN ADFS SOLUTION FOR MICROSOFT DYNAMICS CRM 4.0 BY USING IAG JULY 2009

Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar Microsoft software, automating and streamlining financial, customer relationship and supply chain processes in a way that helps you drive business success.U.S. and Canada Toll Free 1-888-477-7989Worldwide +1-701-281-6500www.microsoft.com/dynamicsLegal NoticeThe information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.© 2009 Microsoft Corporation. All rights reserved.Microsoft, Microsoft Dynamics, Microsoft Dynamics Logo, Microsoft Office Outlook, Active Directory, Windows Server, Windows Vista, and Hyper-V are trademarks of the Microsoft group of companies.All other trademarks are property of their respective owners.

http://www.microsoft.com/dynamics

mailto:[email protected]

mailto:[email protected]

Table of Contents

Introduction.................................................................................................................................5Providing External Access to Internal Resources.....................................................................5Common Business Scenarios...................................................................................................5

Partner Access Scenarios.....................................................................................................5Merger and Acquisition Scenarios........................................................................................6Alliances and Agencies Collaboration Scenarios..................................................................6Web Services Scenarios.......................................................................................................6

Overview.....................................................................................................................................7What is ADFS?.........................................................................................................................7What is IAG?............................................................................................................................8

Key Features and Functionality............................................................................................8Key Benefits.........................................................................................................................9

Architecture..............................................................................................................................10IAG as Authentication Broker Architecture............................................................................10Sample Deployment..............................................................................................................10

Adatum Organization (Account Domain)............................................................................11Treyresearch Organization (Resource Domain)..................................................................11Sample Flow.......................................................................................................................11Detailed Flow.....................................................................................................................12

Implementing an ADFS Solution for CRM by Using IAG..............................................................16Prerequisites..........................................................................................................................16Overview of the Implementation Process..............................................................................16Implementing ADFS...............................................................................................................17Implementing IAG 2007 with SP2..........................................................................................17Configure Active Directory for Delegation.............................................................................17Publishing ADFS by Using IAG................................................................................................17

Configuring an IAG Portal Trunk.........................................................................................17Configuring ADFS with IAG.................................................................................................18

Publishing Microsoft Dynamics CRM 4.0 by Using IAG...........................................................18Configuring Kerberos Constrained Delegation for the CRM Application.............................19

Manage User Operations on CRM from Non-compliant Endpoints..........................................20Appendix A: Additional Resources.............................................................................................21

3JULY 2009 IMPLEMENTING AN ADFS SOLUTION FOR MICROSOFT DYNAMICS CRM 4.0 BY USING IAG

PrefaceThis document provides information related to implementing an ADFS solution for Microsoft Dynamics CRM 4.0 by using Intelligent Application Gateway (IAG) 2007 SP2.Important: Microsoft Dynamics CRM 4.0 implementations that leverage IAG to provide an ADFS solution support only the Microsoft Dynamics CRM 4.0 web client; the Microsoft Dynamics CRM for Office Outlook clients are not supported by ADFS.AudienceThe content is designed for experienced IAG users who are seeking the guidance and resources necessary to successfully implement such a solution. Readers without the prerequisite IAG skills and knowledge should familiarize themselves with the terms and concepts associated with IAG before attempting to implement a solution based on the information provided in this document.ObjectivesThe goals of this document are to:

Explain the business need and common business scenarios for using ADFS and IAG Summarize the functionality and benefits associated with using ADFS Summarize the functionality and benefits associated with using IAG Explain the architecture associated with an ADFS solution for Microsoft Dynamics CRM

that leverages IAG Illustrate the solution architecture by providing and describing a sample deployment Summarize the process for and provide high-level guidance on implementing an ADFS

solution for Microsoft Dynamics CRM by using IAG


IntroductionProviding External Access to Internal ResourcesBy default, an on-premise implementation of Microsoft Dynamics CRM 4.0 leverages Active Directory (Integrated Windows) Authentication to accommodate access by internal users. However, many businesses also require the ability to provide external users with access to the highly sensitive information that is stored in the CRM system and to accommodate this access without having to create Active Directory trusts.Because providing external access to internal CRM resources can also introduce potential security risks from both external and internal sources, in these scenarios, the CRM implementation must be protected by a gateway, such as Intelligent Application Gateway (IAG) 2007, which is sensitive to application logic and data and can ensure that internal and external users perform their routine tasks in a secure manner.By using a combination of IAG and Active Directory Federation Services (ADFS) to establish an authentication gateway, companies can provide access to CRM resources by any identity from any organization, from any computer, complete with strong authentication and full Single Sign On from the end user to the internal CRM system with a full audit trail (including username and source IP).Important: Consider implementing ADFS for scenarios in which establishing two-way trust between users and CRM resource domains is not possible.Common Business ScenariosThis integration architecture also provides a solution that can accommodate other business scenarios, such as company acquisitions, collaboration between companies or agencies; web services from other organizations that need to send or request information from the CRM system; DMZ users that need access to internal resources when there isn’t a trust relationship between the Active Directory in the DMZ and that in the internal network, or any other internal highly classified networks that don't establish trust relationships.Partner Access ScenariosMost companies today work with partners to perform many core and non core business activities. These partners need access to most of the company resources, including CRM, and they need access as seamlessly as possible to ensure efficient operation of the business.At the same time, these partner organizations are not “fully trusted”, and therefore their access should be filtered and audited. Because these partners might also work with a company’s competitors, access is usually provided only to a subset of the partner’s employees. On the other hand, the partners usually do not “fully trust” all of the companies they are working with, and as a result do not want to disclose their employees’ passwords.In these scenarios, there are two different approaches to partner integration:

Use ADFS to integrate the company’s primary Active Directory with the partner’s Active Directory.

Establish an independent Active Directory deployment for extranet access and then populate that deployment with duplicated identities for partners and employees.

IAG provides a solution (further detailed in this document) that can accommodate each of these approaches.


While the application of ADFS in the first approach may be obvious, ADFS can also play a role in scenarios that include a separate Active Directory deployment for extranet users when there is no trust relationship with the primary Active Directory, or scenarios in which highly classified networks segments cannot establish trust with other, less-classified networks. In these scenarios, ADFS and IAG can provide a Single Sign On (SSO) experience and full audit trail between those networks without compromising security.Merger and Acquisition ScenariosIn these scenarios, there are different Active Directories forests without any cross-forest trust relationships. By implementing IAG and ADFS as the authentication gateway, identities from that company, with their credentials, can access to the CRM system. The architecture and implementation in this case is similar to partner access.Alliances and Agencies Collaboration ScenariosOther common scenarios requiring access to CRM data by external parties are collaborative efforts between several companies or agencies within an alliances, consortiums, or government activities. In these scenarios, each organization has a unique identity system, but all need access to shared resources.Web Services ScenariosIn these scenarios, external web services require access to the CRM implementation, but the web services have identities that do not belong to the Active Directory domain in which the CRM deployment is located. While these scenarios are common today, security regulations often require a full audit trail of the original identities that access internal CRM implementations from external networks and in addition full SSO experience.


Overview

What is ADFS?Microsoft Active Directory Federation Services (ADFS) provides the interoperability required to simplify the broad, federated sharing of digital identities and policies across organizational boundaries. Seamless yet secure, customers, partners, suppliers, and mobile employees can all securely gain access to the information they need, when they need it.ADFS is a standards-based service that allows the secure sharing of identity information between trusted business partners (known as a federation) across an extranet. When a user needs to access a Web application from one of its federation partners, the user's own organization is responsible for authenticating the user and providing identity information in the form of "claims" to the partner that hosts the Web application. The hosting partner uses its trust policy to map the incoming claims to claims that are understood by its Web application, which uses the claims to make authorization decisions.ADFS is Microsoft's implementation of the WS-Federation Passive Requestor Profile protocol (passive indicates that the client requirements are just a cookie- and JavaScript-enabled Web browser). ADFS implements the standards based WS-Federation protocol and Security Assertion Markup Language (SAML).Implementing an ADFS solution within an organization can bring a variety of benefits.

Boost cross-organizational efficiency and collaboration with secure data access across companies

Improve operational efficiency with streamlined federation systems and simplified management of IDs and passwords

Enhance visibility into cross-boundary processes with transparent, auditable information rights and roles

Improve security with ADFS claim mapping, SAML tokens, and Kerberos authentication Reduce costs by taking advantage of existing investments in Active Directory and

security systems Eliminate the complexity of managing federation by using Active Directory as the main

identity repository End users rely on their existing AD credentials to gain access to federated services,

avoiding the need to remember additional user name and password information.

Organizations can leverage these benefits to address a wide range of business needs, such as: Improving collaboration and operational efficiency by building secure and efficient

connections with other organizations Retaining control over corporate data while allowing trusted entities to access to business

information Expressing, communicating, and sharing business policies with other trusted

organizationsNote: For more information about ADFS, on the Windows Server 2003 R2 site, see Federated Identity at: http://www.microsoft.com/ADFS


http://www.microsoft.com/ADFS

What is IAG?Intelligent Application Gateway (IAG) 2007 is a remote access and application layer gateway that boosts security and productivity by providing mobile and remote workers, partners, and customers with easy, flexible, and secure access to virtually any application from a broad range of devices and locations. Using a combination of SSL VPN (Secure Socket Layer Virtual Private Network), a Web application firewall, endpoint security management, and application aware publishing, IAG provides employees, partners, vendors, and customers with secure, easy access from a broad range of devices and locations including kiosks, computers, and mobile devices.With IAG, IT administrators can enforce compliance with application and information usage guidelines through a remote access policy customized based on device, user, application, or other business criteria.Key Features and FunctionalityGranular Application IntelligenceThe heart of IAG is a highly granular and intelligent application firewall that improves the security, functionality, and performance of most applications. IAG provides default policies that address common applications such as Dynamics CRM, SharePoint, Exchange, and Terminal Services. In addition, it is possible to create new (or custom) policies to enhance proprietary line of business applications, for example, to allow uploads only if a specific anti-virus software is running with a recently installed update.Endpoint and Access SecurityIAG includes a comprehensive endpoint security engine that allows for the detection of a device’s security and configuration state. As a result, administrators can publish granular and restricted access to unmanaged machines and extend more comprehensive and rich access from corporate assets. Information leakage is mitigated by using IAG’s Attachment Wiper. Policies are built-in and simple to manage.The Attachment Wiper identifies content that the client download from internal application to the computer it access from, identify password that were saved in the cache, etc. When the session is terminated (by the user or by the IAG policy), the Attachment Wiper wipes the information from the end-point. As a result, the Attachment Wiper can provide another level of security to the organization when allowing remote access to internal applications.Easy Management and CustomizationWith wizard-driven configuration, easy-to-use policies, and a highly intuitive user experience, IAG ensures a fast and easy configuration and deployment—allowing employees, partners, vendors, and customers with simple and secure access to internal applications.


Key BenefitsKey benefits of IAG include:

A unique combination of SSL VPN-based access, integrated application protection, and endpoint security management.

A consolidated and comprehensive gateway to provide access to virtually any application from virtually any location and virtually from any computer.

A powerful, Web-application firewall that helps keep malicious traffic out, sensitive information in and malicious attacks

Reduced complexity of managing secure access and protecting business assets with a comprehensive, easy to use platform.

Interoperability with core Microsoft application infrastructure, third-party enterprise systems, and custom in-house tools.

Note: For more information about IAG, see the Intelligent Application Gateway site at http://www.microsoft.com/IAG, or on TechNet, see the article About Intelligent Application Gateway 2007 at http://technet.microsoft.com/en-us/library/cc303240.aspx.


http://technet.microsoft.com/en-us/library/cc303240.aspx

http://www.microsoft.com/IAG

ArchitectureIAG as Authentication Broker ArchitectureWhen Microsoft Dynamics CRM 4.0 is published by using IAG, the IAG server provides an authentication gateway that isolates and protects the authentication process that occurs between external users and the internal CRM server. In an authentication broker architecture, the user authenticates at the IAG server (typically located in the DMZ), and then the IAG server validates the user's credentials against Active Directory. If the credentials are validated, the IAG server proceeds differently depending on the configuration of the environment:

For environments in which the CRM server is configured to reply to the request with an HTTP 401 result to perform HTTP Basic authentication or NTLM, the IAG server sends the credentials to the internal CRM server (replays authentication).

In a Kerberos authentication delegation scenario (401 Negotiate), the IAG Server requests a Kerberos ticket on behalf of the external user, for a specific computer account (CRM) and for a specific service (HTTP); only then does the IAG server forward this ticket to the internal CRM server.

The IAG server also provides several levels of security, such as Application Inspection and Filtering (Headers, URLs, Parameters and Content) and Authentication Denial of Service (DoS), to protect the federation server, the Active Directory server, and the CRM server from external attacks. Implementing this architecture provides both a Single Sign On experience and a full audit trail from the Internet to the internal CRM server.

Sample DeploymentAdatum and Treyresearch are two organizations that need to access the same CRM service. The network at Treyresearch includes the CRM application, Active Directory, and an IAG Server, while the Adatum network includes Active Directory and clients. The primary goal of the intended solution is to provide secure access from Adatum to the CRM server in Treyresearch by using Adatum credentials, which in turn will reduce the effort required to manage IDs and passwords at Treyresearch.The following diagram illustrates a high-level architecture to accommodate the business requirements of this scenario.


Adatum Organization (Account Domain)Accounts in the Adatum organization (which has no trust relationship with Treyresearch) require access to the CRM application in the Treyresearch organization by using their Adatum credentials with a Single Sign On experience and full audit trail.The solution implemented at Adatum includes the following components:

Domain Controller (Active Directory 2003)o Windows Server 2003 R2 SP2o .NET 2.0 and .NET 3.0o Federation Service (FS-R)

Client computer (Windows XP, Windows Vista)Treyresearch Organization (Resource Domain)The Treyresearch organization contains an internal CRM application that serves users from Adatum organization (which has no trust relationship with Treyresearch). The IT managers in Treyresearch want to avoid having to manage the IDs and passwords associated with the Adatum users.The solution implemented at Treyresearch includes the following components:

Domain Controller (Active Directory 2003)o Windows Server 2003 R2 SP2o .NET 2.0 and .NET 3.0o Federation Service (FS-A)

Microsoft Dynamics CRM 4.0 server IAG 2007 with Service Pack 2 server

Sample FlowThe following diagram illustrates high level architecture and authentication flow:


Detailed FlowThe following diagram illustrates the authentication flow in greater detail:

The following steps provide additional information about each of the steps that are associated with this authentication flow.

1. Mark, a user at Adatum ([email protected]), navigates to the IAG server at the following URL:https://adfsiag.treyresearch.net

2. The Secure Channel (SChannel) client (Browser) sends an HTTP request to the IAG server, which responds with information necessary to authenticate itself; the SChannel client (Browser) and the IAG server exchange session keys, and then SSL Secure communication begins between the browser and the IAG server.


3. The IAG server sends an HTTP 302 Redirect to https://adfsresource.treyresearch.net (another trunk/portal on the IAG server).

4. The IAG server establishes an SSL connection (following the steps described above) to the Treyresearch Federation Server (FS-R).

5. After the authentication, first-time users are presented with a Web page prompting them to identify the realm (Adatum or Treyresearch) to which they belong.

Note: This page is presented to the user one time (cookie) after successful authentication; no prompt appears for subsequent entries to the system. When a user accesses resources from within the organization and the user’s browser recognizes the URL as part of Intranet zone or trusted site, the user is automatically authenticated by using Integrated Windows Authentication, and this page will not appear on this screen.For information about customizing the Client Logon and Real Discovery pages, on MSDN, see Customizing Client Logon and Home Realm Discovery Pages at:http://msdn.microsoft.com/en-us/library/bb625464(VS.85).aspx


http://msdn.microsoft.com/en-us/library/bb625464(VS.85).aspx

6. Depending on the home realm choice in step 5:a. For users who specify the Adatum realm (which represents a Treyresearch

partner organization that has an ADFS trust set up), the IAG server sends an HTTP 302 Redirect to https://adfsresource.treyresearch.net/, and then the FS-R sends an HTTP POST 302 redirect to https://adfsaccount.adatum.com (FS-A), which is located in the Adatum organization.The FS-A then prompts the user, via an HTTP 401 (Negotiate/NTLM), for credentials that are valid in the Adatum organization. Continue to step 7a.Note: For user access requests subsequent to the initial successful authentication process, the FS-R will send HTTPGET 302 Redirect to the FS-A (401 authentication page).

b. For users who specify the Treyresearch realm (which represents the local realm), the IAG server sends HTTP 302 Redirect to https://adfsresource.treyresearch.net/ with indication that the user belongs to Treyresearch realm, and then FS-R prompts the user with a form-based authentication page for credentials that are valid in the Treyresearch organization. Continue to step 7b.Note: For user access requests subsequent to the initial successful authentication process, the FS-R will send HTTP GET 302 Redirect to itself (form-based authentication page).

Note: This scenario typically happens when users are outside the corporate network and therefore are not automatically authenticated in step 5.

7. The authentication flow proceeds according to the realm selected; for users who specify that they are members of the:

a. Adatum realm, FS-A validates the credentials, issues a valid SAML token (Kerberos to SAML), replaces the UPN [email protected] with [email protected], and then validates the signature of the SAML token from Adatum by sending an HTTP POST to https://adfsresource.treyresearch.net.

b. Treyresearch realm, the FS-R validates the credentials, issues a valid SAML token, and then validates the signature of the SAML token from Adatum by sending an HTTP POST to https://adfsresource.treyresearch.net.

8. FS-R sends an HTTP POST 302 Redirect to https://adfsiag.treyresearch.net (ADFS/Login.asp) with the valid SAML token, and IAG checks whether or not the user


authenticated. If the user did not authenticate successfully, the user receives an error page from IAG.

9. The IAG Portal (Login.inc) sends an HTTP GET 302 redirect to /ADFS/auth/validatetrampoline.asp, which:

a. If ADFS group-to-group mapping is configured, tries to identify the user's groupb. If ADFS group-to-group mapping is not configured, adds only the logon user to the

session10. The IAG Portal (validatetrampoline.asp) sends an HTTP GET 302 redirect to

/ADFS/validate.asp to validate the user credentials, and then the validate.inc hook adds the ADFS groups to which the user belongs in the resource domain to the user's session and adds the user to the session.

11. The IAG server performs (Kerberos Constraint Delegation Protocol Transition) authentication for the UPN (user) [email protected] and requests a Kerberos ticket to the HTTP service on the CRM server from the Treyresearch Active Directory on behalf of the user and then forwards the Kerberos ticket (Which comes from Domain Controller) to the CRM Server.Below is an example of the Kerberos request and response structure for the user Mark:

AS-REQ [email protected] SF4U2SelfTGS-REP

In the IAG interface, CRM appears as a published application, so users can now access the CRM application by using the credentials associated with their own organization (Adatum or Treyresearch) with a full SSO experience and full audit trail.Note: For more information about accessing the audit trail created by IAG, on TechNet, in the Forefront Edge Security Techcenter, see the article IAG Monitoring and Logging at:http://technet.microsoft.com/en-us/library/dd278015.aspx


http://technet.microsoft.com/en-us/library/dd278015.aspx

Implementing an ADFS Solution for CRM by Using IAGPrerequisitesWhen planning to implement an ADFS solution for Microsoft Dynamics CRM 4.0 by using IAG, be sure to account for the following prerequisites.

Set the domain to the Windows Server 2003 functional level, as described in the article How to raise domain and forest functional levels in Windows Server 2003 at:(http://go.microsoft.com/fwlink/?LinkId=123084)

The IAG server must be domain member of Active Directory forest in which the applications (resources) are located.

When publishing ADFS, IAG supports ADFS v1 NT-tokens mode, which requires that shadow accounts be configured in the Active Directory forest associated with the resource domain. IAG supports user-to-user and group-to-user mappings between the users’ forest and resource forests. Note that we only need to create these accounts; there is no need to synchronize passwords between the resource and account domains.Tip: You can use InterOrgPerson attribute for "Light" shadow accounts and rather than a regular user account.Note: For more information please refer to Determine your resource account mapping method at: (http://technet.microsoft.com/en-us/library/cc779214(WS.10).aspx)

IAG requires that Federation Server Proxy (FS-P) be implemented on the IAG server.Note: For more information on implementing ADFS on IAG, see the article Enabling Active Directory Federation Services in IAG SP2 at:(http://technet.microsoft.com/en-us/library/dd353186.aspx)

If your application supports ADFS authentication, you can allow users to authenticate directly to the application by using ADFS; simply do not enable authentication delegation on IAG (pass-through authentication).

If your application does not support ADFS, you can use Kerberos constrained delegation (KCD), described later on, to provide Single Sign-On experience and full audit trail to your partners’ users.Note: Additional information about Kerberos constrained delegation appears in the section Configuring Kerberos Constrained Delegation for the CRM Application.

Overview of the Implementation ProcessThe process for implementing an ADFS solution for Microsoft Dynamics CRM 4.0 by using IAG involves the following major steps:

1. Implement ADFS2. Implement IAG 20073. Configure Active Directory for Delegation4. Publish ADFS by using IAG

a. Configure an IAG portal trunkb. Configure ADFS with IAG

5. Publish Microsoft Dynamics CRM 4.0 by using IAGa. Configure Kerberos constrained delegation for the CRM application

6. Manage user operations on CRM from non-compliant endpoints (scenario-dependent)Implementing ADFS16IMPLEMENTING AN ADFS SOLUTION FOR MICROSOFT DYNAMICS CRM 4.0 BY USING IAG JULY 2009


http://technet.microsoft.com/en-us/library/cc779214(WS.10).aspx

http://go.microsoft.com/fwlink/?LinkId=123084

To implement ADFS, see the following resources: Step-by-Step Guide for Active Directory Federation Services

http://www.microsoft.com/downloads/details.aspx?familyid=062F7382-A82F-4428-9BBD-A103B9F27654&displaylang=en

ADFS Design and Deployment Guidehttp://www.microsoft.com/downloads/details.aspx?familyid=B92EA722-0C30-4EA6-BD45-7E5934B870CF&displaylang=en

Implementing IAG 2007 with SP2To install IAG 2007 with Service Pack 2 (SP2) as a virtual machine running on Windows Server 2008 with Hyper-V, see the following resources:

IAG Service Pack 2 system requirementshttp://technet.microsoft.com/en-us/library/dd282916.aspx

IAG deployment checklisthttp://technet.microsoft.com/en-us/library/dd278078.aspx

Installing IAG with Service Pack 2 as a virtual machinehttp://technet.microsoft.com/en-us/library/dd282917.aspx

Note: You can also install IAG Service Pack 2 on an existing IAG hardware appliance. For more information, see Installing IAG Service Pack 2 on a hardware appliance at:http://technet.microsoft.com/en-us/library/dd278089.aspxConfigure Active Directory for DelegationBefore you can configure IAG to support ADFS, you must configure Kerberos Constraint Delegation (KCD) in the Active Directory in the resource domain (Treyresearch in the sample deployment) for the IAG computer account. This will allow the delegation of Kerberos tickets to the CRM server on behalf of the user. To configure delegation for the IAG computer account, perform the following steps:

1. In Active Directory Users and Computers, navigate to and then right-click on the IAG computer account, and then click Properties.

2. In the Properties dialog box, on the Delegation tab, select Trust this computer for delegation to specific services only, and then select Use any authentication protocols.

3. Click Add, select the CRM computer account, and then click OK.4. For the Service Type, select http, click OK to close the Add Services dialog box, and

then click OK to close the Properties dialog box.Publishing ADFS by Using IAGConfiguring an IAG Portal TrunkPrior to configuring any applications to use ADFS, create an IAG portal trunk (configured to use Active Directory authentication) that publishes the applications that ADFS will access, and then verify that client endpoint access to those applications is working as expected.Note: To configure an IAG portal trunk, on the Forefront Edge Security TechCenter site, see the article Publishing applications in an IAG portal at:http://technet.microsoft.com/en-us/library/dd278153.aspxConfiguring ADFS with IAGTo configure ADFS with IAG, perform the following steps:







http://www.microsoft.com/downloads/details.aspx?familyid=B92EA722-0C30-4EA6-BD45-7E5934B870CF&displaylang=en




1. After verifying that an ADFS server is installed, in ADFS, add the IAG portal as a Windows NT token-based application.

2. Configure an IAG trunk as a proxy for the ADFS server; IAG publishes the ADFS server and protects it by inspecting the ADFS traffic flowing through IAG to the ADFS server.Important: To access ADFS, the portal trunk requires different external address (for example, the address in step 1), running a script, and an ADFS proxy IAG trunk.

3. On the IAG server, install the ADFS Web agent as a Windows component, and then configure IIS to support federation.

4. Run the ADFS configuration tool.To test the configuration, create an entry in the hosts file to resolve the IP address and name of the ADFS server. Verify that members of the Active Directory group can log on to the IAG portal. After verifying that access functions as expected, you can optionally set up authorization to limit access to specific applications to members of the Active Directory group for ADFS access. Afterwards, be sure to verify that client endpoint access works as expected.Note: For more information about how to publish ADFS by using IAG, on the Forefront Edge Security TechCenter site, see Enabling Active Directory Federation Services in IAG SP2 at http://technet.microsoft.com/en-us/library/dd353186.aspxPublishing Microsoft Dynamics CRM 4.0 by Using IAGPublishing Microsoft Dynamic CRM 4.0 by using IAG 2007 with Service Pack 2 allows for remote access to your CRM implementation.To publish Microsoft Dynamics CRM 4.0 by using IAG, perform the following steps:

1. Create a new IAG application by using the Services menu or right click on the trunk under the HTTP or HTTPS Connections in the navigation tree.

2. In the Add Application wizard, on the Select Application page, select Web Applications, in the list, select Microsoft Dynamics CRM 4.0, and then click Next.

3. On the Web Servers page, in the Addresses box, enter the address of the server, and then in the Organization box, enter the organization name.Note: The organization name is a logical name representing the organization; it is defined in the CRM Deployment Manager, under the Organizations folder. An application server might have more than one organization name defined for it when several organizations share the same server. In such cases, type the organization names as a list below the address of the server.

4. Click Finish to close the Add Application wizard.Note: For information about how to publish CRM by using IAG, on the Forefront Edge Security TechCenter site, see Publishing Microsoft Dynamics CRM with IAG SP2 at http://technet.microsoft.com/en-us/library/dd278093.aspx




Configuring Kerberos Constrained Delegation for the CRM ApplicationThe only way to configure Kerberos constrained delegation on an existing application is by using the Web Settings tab of the Microsoft Dynamics CRM 4.0 application. If you are adding an application to the trunk by using the Add Application wizard, on the Authentication page, click Next to skip this step. When you complete the wizard, perform the following procedure.Note: To complete this procedure, you must know the application’s service principal name (SPN), or the name by which a client uniquely identifies an instance of a service. To determine the appropriate SPN, use the following command:

setspn –L machinename

For more information about SPNs, on MSDN, see the article Service Principal Names at:http://go.microsoft.com/fwlink/?LinkId=123632&clcid=0x409Each instance of a service that uses Kerberos authentication requires that an SPN be defined so that clients can identify that instance of the service on the network.To configure Kerberos constrained delegation for the Microsoft Dynamics CRM 4.0 application, perform the following steps:

1. On the IAG Configuration console, in the Applications group box, click the application, and then click Edit.

2. In the Application Properties dialog box, on the Web Settings tab, select Automatically Reply to Application-Specific Authentication Requests, and then click Use Kerberos constrained delegation.

3. In the Application service principal name text box, type the SPN, and then click OK.When specifying the SPN, keep the following points in mind.

Generally, you can set the SPN explicitly or use the wildcard character * (e.g., crm/*). If the application’s SPN was not defined in the default format (service name/hostname)

in the application server, for example if an application is published as part of a load-balanced Web farm and runs with an application account identity and not with a computer account identity, then the SPN must be specified explicitly.

When using the wildcard character in specifying the SPN, the addresses for all the servers of the application (defined on the Web Servers tab) must be host names rather than IP addresses. The wildcard character is translated to each of the host names defined on the Web Servers tab.

If the SPN of the application in the application server is defined as a fully qualified domain name (FQDN), then IAG translates it into two SPNs: hostname and FQDN (for example, owa and owa.contoso.com).

If the application's SPN in the application server is defined as a hostname, then IAG translates it into two SPNs: a hostname and an FQDN with the IAG Domain Name System domain.

Note: For information about how to Configuring Kerberos constrained delegation with IAG SP2, on the Forefront Edge Security TechCenter site, see Configuring Kerberos constrained delegation with IAG SP2 at:http://technet.microsoft.com/en-us/library/dd278107.aspx#ConfigADforKCD

Manage User Operations on CRM from Non-compliant Endpoints19

JULY 2009 IMPLEMENTING AN ADFS SOLUTION FOR MICROSOFT DYNAMICS CRM 4.0 BY USING IAG

http://technet.microsoft.com/en-us/library/dd278107.aspx#ConfigADforKCD

http://go.microsoft.com/fwlink/?LinkId=123632&clcid=0x409

After adding the CRM application to the trunk, in certain scenarios you may need to modify the dedicated Microsoft Dynamics CRM 4.0 policies to comply with the security policy requirements of your organization.The following table lists the operations that can be controlled by using endpoint policies.Operation PolicyPrevent end users from exporting to Microsoft Office Excel® and printing.

Microsoft CRM 4 Enhanced Security

Preventing end users from uploading, checking in files, and saving files from Microsoft Office applications to the CRM server.

Microsoft CRM 4 Upload

Preventing end users from downloading files, exporting to a spreadsheet, or editing datasheets.

Microsoft CRM 4 Download

Note: By default, these policies are set to True, so that users can perform each operation.To prevent users from performing these operations unless their computers meet the defined security policy requirements, perform the following steps:

1. In an area where you assign policies in the new application wizard or on the application property pages, click Manage Policies.

2. In the Manage Policies and Expressions dialog box, select the application-specific policy (from the policies described in the table above), and then click Edit Policies.

3. Use the Policy Editor to modify the policy to address your requirements.Note: For more information, see Managing IAG client endpoint policies at http://technet.microsoft.com/en-us/library/dd278045.aspx.



Appendix A: Additional ResourcesFor additional information related to implementing an ADFS solution for Microsoft Dynamics CRM 4.0 by using IAG, see the following additional resources.ADFS

Step-by-Step Guide for Active Directory Federation Serviceshttp://www.microsoft.com/downloads/details.aspx?familyid=062F7382-A82F-4428-9BBD-A103B9F27654&displaylang=en

ADFS Design and Deployment Guidehttp://www.microsoft.com/downloads/details.aspx?familyid=B92EA722-0C30-4EA6-BD45-7E5934B870CF&displaylang=en

IAG About Intelligent Application Gateway 2007

http://technet.microsoft.com/en-us/library/cc303240.aspx IAG Monitoring and Logging


CRM IAG SP2: Securely Publishing Dynamics CRM 4.0

http://blogs.msdn.com/crm/archive/2008/11/06/iag-sp2-securely-publishing-dynamics-crm-4-0.aspx





http://technet.microsoft.com/en-us/library/cc303240.aspx





Date post:	27-May-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

Implementing an ADFS Solution for Microsoft...

Documents