I'm sure everyone familiar with Dynamics CRM IFD deployments know of (and despise) the fact that users on the intranet/LAN hitting the IFD address https://org.crm.contoso.com will get a login form. No point in reiterating reasons for this, but lets agree that it's a sensible thing to do given mobility.
According to http://blogs.msdn.com/b/crminthefield/archive/2013/10/30/crm-2011-and-asp-net-single-sign-on-use-wauth-for-integrated-web-apps.aspx this is 'by design' due to the redirect query containing a wauth header instructing ADFS to present the login screen because some developer decided 6 years ago that an IFD endpoint must mean external access. Pre ADFS 2012 R2 some folk even suggesting stripping the wauth header from IFD requests using IIS URL rewrite (https://www.dmcinfo.com/latest-thinking/blog/id/8743/single-sign-on-with-dynamics-crm-external-url), but as ADFS 3.0 no longer relies on IIS it's not an option in our environment without introducing more layers of indirection.
Consider for a minute that ADFS is perfectly capable of discerning between internal and external (ADFS / ADFS Proxy). ADFS can also clearly discriminate between Relying Parties in order to apply various rules, multi factor authentication, etc. So there should be no need to mess about with internal/external IP addresses or forcing internal/external behaviour based on using different endpoints - right?
I'd like to know why this 'login form' behaviour is forced with an IFD deployment or am I missing something obvious/major that makes this a requirement? I find this a less than sensible approach and unless I'm missing something major would appreciate an explanation for this behaviour and why we're (still) unable to change it or did I miss that chapter entirely and just waste 30s of your day?
*This post is locked for comments
I have the same question (0)
