locked
Dynamics CRM 2016 IFD http redirect to ADFS RRS feed

  • Question

  • We deployed CRM 2016 and configured IFD as well but the issue we have noticed is if we explicitly mention "HTTP" protocol in org url then its not redirecting to ADFS sign in page. just a basic windows prompt leading with error 401.1 - it does working fine and redirecting properly to adfs sign in page if we mention https. this behavior is only with CRM 2016.  CRM 2011 / 2013 / 2015 properly push to ADFS sign in page even with http.

    summary : CRM 2016 Only

    http://org.rootdomin.com   [not redirecting to adfs sign in page]
    https://org.rootdomain.com [working fine.]

    NOTE : both the combination [http and https] indeed working fine with CRM 2011, 2013 and 2015 update 0.2

    To fix this situation we have temporally added http to https redirect Rewrite Rule hooked with CRM website.

    is it a bug? or it is by design, if yes then why? what is the logic behind this...

    thanks.


    ja



    Thursday, January 7, 2016 12:36 PM

All replies

  • In my experience, what you saw prior to CRM 2016 is the exception. With IFD you'd expect the original request to be to https, and there needs to be something specific (such as a rewrite rule) to redirect an http request to https, and CRM will not do this automatically. I expect in your deployment(s) with previous CRM versions someone had added in a rewrite rule, or other redirection

    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Friday, January 8, 2016 11:11 AM
    Moderator
  • this is indeed an issue with CRM 2016. all legacy versions are working very fine with Same ADFS end points. rewrite rule not supposed to be there but due to this limitation in new version we have added the rule so end users can use the product without having any issues. 

    once claims and IFD configured on CRM node all requests must be forwarded to adfs sign in page regardless of the protocol [http or https]. this is what working up to CRM 2015 but with CRM 2016 only https requests redirecting to adfs sign in page not http requests.

    if we use http://org.rootdomain.com or https://org.rootdomain.com with previous version all calls/requests properly redirected to adfs sign in page which is expected. In CRM 2016 only https://org.rootdomain.com is redirecting but if we use http in the url we get a win prompt.

    we even tested CRM 2016 with a clean fresh install and also upgraded one of our CRM 2015 deployment but end result is same.

    thanks.


    ja



    • Edited by Ja08 Friday, January 8, 2016 2:26 PM
    Friday, January 8, 2016 2:14 PM
  • CRM IFD only supports https and not http. Also, CRM only supports one binding for the website. It may be that you previously had something to redirect http://org.rootdomain.com to https://org.rootdomain.com, but I don't think that's something CRM would do for you.


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Friday, January 8, 2016 2:42 PM
    Moderator
  • 1. it is recommended to use single binding. but both are fully supported.

    2. i am not taking about dual bindings here, it is all about redirection. try to understand and take a deep look at my first post.

    3. it seems that CRM 2016 has issues with http redirection OR there are some additional steps involved. we never added any rule to redirect http traffic to https in the previous versions. after an IFD configuration CRM is smart enough to take care of it. but there is something not working with CRM 2016. when i say issues with http, I mean http://........... not redirecting to adfs sign in page.

    anyone from MS CRM dev team can take a look at my initial post and respond?  or best is to configure CRM 2016 on-premise in lab env and check what i am trying to convey here ...

    thanks.









    • Edited by Ja08 Saturday, January 9, 2016 1:59 AM
    Friday, January 8, 2016 6:38 PM
  • Hi,

    I agree with David, I haven't seen an automatic redirect from http to https in any CRM from 2011 (when the IFD was changed, and I haven't worked with IFD on CRM 3 or 4).

    I would do a redirect on the CRM IIS from http to https.

    Regards


    Rickard Norström Developer CRM-Konsulterna
    http://www.crmkonsulterna.se
    Swedish Dynamics CRM Forum: http://www.crmforum.se
    My Blog: http://rickardnorstrom.blogspot.se

    Monday, January 11, 2016 7:36 AM
  • it does redirect to ADFS sign in page even with HTTP with lagacy versions 2011 / 2013 / 2015. leave CRM 3.0 / 4.0 because at that time we were using form auth without ADFS. we never added http to https redirect rules at IIS level for previous version.

    Thanks.


    ja

    Monday, January 11, 2016 8:06 AM
  • Re 'it is all about redirection'. I know that, but in your non-CRM 2016 implementation(s) you must have something configured to listen on http://org.rootdomain.com , otherwise the client will get a 404. This is most likely a binding in IIS, with a redirect/rewrite to https://org.rootdomain.com , though it could be some other network component listening on port 80.

    If you want to get a better understanding of what's happening, use a tool like Fiddler to check the network traffic


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Monday, January 11, 2016 4:29 PM
    Moderator
  • Already utilized fiddler but nothing was noticeable about authentication. Also nothing is configured on port 80. As I already mentioned that same configuration is working with previous CRM versions without any additional rewrite rules.

    the only thing we have noticed here is if you install CRM 2016 you can see extra rewrite rules in web.config. Not sure if these rules linked with this issue, perhaps these extra rules has nothing to do with this thread.

    by default the below rules are in place for ...

    CRM 2016 URL Rewrite :

    CRM 2016 Rewrite Rules

    ----

     CRM 2011/ 2013/ 2015 URL Rewrite:

    CRM 2015


    ja






    • Edited by Ja08 Tuesday, January 12, 2016 5:11 AM
    Monday, January 11, 2016 7:28 PM
  • Is it possible to see what fiddler gives on other versions where this works?

    Regards


    Rickard Norström Developer CRM-Konsulterna
    http://www.crmkonsulterna.se
    Swedish Dynamics CRM Forum: http://www.crmforum.se
    My Blog: http://rickardnorstrom.blogspot.se

    Thursday, January 14, 2016 6:57 AM
  • Here the Fiddler traces of CRM 2015 node. where it is working and properly redirecting http://.... to adfs sign in page.

    RAW:

    GET http://org2.domain.com/ HTTP/1.1
    Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, */*
    Accept-Language: en-US
    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729)
    Accept-Encoding: gzip, deflate
    Connection: Keep-Alive
    Host: org2.domain.com
    Cookie: ReqClientId=3a9d1053-b1d4-428e-8c5e-110857fd5840
    ..........

    HTTP/1.1 302 Found
    Cache-Control: private
    Content-Length: 154
    Content-Type: text/html; charset=utf-8
    Location: https://org2.domain.com/default.aspx
    Server: Microsoft-IIS/8.5
    X-AspNet-Version: 4.0.30319
    REQ_ID: 84fc592f-1adf-44ca-befd-73b96b2d3084
    X-Powered-By: ASP.NET

    Text View :
    <html><head><title>Object moved</title></head><body>
    <h2>Object moved to <a href="https://org2.domain.com/default.aspx">here</a>.</h2>
    </body></html>

    A SSLv3-compatible ServerHello handshake was found. Fiddler extracted the parameters below.


    CRM 2016 Fiddler Trace for http://......

    GET http://crm16.domain.com/ HTTP/1.1
    Accept: text/html, application/xhtml+xml, */*
    Accept-Language: en-US
    User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
    Accept-Encoding: gzip, deflate
    Connection: Keep-Alive
    Host: crm16.domain.com
    Cookie: ReqClientId=acd4cf71-b6e3-47e2-b70a-2ad069c959d7

    HTTP/1.1 401 Unauthorized
    Cache-Control: private
    Content-Type: text/html; charset=utf-8
    Server: Microsoft-IIS/8.5
    REQ_ID: 78499cf5-4386-4c5b-bd3c-dc16984dd581
    WWW-Authenticate: Negotiate
    WWW-Authenticate: NTLM
    X-Powered-By: ASP.NET
    Content-Length: 4838
    Proxy-Support: Session-Based-Authentication


    • Edited by Ja08 Thursday, January 14, 2016 7:51 AM
    Thursday, January 14, 2016 7:40 AM
  • Interesting, I had a look at a dev Environment for 2013 the other day and that doesn't redirect http to https.

    Rickard Norström Developer CRM-Konsulterna
    http://www.crmkonsulterna.se
    Swedish Dynamics CRM Forum: http://www.crmforum.se
    My Blog: http://rickardnorstrom.blogspot.se

    Thursday, January 14, 2016 8:18 AM
  • We are on CRM 2015 Onpremise IFD environment (UR 0.1), and if nothing (no website) is listening on port 80 - I get a 404 error when I access the http link.

    And then I have bind port 80 to CRM Website - after which, when I access the http link, it's getting redirected to ADFS login page and from there everything works normal.

    So, yes, I believe that CRM website has to listen on port 80 as well (multiple bindings supported I think!), in order for this to happen.

    Wednesday, February 24, 2016 12:18 PM
  • Hi-

    This very well could be IIS Authentication settings and site bindings at play.

    The Fiddler extract showing 401.1 response for crm16.domain.com, Where was this captured?  CRM Server or ADFS server?

    Thanks- BShastriCRM

    Monday, February 29, 2016 4:11 AM
  • Interesting, I had a look at a dev Environment for 2013 the other day and that doesn't redirect http to https.

    Rickard Norström Developer CRM-Konsulterna
    http://www.crmkonsulterna.se
    Swedish Dynamics CRM Forum: http://www.crmforum.se
    My Blog: http://rickardnorstrom.blogspot.se

    I believe that this might have something to do with how you configure the Domains in the IFD config for CRM. I am at present running CRM 2011, 2013, 2015 and 2016 in DEV and every one of them redirects to HTTPS from HTTP except for CRM 2016.  

    When you are setting the domain addresses in the IFD config, did you put :443 on the end of all addresses? It seems to be the key factor for me in the other versions except for CRM 2016. 
    Wednesday, March 2, 2016 5:13 AM
  • I'd love to hear from someone @ MS why on EARTH they would not think to build this into their installer?  I mean if they now essentially REQUIRE HTTPS (there are all sorts of problems without it), and if this many users are having this many issues with this issue, why not just build it in?  That would make the product work most effectively, reduce the burden on deployment admins and prevent support calls.  

    Don't they think about existing customers, especially legacy customers who've been using the product since the days when HTTP was good enough, or customers who did not previously want or need IFD, or the additional complexities of dealing with SSL certs, but now essentially HAVE to use them?

    We have an existing 2016 deployment which we initially had running HTTP and then we added SSL - but end users have thousands of existing HTTP links that we need to redirect - without asking end users to manually re-type URLs.

    I've now opened a case with MS CRM support, to speak to an 'expert' and they did not even know how to answer the simple question of 'how do you properly configure IIS to redirect HTTP user requests to HTTPS'.  They had to speculate and then told me they'd send some TechNet article, which they still haven't sent.  

    They also told me 'that's not supported', when I asked the very simple and logical question of, 'what should we do about non-technical end users who might inadvertently type in the server address and not remember to add https?'  

    They did not seem to grasp the concept that we have to deploy the product to meet the needs of the lowest common denominator of end user, who can be expected to do things like that.  Their 'solution' was actually to 'just train your end users'.  When I pointed out that just about every website on earth does a basic http to https redirect, they had no answer.  THIS IS MS CRM PAID TECHNICAL SUPPORT actually saying this!  Likely due to language barriers since MS has outsourced everything to overseas support.  Nothing against the overseas folks but if they aren't trained in basic communications (I'm assuming the technical stuff is a GIVEN), then they really aren't providing an effective solution.

    I've been reviewing blogs like this searching for answers on what the MS *approved* method is to accomplish this and everyone seems to have a different opinion.  But I want to implement the solution that MS says is *supported*, so that we don't later have to deal with them telling us 'oh, that's not supported'.

    I'm thinking there HAS to be some simple TechNet article for how to address this the MS-sanctioned way but I have yet to find it so if anyone else does, would love to see it!  Thanks in advance. 

    BTW: these two below looked good, but they're written for NAV/Sharepoint and one says 'there are several different ways to do this' so until I see something by MS, for CRM, I'm reticent to implement it - again, because MS has conditioned us to expect to be told 'that's not supported' and then blame the customer for trying to implement their own solution in the absence of something from MS - no matter how legitimateyour need for a solution may be.  Personally I think MS support has really gone downhill in the last year or so, likely all in the pursuit of increasing profitability.  

    https://msdn.microsoft.com/en-us/library/hh167264%28v=nav.90%29.aspx?f=255&MSPPError=-2147217396#Redirect

    https://blogs.technet.microsoft.com/dawiese/2016/06/07/redirect-from-http-to-https-using-the-iis-url-rewrite-module/



    Tuesday, January 24, 2017 5:29 PM