First off let me start describing how I have the CRM server setup.
- Single Server Install (CRM + SQL)
- HTTPS setup on non-standard port (4445), one binding and using an SAN certificate signed by our CA in our domain
- One domain user account used to run everything (IIS App Pool, Async Service, Deployment Service, etc...)
When I run the following code
Uri discoUri = new Uri("https://crmserver:4445/XRMServices/2011/Discovery.svc");
clientCredentials.Windows.ClientCredential = new System.Net.NetworkCredential(USERNAME, PASSWORD, DOMAIN);
using (var _serviceProxy = new DiscoveryServiceProxy(discoUri, null, clientCredentials, null))
{
// You can choose to use the interface instead of the proxy.
IDiscoveryService service = _serviceProxy;
RetrieveOrganizationsRequest orgsRequest = new RetrieveOrganizationsRequest()
{
AccessType = EndpointAccessType.Default,
Release = OrganizationRelease.Current
};
RetrieveOrganizationsResponse organizations = (RetrieveOrganizationsResponse)service.Execute(orgsRequest);
}
I get this exception:
Exception: SOAP security negotiation with 'https://crmserver:4445/XRMServices/2011/Discovery.svc' for target 'https://crmserver:4445/XRMServices/2011/Discovery.svc' failed. See inner exception for more details.
Inner Exception: Security Support Provider Interface (SSPI) authentication failed. The server may not be running in an account with identity 'host/crmserver'. If the server is running in a service account (Network Service for example), specify the account's ServicePrincipalName as the identity in the EndpointAddress for the server. If the server is running in a user account, specify the account's UserPrincipalName as the identity in the EndpointAddress for the server.
I get this error running the code above, using the Plugin Registration Tool or other CRM tools from a computer other than the server. If I run the code/tools on the server they run just fine.
Since I'm using Kernel Mode in IIS 7.5 and a Domain User account I was under the assumption that HTTP SPN's didn't need to be setup, just for the heck of it I added two HTTP SPN's against the Domain User account
- HTTP/crmserver DOMAIN\SERVICEACCOUNT
- HTTP/crmserver.fqdn.local DOMAIN\SERVICEACCOUNT
And that didn't seem to help either!
Interestingly enough if I switch from HTTPS to HTTP I can connect from the client machinse so I'm really confused why an issue that appears to be Windows Authentication/Kerberos related suddenly disappears once I use HTTP!