Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
CRM 2013:Adding a Host NAme to IIS I am no longer able to log in RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have CRM installed on-prem and have set up SSL.

    I have the HTTPS binding set up and have removed the HTTP binding.

    On the server, at this stage I can login in to https://localhost/org.

    Now, if I add the Host Name to the HTTPS binding: crm.mydomain.com I can no longer log in:

    •     HTTP Error 401. The requested resource requires user authentication.

    I am using a domain account for the app pool "domain\crmsecurity".

    I have the following SPNs:

    • HTTP/servername
    • HTTP/servername.domain.local
    • HTTP/crm.mydomain.com

    I am logging in to "https://crm.mydomain.com".

    Removing the host name and the site works again as localhost.

    Any advice on what I should check. 

    Wednesday, January 22, 2014 5:45 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    It is working now.  Not sure what corrected it.

    The last thing we did was remove the existing SPNs and reapply them.

    We went with:

    "servername:443" and "servername.domain.com" (no 443).

    I don't know quite what made it work as the whole thing was complicated by the site not working on the server but when I checked from another machine it was fine.

    I do wish server, by default, were smart enough to go to the router and back again.  I know it's not quite that simple.

    Thursday, January 23, 2014 3:49 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Found this:

    http://msdn.microsoft.com/en-us/library/dd979498.aspx

    Is it still the case that SSL does not work with Host Headers?

    It could be that my approach is all wrong and I need to set up a DNS Alias record.

    Thursday, January 23, 2014 9:55 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Okay, reconfigured things a little but have same problem.

    I removed the Host Header and has am DNS Alias record created. When I log in as https://localhost/org, I get in no problem; when I log in as https://org.domain.com I get the repeated login dialog and then the 401 error.

    In the event viewer I get:

    The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server crm-server-frontend$. The target name used was HTTP/org.domain.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN.LOCAL) is different from the client domain (DOMAIN.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

    Have I misconfigured something here?

    Thursday, January 23, 2014 11:29 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The event viewer error was a red herring.  It has not recurred.

    Back to the drawing board.

    Thursday, January 23, 2014 11:49 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    It is working now.  Not sure what corrected it.

    The last thing we did was remove the existing SPNs and reapply them.

    We went with:

    "servername:443" and "servername.domain.com" (no 443).

    I don't know quite what made it work as the whole thing was complicated by the site not working on the server but when I checked from another machine it was fine.

    I do wish server, by default, were smart enough to go to the router and back again.  I know it's not quite that simple.

    Thursday, January 23, 2014 3:49 PM