locked
Dynamics 2016 IFD use same internal and external URL RRS feed

  • Question

  • Hi all

    We have setup an internet-facing deployment of Dynamics 2016 and all works fine.  We can connect successfully internally and externally using the following URLs:

    Internal: internalcrm.domain

    External: orgname.domain

    However we want to use the same URL for both to avoid confusion as our users work both internally and externally throughout the day.  I've messed about with URL redirect and CNAMEs so that internal users use the external URL but should then be directed to the internal URL.  This kind of works in that they are directed to our ADFS URL when they enter the external CRM URL but it doesn't automatically sign them into ADFS.  They have to enter their credentials and then it logs them into CRM.

    My question is, is there a way to make the internal clients log int automatically when they get redirected to ADFS.  Our ADFS and CRM URLs are in our intranet zone and ADFS automatically logs users in when we use Office 365.  I assume it's not doing it here because the external URL (orgname.domain) is displaying in the connection string when they're directed to ADFS so ADFS sees it as an external connection and displays the form authentication to log into ADFS?  Does this mean that my URL redirect isn't working (this is shown below):

    <rule name="Redirect Internal Connections" stopProcessing="true">

    <match url="https://(.*)" />

    <conditions trackAllCaptures="true">

    <add input="{REMOTE_ADDR}" pattern="192\.168\.[0-9]{1,3}\.[0-9]{1,3}" />

    <add input="{HTTP_HOST}" pattern="([^\.]*)\.(.*)" />

    </conditions>

    <action type="Redirect" url="internalcrm.domain/{C:1}/{R:1}" appendQueryString="true" redirectType="Found" />

    </rule>

    I've checked the REMOTE_ADDR pattern and this corresponds to our internal subnet.

    Any advice would be gratefully received.

    Tuesday, May 16, 2017 8:55 AM

Answers

  • As you guys are only on to, it's duo to CRM is passing the "wauth=urn:oasis:names:tc:SAML:1.0:am:password" parameter to ADFS when accessing the IFD url.
    If you take a look in fiddler or simply in your IE address field you will see this parameter.
    You can see that you can login in just fine with WIA(if enabled on ADFS) if you remove "wauth=urn%3aoasis%3anames%3atc%3aSAML%3a1.0%3aam%3apassword" found in the address field while hitting the ADFS sign-in page.

    I'm not sure why Microsoft hasnt at least made this a configurable option to disable it and let the STS(ADFS in our case) handle what type of authentication method(Windows authentication, Forms-based, Certificate etc) required to logon..
    Have tried sending them feedback regarding this, but nothing has come back on the subject sadly..

    So, you should be able to get around this by implementing URL rewrite and removing the wauth parameter.

    As a side note these values are found in the MSCRM_Config db under the table FederationProviderProperties.
    Of course the following is NOT supported change(All direct changes on the CRM db's are unsupported if not directly told by MS.)
    But I have in a dev. enviromnent tested by removing the values from IfdAuthenticationMethod(NavVarChar) and it works like a charm.

    But implementing URL Rewrite would be the safest path and perhaps you now have enough info to setup the rule for it.
    One can hope that Microsoft will sort this out in a later release.. But I doubt it.

    BR. /Philip

     

    • Marked as answer by gjayne Friday, June 2, 2017 8:33 AM
    Thursday, June 1, 2017 9:28 PM

All replies

  • I'm fairly sure that CRM uses the http headers to determine whether the request came from an internal or external url. Does the redirect change the http headers within the request ? If not, that would explain this behaviour

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

    Tuesday, May 16, 2017 10:08 AM
    Moderator
  • Hi David

    Thanks for the swift response.  I've just used Fiddler and when the responses are passed to CRM and ADFS the host name is coming up as not being changed so is still showing the external hostname.  I've had a look but can't seem to find how to rewrite the actual host in the header as well as the URL.  is this possible in IIS?

    Tuesday, May 16, 2017 11:10 AM
  • You can modify host headers in IIS using URL Rewrite rules. I've not used them in this scenario, but it should work. Here's one example, it's for CRM 2011, but the main claims and IFD architecture hasn't changed significantly since then, so I expect the technique would still work

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

    Tuesday, May 16, 2017 5:07 PM
    Moderator
  • As you guys are only on to, it's duo to CRM is passing the "wauth=urn:oasis:names:tc:SAML:1.0:am:password" parameter to ADFS when accessing the IFD url.
    If you take a look in fiddler or simply in your IE address field you will see this parameter.
    You can see that you can login in just fine with WIA(if enabled on ADFS) if you remove "wauth=urn%3aoasis%3anames%3atc%3aSAML%3a1.0%3aam%3apassword" found in the address field while hitting the ADFS sign-in page.

    I'm not sure why Microsoft hasnt at least made this a configurable option to disable it and let the STS(ADFS in our case) handle what type of authentication method(Windows authentication, Forms-based, Certificate etc) required to logon..
    Have tried sending them feedback regarding this, but nothing has come back on the subject sadly..

    So, you should be able to get around this by implementing URL rewrite and removing the wauth parameter.

    As a side note these values are found in the MSCRM_Config db under the table FederationProviderProperties.
    Of course the following is NOT supported change(All direct changes on the CRM db's are unsupported if not directly told by MS.)
    But I have in a dev. enviromnent tested by removing the values from IfdAuthenticationMethod(NavVarChar) and it works like a charm.

    But implementing URL Rewrite would be the safest path and perhaps you now have enough info to setup the rule for it.
    One can hope that Microsoft will sort this out in a later release.. But I doubt it.

    BR. /Philip

     

    • Marked as answer by gjayne Friday, June 2, 2017 8:33 AM
    Thursday, June 1, 2017 9:28 PM
  • Thanks for all the advice guys, it's all been really helpful and pointed me in the right direction to get this sorted.  As mentioned, we used URL rewrite to remove the "wauth..." part of the URL when passed through to ADFS from an internal client.  This successfully allows clients connected to our internal network to access Dynamics without having to sign in each time.

    The only downside to using the external URL for all users is that Dynamics/ADFS sees all users as using the external relying party trust so the toekn lifetime has had to be set to 8 hours for both internal and external clients.  This isn't ideal as usually external clients would be set to an hour but we'll have to live with this for the time being...

    Thanks again for all your help.

    Friday, June 2, 2017 8:33 AM