This article stems from an article written from a SharePoint PFE, Jason Vallery. There have been changes to include certain scenarios or to provide more details on CRM specific items. The original can be found here:
http://blogs.msdn.com/b/javaller/archive/2014/01/13/publishing-crm-internet-facing-deployment-using-web-application-proxy-and.aspx
Windows Server 2012 R2 introduces a new service called Web Application Proxy (WAP). This service acts as a reverse proxy and as an ADFS proxy:
http://technet.microsoft.com/en-us/library/dn584113.aspx
The recommendation is to have a WAP server for any applications being accessed from the internet and using ADFS authentication, such as Microsoft Dynamics CRM with Internet Facing Deployment (IFD), rather than exposing actual ADFS servers to the internet. In order for the authentication to flow properly, there are configurations to WAP that must be made.
Microsoft Dynamics CRM utilizes multiple endpoints since we can have multiple servers host different services. Microsoft Dynamics CRM has endpoints for the Web Application service, Organization Web Service, and Discovery Web Service. Additionally, we must specify the external domain which is most commonly known as the Auth endpoint as the endpoint is prefaced with auth in front of the domain name for the Web Application Service. This is all documented in the Claims document found here:
http://www.microsoft.com/en-us/download/details.aspx?id=41701
By default, a deployment with a single organization will have three different endpoints:
Organization: https://ORG.contoso.com
Discovery: https://dev.contoso.com
Auth: https://auth.contoso.com
If an administrator wishes to have Microsoft Dynamics CRM exposed to the internet, each of these URLs need to be accessible from the internet. If you are using WAP, this means that each of the Microsoft Dynamics CRM URLs will need to be published along with the ADFS proxy URL (https://adfs.contoso.com). To understand how to do this within WAP, please review the following WalkThrough:
http://technet.microsoft.com/en-us/library/dn280943.aspx
The rest of this article comes from the aforementioned article posted in the beginning notes:
The default configuration of WAP is to translate internal URLs to external URLs when you do pass-through authentication. We had configured the org URL as ADFS pre-auth. The discovery and auth URLs both used pass-through authentication. The external and internal names were the same and we used split DNS to handle internal versus external traffic.
The way CRM does authentication when using an internet facing deployment and ADFS is with the HTTP POST binding back to the auth URL. The auth URL issues a DOMAIN cookie and redirects to the org URL. In our case the domain cookie was scoped to *.crm.contoso.com. The org web application gets the cookie and lets the user in.
This breaks down with WAP because it attempts to remap the outbound cookie from the auth web application and reissue it under the external name (auth.crm.contoso.com). When we redirect to the org URL it can't see the cookie because the browser doesn't pass it back. The org URL then redirects back to ADFS, which redirects to auth, which reissues the cookie. As you can see we're stuck in an infinite redirect loop. Eventually ADFS gets tried of this and fails issuing the following error in the log:
Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '3' seconds. Contact your administrator for details.
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateLoopDetectionCookie(WrappedHttpListenerContext context)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.SendSignInResponse(WSFederationContext context, MSISSignInResponse response)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
The solution for this is to tell Web Application Proxy not to translate the outbound URLs in the response header. This can be done via powershell and the Set-WebApplicationProxyApplication cmdlet.
http://technet.microsoft.com/en-us/library/dn283415.aspx
Set-WebApplicationProxyApplication -ID <id of auth web app> -DisableTranslateUrlInResponseHeaders
Now WAP will ignore the outbound cookie and let it pass along to the client as CRM had intended. Presto!