Jaa


Publishing CRM Internet Facing Deployment using Web Application Proxy and

If you've been following the TMG/UAG product line for a while you'll know that those products
are end of life.   The official announcement was recently made on the Server & Cloud Blog <https://blogs.technet.com/b/server-cloud/archive/2013/12/17/important-changes-to-the-forefront-product-line.aspx>

I've been working on deploying Web Application Proxy with one of my customers recently in an effort to transition them off UAG.   We were successful in getting SharePoint working quickly but we ran into some problems with CRM.   Given how new WAP is I thought it would be appropriate to document what we had to do in order to get it working.

The customer has 3 externally facing URLs that we need to publish via WAP:

https://auth.crm.contoso.com/

https://org.crm.contoso.com/

https://discovery.crm.contoso.com/

 

Additionally WAP and ADFS are published at

https://fs.contoso.com/

 

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.

 

https://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!

Comments

  • Anonymous
    January 13, 2014
    Just wondered have you managed to get the CRM Mobile app work externally via this method?

  • Anonymous
    January 19, 2014
    So, you set all three published rules to "DisableTranslateUrlInResponseHeaders", correct? I can not make CRM mobile apps working (WP8, Nexus 7). WP8 app got IIS error on CRM server. Nexus 7 app show blank screen after ADFS login page and no error in servers log.

  • Anonymous
    January 20, 2014
    Hi Dan/Vladimir, To clarify -

  1. Set DisableTranslateUrlInResponseHeaders for all 3 published URLs
  2. Ensure you're not using ADFS pre-auth.   We ran into a problem with the Outlook connector not handling the 307 redirect correctly.   It worked fine when we disabled the pre-auth piece. I haven't tested the Android app but it worked great for iOS and Windows Phone.   Can you post back the error you're getting? -JV
  • Anonymous
    January 20, 2014
    As you mentioned, my org rule has adfs pre-auth. Dev and Auth - pass-through. Do I need to set all three rules to pass-through?

  • Anonymous
    January 20, 2014
    The comment has been removed

  • Anonymous
    January 20, 2014
    Yes - we found that we had to set all 3 to pass-through for the clients to work.   The problem is that the client calls the Discovery.WSDL on the organization URL.   If pre-auth is enabled a 307 is returned which the client doesn't know how to handle.   If you disable pre-auth it should 302 redirect to ADFS instead which works.

  • Anonymous
    January 20, 2014
    3 publishing rules (pass-through) with Set DisableTranslateUrlInResponseHeaders - CHECK Win8 CRM Apps works - CHECK Android CRM App works - CHECK Thank you VERY VERY much!

  • Anonymous
    January 20, 2014
    The comment has been removed

  • Anonymous
    January 22, 2014
    Dan -   Can you email me a fiddler trace?   javaller@microsoft.com Thanks

  • Anonymous
    January 29, 2014
    Got it all working now Jason :) Forgot to add Oauth to ADFS Client ....doh

  • Anonymous
    January 29, 2014
    The comment has been removed

  • Anonymous
    April 10, 2014
    I have the same problem, could anybody help? $fedurl = Get-CrmSetting -SettingType ClaimsSettings $fedurl.FederationProviderType = 1 Set-CrmSetting $fedurl and then Get-CrmSetting -SettingType ClaimsSettings, the FederationProviderType stays 0 for some reason.

  • Anonymous
    July 04, 2014
    Ok publishing CRM using WAP without preauth is not a big deal, Have you tried to use WAP with ADFS for Preauthentication and then using Kerberos contraint delegation to access the internal CRM page ?.  This looks much more interesting than using a simply anonymous reverse Proxy.

  • Anonymous
    August 22, 2014
    I'm confused.  The title of your article is "Publishing CRM Internet Facing Deployment using Web Application Proxy", yet I can't any information in the article itself or any links that explain how to Publish CRM Internet Facing Deployment using Web Application Proxy.  Do you have another document somewhere that explains how to do this using a step-by-step method, or a link to a similar document?

  • Anonymous
    April 22, 2015
    The comment has been removed

  • Anonymous
    July 21, 2015
    Quick question, I  was able to get Claim Base Auth working internally, but I guess i'm failing to see the how a couple pieces of the puzzle fit together. I setup the rules in ADFS for IFD, and configured it to point to the AUTH address, which does pull up correctly. Next I'm must be over looking something here, how does the external addresses know to work together? ie how does the external CRM Org address, when using passthrough, know that it must use the IFD rule set to get back to the WAP?

  • Anonymous
    September 16, 2015
    Has anyone managed to publish Dynamics CRM 4 (on windows 2008R2) with WAP running on a win2012 server (the old ISA 2006 host)? my scope is only to upgrade the windows OS for now and next year to upgrade the CRM version.... so as a replacment for the ISA I'm considering only upgrading the ISA server OS to 2012 and use the WAP to do the ISA's reverese proxy and AD authentication roles.

  • Anonymous
    January 06, 2016
    Facing this error in ADFS server and redirection wot CRM dyanmics Dashboard is failed. Protocol Name: Saml Relying Party: Exception details: Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '11' 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) Any ideas how to solve it. Already tried Set-WebApplicationProxyApplication -ID <id of auth web app> -DisableTranslateUrlInResponseHeaders This doesnt seem to work, any other ideas??