CRM 2011 IFD with multiple webservers/different internal and external domain names RRS feed

  • Question

  • All,


    I am upgrading our existing CRM 2011 UR12 isntallation to use claims based authentication and IFD.  We previously had two servers, one DB and one web server, I am adding a second server with just the front end roles and placing it in my DMZ.  I have ADFS installed with an ADFS proxy server, and I believe I have the knowledge to get the ADFS setup to work, however, my problem is with the relying party certificate. 


    My internal web server is on the domain.local domain and my public servers run on domain.net.  I have created the necessary certificates for the internal server and claims based authentication works just fine.  For the public web servers I am using a wildcard certificate for *.domain.net.  When I attempt to login to the public URL I am getting the error 'Relying Party Certificate was not found'.  I used tracing to find the error message and just prior to this error message I see it is looking in the database for a thumbprint (guid) for a certificate that is the type RelyingPartyEncrypting.  The certificate it finds is the internal certificate that is used for internal claims authentication on the internal web server.  I am assuming this was created when I configured claims based authentication, as that is the only step I remember it asking about a certificate. 


    1. Is there a method to individually identify a separate certificate for the external web server? 
    2. The only solution I can think of is to request a public certificate with SAN's that include all of the internal and external dns addresses for:
    • crm.domain.local
    • auth.domain.local
    • dev.domain.local
    • org.domain.net
    • auth.domain.net
    • dev.domain.net



    Wednesday, March 13, 2013 3:14 AM

All replies

  • Hi James,

    If internal and external URL has different domain name, SAN certificate is the solution for this kind of deployment.

    Jackie Chen, Microsoft Online Community Support. Please remember to click “Mark as Answer” on the post that helps you. This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, April 10, 2013 6:56 AM
  • We are in a similar situation. I am not sure how would you get a SAN cert for your internal domain. I know you can get a third party SAN cert for your external domain (*.domain.net) but how would you get a cert from *.domain.local. Since this is not a public domain and the 3rd party Certificate Authority can't validate it, how would you add this to SAN names in the certificate. Like you mentioned, you can create SAN certificate for *.domain.local using your internal Certificate authority but how would you add both domain.net and domain.local on the same SAN cert. I am not sure if I am making any sense but I am trying to figure this out myself. Any suggestions would be appreciated.


    Wednesday, July 10, 2013 7:27 PM
  • Jackie,

    Actually the best way to handle this would be setting up split DNS.  Create a new internal DNS zone for domain.com so that crm.domain.com internally resolves to your internal server.  Then the internal and external servers can use the same certificate, and you never reference CRM by the domain.local name.


    Wednesday, July 10, 2013 7:36 PM
  • James,  I totally agree that split DNS would be the best way to do it. We have a little twist in our infrastructure. Our internal Active directory domain is "internal.com" and external domain is "external.com". Internal.com is a private domain and we don't own the public domain name for this internal domain. We do own external.com and we can get public SAN certificates for that. To keep the inside and outside domains the same, we obtained public SAN certs for *.external.com and set these on CRM and ADFS servers. We created a new active directory integrated DNS zone internally and called it external.com. This will allow the internal clients to resolve crm.external.com to inside IP addresses when they are inside the network. When they are outside, they can resolve crm.external.com using public dns which are NAT back to internal servers. The only problem that I am running into is authentication prompt. Ideally when the users are in the network and logged on to our domain, they should be able to open CRM with pass-thru authentication without a username and password prompt however they are getting prompted for username and password just coz we are using crm.external.com to connect to CRM servers inside our network. Any suggestions on this? I have tried to set up SPN without success. This would have worked flawlessly with split dns if we had the same internal and external domain name.


    Wednesday, July 10, 2013 8:27 PM