31 Responses to Configure CRM 2011 and ADFS 2.0 on a single server on port 443

  1. Simon Hetzel says:

    Have you tried this with a single IP but using HTTPS host-headers to distinguish between the sites? Curious to know if that can be made to work…

    • Adam Vero says:

      No, I have not tried doing this with host headers since there are already enough DNS names to worry about for internal URL + one per organisation for external access plus ADFS itself. Also not sure what the impact would be on firewall rules simply forwarding everything through to same IP and port, especially with more ‘active’ devices such as TMG. I was trying to come up with a method that can be followed every time (when needed) and reliably work.

      You can’t get round the need for separate URLs for all the CRM organisations for external access, as that is how ADFS determines this is an external logon and prompts for user credentials rather than requesting a Kerberos token for SSO which it does for internal access (where the org is determined by the folder on the end of the URL eg crm.internal.com/MyOrg – if none specified it will redirect to user’s default organisation).
      Also, if using https then whatever name is used has to match your certificate, so with multiple names it quickly becomes easier, cheaper and more manageable to use a single wildcard certificate (from an external trusted authority rather than self-signed) for all these services (and possibly others, such as SSRS).

  2. Simon Hetzel says:

    I don’t have a problem with the multiple hostnames – after all that’s what aliases are for – but I dislike having server adaptors with multiple IPs because of other problems that can then bring. It’s a personal thing I guess as there are pros and cons with each…

    I agree that it’s a pain that wildcards are STILL not supported in hostheaders in IIS. On the certificate side I beleive that a wildcard (or a SAN cert) is **required** to implement hostheaders with https. (Because IIS needs to decrypt the request from the client to figure out what hostname the client was using in the first place).

    I guess it’s unlikey that people trying to do this will have lots of CRM organisations to handle so the number of hostheaders should still be reasonably manageable. I’ll add it to my list of things to try one day…

    Thanks for your help Adam.

    • Adam Vero says:

      Thanks for your input! It would be interesting to hear back when you have a chance to test this.

      I have seen some reports of issues with multiple server IPs in some virtualised environments (usually older versions of hyper-V, from memory), but was able to use this approach with no problems at all in a recent ESX hosted deployment.

      As always, keeping it simple will usually result in better availability of the system and ease of maintenance, troubleshooting and so on. Two separate servers for CRM and ADFS is still probably easier for most deployments.

  3. Pingback: Did You Know, Dynamics CRM & xRM #16 « North52

  4. Mohammed JH says:

    I’m new to CRM but after deploying the server I now want to put it online instead of having internal access only.

    I need to know if it is mandatory to have multiple SAN certificate or Wildcard to do this or would it also work with one SAN certificate?


    • Adam Vero says:

      Short answer is no, you need a certificate which has lots of names on or just a wildcard one since there are so many different URLs you are trying to secure at the same time, for the user to access CRM internally eg myserver.mydomain.com/mycrmorg, or CRM externally mycrmorg.mydomain.com (a different URL), and ADFS eg sts.mydomain.com or adfs.mydomain.com, and for ADFS to talk to CRM at auth.mydomain.com and for third party apps or the Outlook client wizard to talk to at crmdev.mydomain.com. Of course you might have multiple organisations too (eg for dev, test, training, live).

      So you could use lots of individual certs for each of these but frankly that seems like too much work. A wildcard is always my preference

  5. Mukesh says:

    Hi…I have wild card certificate which is going to expire on 21st nov,2012.So please tell me what are the steps which I have to follow to to update certificate and ADFS 2.0.

    1.Does I have to attached renewed certificate again to default website and CRM website.

    2.Does I have to add these entry again to MMC for personal and Trusted certificate.

    If Not,then do let me know what are the steps that need to perform as still there are 20 days for certificate expiration.

    • Adam Vero says:

      You will have to import and associate the renewed certificate with your sites, and both CRM server and ADFS will need the public key in the personal store so they can encrypt data to be used at the other end.
      As a rule of thumb, a certificate which is actually renewed via a renewal request will work more easily than simply buying a new unrelated one which starts from the end of the previous one.

  6. Ian says:

    Hi Adam

    I felt compelled to write and thank you for this article as I have been pulling my hair out trying to get an ADFS test bed set up for use with a local network SSL wildcard system. I had been going round in circles with creating new sub domains for sites that had originally been created for the default site in IIS 7.5 on 2008, but was constantly getting the 503 Service Unavailable error. What your article helped prove was what the Microsoft uninstall program for ADFS doesn’t do! It fails to remove the reserved URLs from a server it has been originally installed on as I had moved it from the DC to a stand alone server and kept the sites on the DC. The show urlacl list presented me with a list of reservations that were stopping any ADFS traffic that wasn’t under the default site on the DC and once deleted manually using your instructions above everything sprang into life.

    Many, many thanks for sharing your wisdom.

    Kind regards


  7. readyxrm says:

    Thanks for this post Adam. It seems that every time I setup a CRM 2011 IFD I run into a new issue (and learn something new). I have now implemented this a dozen times and this week was the first time we had ADFS and CRM (2 IPs) both on 443 on the same server (not ideal). Your post was very helpful.


  8. Baps says:

    Hello Adam,

    Could you please help me here.
    I deploy crm 2011 and ADFS2.0 in the same server, using different IP@ with default port 443 for CRM and ADFs. The installation goes successully but I am having issue signing into CRM. When I put CRM URL it redirect to IDFS and give the error :”There was a problem accessing the site. Try to browse to the site again.
    If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
    Reference number: 25a92579-8d45-4f4e-b40e-308ab531cb1d ”

    When I verify the relying Party Trusts on ADFS,
    – Identifiers is pointing on the ASFS URL instead of CRM URL
    – Accepted claim all are No required.

    It look like my XML file do not have the right contain.

    Can you please help here?

    • ukcrmguru says:

      Can you go directly to the ADFS federation metadata URL? eg https://adfs.mydomain.com/federationmetadata/2007-06/federationmetadata.xml
      What do you see?
      Do all your domain names resolve to the correct IPs? (crmserver, adfs, mycrmorg, etc)?
      Is the ADFS website (the default site) bound only to one IP and only to https on 443? Likewise CRM? (you should not have multiple IPs, nor “all unassigned”, nor http and https at the same time)
      I don’t quite understand what you mean by “Accepted claim all are No required” – can you elaborate?

      • Baps says:

        yes I can itand have the contain of the XML file.

        I fixed the issue now by uninstalling ADFS, remove the default URL and reconfigure the binding to point to port 444 instead of port 443.
        Reinstall ADFS and setup the relying party trust and now I am pointing to the right site.
        So now, I am using only one IP, CRM in port 443 and ADFS in port 444

        Everything works fine.
        Your post helped me a lot.
        Thank you again.

      • Baps says:

        Hello Adam,

        I deployed CRM2011 with ADFS and it is working very well inside my organization.
        I don’t want to you use IFD, but would like to use CBA to pointed to the public IP.
        Can this work that way?
        I register the DNS for both CRM and ADFS, but when trying to access the site from outside, ADSF will fail loading. But inside my network CRM will work fine.
        Can someone explain the raison why it is failing.

  9. ukcrmguru says:

    A couple of things to test:
    Can you access CRM from your internal network but using the external URL? (if you don’t already have an internal IP address published in your internal DNS for this, edit your hosts file temporarily to test this). You should get redirected to ADFS and prompted for credentials on the form (NOT a pop up windows authentication dialogue)
    Can you browse to the ADFS server from outside the LAN? Do you have the right port forwarding rules on your firewall to redirect the request to the right place?

    • Baps says:

      Hello UK, thank you for your reply.
      Actually, I fixed the issue. The problem was, my ASA Firewall was blocking ADFS port (444). I opened the port for the specific server and it works fine.

      Thank you for getting back to me. Now I am fully operational.

  10. Ben Weston says:

    Hi ukcrmguru

    I have tried the steps above, but I am seeing slightly different behaviour and wondering if you have any ideas where I’m going wrong.

    Before removing the URL ACL for https://+:443/FederationMetadata/2007-06/ I can actually create the Relying Party Trust in ADFS and browse to the CRM federationmetadata.xml file (e.g. https://internalcrm.mydomain.com/federationmetadata/2007-06/federationmetadata.xml) without any error.

    However, it looks like the CRM federation metadata URL is actually serving the ADFS federation metadata, because the XML shown in the browser is exactly the same as the ADFS federation metadata and the entityID at the top of the page shows as http://adfs.mydomain.com/adfs/services/trust where I would expect to see https://internalcrm.mydomain.com. In addition, the Relying Party Trust for internalcrm.mydomain.com shows several Relying Party Identifiers such as https://adfs.mydomain.com/… whereas, based on our other ADFS implementations, I would expect to see only 1 Relying Party Identifier of https://internalcrm.mydomain.com.

    When I then remove the URL ACL for https://+:443/FederationMetadata/2007-06/ and add it back as https://adfs.mydomain.com:443/FederationMetadata/2007-06/ I can still get to the CRM and ADFS federationmetadata xml in the browser, but both still return the same XML.

    If I then restart the AD FS 2.0 Windows Service, the CRM federation metadata now looks correct (i.e. the entityID is now https://internalcrm.mydomain.com/), but the ADFS federation metadata URL returns a 503 service unavailable error.

    I can get back to where I was if I remove the URL ACL for https://adfs.mydomain.com:443/FederationMetadata/2007-06/, reinstate it as https://+:443/FederationMetadata/2007, and restart the AD FS 2.0 Windows Service, but at this point I’m pretty stuck!

    Have you got any ideas why the URL ACL for https://adfs.mydomain.com:443/FederationMetadata/2007-06/ doesn’t seem to work?


    • Daniel says:

      Hey Ben:

      Have you got any news for your problem?. eVERY FORUM AND BLOG REDIRECTS TO YOUR POST, but still no details on this exact issue are resolved or answered. I have the same EXACT problem.
      Please some help would be greatly aprecciated.



    • ukcrmguru says:

      Firstly, make sure you really need to do this configuration. If you can put ADFS on port 444 it would simplify the whole job. Having said that, you got this far, so try these steps:
      Delete the URL ACL for ADFS https://+:443/….. (Ben it looks like you did this already, so skip this).
      Add the new URL ACL for ADFS https://adfs.somedomain.com:443/…. (again skip if you did this).
      An IISReset is always a good idea at this point (NB: not on a production system when users are working!)
      Re-run through the wizard to configure Claims-Based authentication, so that CRM publishes it’s metadata again.
      Now check the ADFS metadata URL in a browser again. If it comes up OK, add and configure the relying party for internal access in ADFS.
      Now run the IFD config wizard for external access, and then configure ADFS to add and configure the relying party for external access.

      • Daniel says:

        Hello UK, thanks for your reply.

        Actually the problem is just after the step you mentioned : “Add the new URL ACL for ADFS https://adfs.somedomain.com:443/…. (again skip if you did this).” After doing this, an IISRESET, the ADFS service restarted, the ADFS federation metadata URL returns a 503 service unavailable error.

        The requiremnts must be in a single server and on port 443 due to a PROXY server (which is apache http mod-proxy module). We cant use another server. I would really like to know how to debug the issue on why the service cant listen to the urlacl.

        Please any help would be greatly aprecciated.


  11. Prog CRM says:

    Hi Adam,

    Great post. We’re trying to configure CRM 2013 Claims & IFD but we’re having issues. Would you please take a look and see if there’s anything you can help us with?

    I have 2 issues related to CBA and IFD configuration:







    • ukcrmguru says:

      @ProgCRM. Your community post is very long and detailed. At the moment I spotted a few things in there that I would question:
      1) you configured CRM to use HTTPS by changing the bindings to use SSL on port 443 (as far as I can tell) and tested this, and it worked

      2) you configured ADFS to use port 443 as well – why would you do this? You would be MUCH better off uninstalling ADFS, removing any reserved URL ACL entries and configuring the default website to use port 444 with SSL before installing ADFS. That way you have CRM and ADFS configured for different ports and avoid lots of issue with conflicts

      3) Your relying party trust identifiers are completely wrong. When the ADFS config is requesting the federation metadata file from CRM, this should contain a list of CRM URLs (specifically including one for each CRM organisation as for example CRMTest.mydomain.com). The fact that this list is wrong is usually an indication that you have a conflict and the ADFS reserved URL is redirecting the request before IIS or CRM even sees it. By configuring on two different port numbers, you can avoid this issue. Alternatively you have configured CBA incorrectly in deployment manager and used the wrong names there.

      4) You used CNAME DNS records. I tend to use A records, but I can’t immediately give you a good reason why CNAMEs would not work, or why one would be better.

      5) For your setup on a single server, I cannot see any reason you should need to use SPNs. If you do use them, then you need to set them using Domain Admin privileges (and check for conflicting ones before you do, by listing them). I don’t think the domain functional level (or schema, if you want to call it that) has any bearing here. Also, if I understand correctly, you should register the SPN for the ADFS computername account, not the CRMAppPool account (I see conflicting information about this, but my understanding is that prior to IIS 7, the website was run in the service account context, and since then it uses the local computer account for our purposes here. I am not an IIS expert so this may be wrong, or has been superceded in later versions).

  12. Christina says:

    Hi, we have a problem with CRM and ADFS config. They are on one server, and need to use 443 port togother. Now CRM is working on 443, but ADFS is not. Send error message:

    A token request was received for a relying party identified by the key ‘https://crm.pannoniaethanol.hu/’, but the request could not be fulfilled because the key does not identify any known relying party trust.
    Key: https://crm.pannoniaethanol.hu/

    This request failed.

    User Action
    If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.

    Encountered error during federation passive request.

    Additional Data

    Exception details:
    Microsoft.IdentityServer.Web.InvalidScopeException: MSIS7007: The requested relying party trust ‘https://crm.pannoniaethanol.hu/’ is unspecified or unsupported. If a relying party trust was specified, it is possible that you do not have permission to access the trust relying party. Contact your administrator for details.
    at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
    at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, Uri& replyTo)
    at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
    at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
    at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSecurityToken(SecurityToken securityToken, WSFederationMessage incomingMessage)
    at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolRequest(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)
    at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(SecurityToken securityToken)

    • Christina says:

      Oh sorry, crm version is 2013, and ADFS 2.0 🙂

      • ukcrmguru says:

        Sorry, but I think I will find it hard to figure out your very specific error without knowing what you have configured and how, what steps you have taken to troubleshoot this, what you have checked etc.
        This is my blog, not a support forum. You might be better off posting in one of the many forums available for such things that will have a much wider viewing audience and are designed for the back and forth that will almost certainly be required to fix this.

  13. Daniel Abreu says:

    This is a hell of an impressive post. Thank you very much!

    Not sure if you face similar situation, but from time to time ADFS restores the https://+:443/FederationMetadata/2007-06/ reservation breaking the Relying Party Monitoring between CRM and ADFS.

    Is there any way to avoid this situation?


    • ukcrmguru says:

      @Daniel I have not seen that happen. I can’t see why it would do that unless you reinstall ADFS, or perhaps applying a windows update to it might have the same effect. Don’t forget, the best advice is NOT to run CRM and ADFS on the same port, but use eg port 444 or 4433 for ADFS to avoid all possible conflicts.

Please feel free to join in the conversation below...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: