Jaa

Using a Third-Party Proxy as a Replacement to an AD FS 2.0 Federation Server Proxy

  • Artikkeli

Applies To: Active Directory Federation Services (AD FS) 2.0

Microsoft Active Directory Federation Services (AD FS) 2.0 is a security token service (STS) that enables identity federation. AD FS 2.0 extends the notion of centralized on-premises Active Directory authentication, authorization, and single sign-on (SSO) to corporate users that are requesting access to Web applications and services located virtually anywhere, including perimeter networks, partner networks, and the cloud.

This SSO functionality is made possible when you deploy a federation server farm in your internal network and set up the Federation Service. Federation servers will validate incoming authentication requests, and then generate and sign the tokens that will be consumed by applications to determine the user’s level of access.

Using an AD FS 2.0 Federation Server Proxy

An AD FS 2.0 federation server proxy is used to complement the federation server when there is need for the STS to be exposed to the internet for extranet access. The federation server proxy is a lightweight component that forwards requests from the extranet to the internal federation server. It is designed to be secure and provides the ability to configure an authentication mechanism that is distinct from the intranet.

For example, the internal federation server may be configured for windows integrated authentication for web applications whereas the federation server proxy may be configured for forms-based (username/password) authentication or smartcard authentication.

When a client authentication request is made using the Transport Layer Security (TLS) authentication method (For example, two-factor authentication request using a smart card), the AD FS 2.0 federation server proxy can successfully process the request because it has built-in mechanisms to terminate this at the edge and securely communicate back to the federation server.

Using a Third-Party Proxy

While we primarily recommend that you deploy and use an AD FS 2.0 federation server proxy, you might prefer to use an existing reverse HTTP proxy in your extranet in favor of deploying an AD FS 2.0 federation server proxy.

Note

Most third-party proxies do not support client TLS authentication at the edge. If this is required, you must deploy an AD FS 2.0 federation server proxy.

Note

The support for blocking all extranet access but allowing only browser based applications like SharePoint Online and Outlook Web Access using client access policy control rules is not supported with third-party proxies.

AD FS 2.0 requirements for third-party proxies to communicate with federation servers

In order for third-party proxies to successfully interact with your internal federation servers, you must first configure your third-party proxies to meet the following list of requirements. A list of test cases specific to Microsoft ® Office 365 is supplied later in this document to help with the validation.

Note

The provided requirements should be considered general guidance for communications between federation servers and third-party proxies. It is highly recommended that you first validate these steps end to end with your specific third-party proxy documentation before configuring it for AD FS 2.0 in your production environment.

  1. The proxy MUST NOT modify response bodies

  2. The proxy MUST flow through all HTTP headers that it received to the back-end STS. The proxy MAY choose to augment additional HTTP headers if needed.

  3. For active protocol communications:

    1. Proxy MUST not issue 302’s in response as rich clients cannot handle this.

    2. For all requests /adfs/services/trust, the proxy MUST pass thru the request to AD FS and the respective response back to the client.

    3. Special case: The MEX information is distinct for the extranet. To accommodate this, all external requests to the URL /adfs/services/trust/mex MUST be rerouted to /adfs/services/trust/proxymex on the back-end STS.

    4. In the case of using the Windows Integrated Active endpoint (will be negotiated to NTLM based on the client request), the proxy MUST ensure that it is talking to the same STS to complete the multi-legged NTLM authentication flow.

  4. For passive protocol communications:

    1. All requests to /adfs/ls MUST be re-routed to the same URL on the back-end STS. Note that if the internal STS is configured for Windows integrated authentication, this will result in a NTLM prompt to enter the credentials. The proxy MUST ensure that it is talking to the same STS to complete the multi-legged NTLM authentication flow.

Note

When challenged with NTLM, non-IE browsers (For example, Chrome, Firefox) may not support the use of Extended Protection Authentication (enabled by default in AD FS 2.0) within their NTLM implementation. To avoid this, we recommend a configuration to adopt #4c or #4d as a mechanism to use forms-based authentication. 

2.  The proxy MUST flow through all query string parameters that it receives from an incoming request to the back-end STS.  
      
3.  To provide a better user experience using forms-based login instead of an NTLM prompt, the proxy MAY parse the message to determine the protocol (WS-Fed OR SAML-P) and add an authentication method that is conformant to the protocol. This is ‘wauth’ in WS-Fed and ‘AuthNContext’ in SAML-P. Note that this is not feasible for signed SAML-P requests.  
      
4.  The proxy MAY also collect its own credentials and perform an NTLM authentication to the /adfs/ls page while preserving all protocol parameters that may be present in the query string or in the body.  
      
5.  The proxy MAY also perform its own two-factor authentication for any traffic that is targeted towards the /adfs/ls page and use Kerberos Constrained delegation to talk to the STS using Windows Integrated Authentication. Note that in this case, all traffic to the active endpoints of the STS must still honor the requirements in \#3.

  1. For federation metadata access from the extranet:

    1. All requests to /federationmetadata/2007-06/federationmetadata.xml MUST be rerouted to the same URL on the back-end STS.

  2. Additional Authentication mechanisms at the edge:

    1. The proxy MAY choose to authenticate using additional credentials like two-factor authentication. If this is needed, it can only work for web applications that authenticate over passive protocols as specified in requirement #4 (requests to /adfs/ls). Note that in this case, all traffic to the active endpoints of the STS must still honor the requirements in #3.

  3. For support of Office 365 client access policy scenarios:

    With the availability of the AD FS 2.0 Rollup 1 Update, AD FS 2.0 supports the ability to create policies that limit access to Office 365 services that depend on the location of an Office 365 client. This is achieved by utilizing HTTP headers in traffic originating from the extranet as well as adding new relying party trust claims issuance authorization rules in AD FS 2.0. Therefore, to support client access policy scenarios, a third party proxy must be configured to provide additional information through HTTP headers. For more information about what additional HTTP header information is needed, see Limiting Access to Office 365 Services Based on the Location of the Client.

    1. An HTTP header (“X-MS-Proxy”) MUST be added to any request under /adfs. The value of the header should be the proxy machine host name. For example, the following header would be added to a request which is handled by a proxy running on PROXY-MACHINE: ‘X-MS-Proxy = PROXY-MACHINE’

Note

The support for blocking all extranet access but allowing only browser based applications like SharePoint Online and Outlook Web Access using client access policy control rules is not supported with third-party proxies.

Testing Office 365 SSO Access with a Third-Party Proxy

If you have deployed AD FS 2.0 and enabled SSO with Office 365 using the steps in Single sign-on: Roadmap and want to use a third-party proxy as a replacement for an AD FS 2.0 federation server proxy, then we recommend that you perform the following tests before making the switch over in the production environment:

Test to perform Expected result

Access OWA for your organization from the extranet

You should observe a NTLM prompt for credentials after which access should be granted. If requirement 4c is met, you will observe a forms-based login page that will require the user to enter their login ID and password after which access should be granted.

Access Outlook from the intranet

You will be prompted to save credentials in Outlook after which access should be granted.

Access Lync initially from the intranet and then access Lync from the extranet after a period of 10 hours

You should observe continued seamless authentication to the Lync service.

If you are using client access policy scenarios, verify that the listed scenarios that can be deployed are tested and validated

Clients should only be able to access Office 365 services from within policy-specified locations. For more information about client access policy scenarios, see Limiting Access to Office 365 Services Based on the Location of the Client.