A few weeks ago I was getting errors connecting to the NAV webservices using the Connector.
You can read more about that here
https://crmbusiness.wordpress.com/2012/08/16/crm-2011-dynamic-connector-error-the-request-failed-with-http-status-401-unauthorized/
I got round the problem by using the ip address of the server, other things you can try is the full name (usually .local at the end or something like that) or just the server or localhost if you are on the machine.
I did raise the question with the Dynamic Connector development team, who are a helpful bunch.
I have had a problem like this before and I thought I would explain what is causing this problem because you may come up agaisn’t similar issues like this in CRM, NAV and the Dynamic Connector.
The basic problem is Kerberos authentication and it’s failing.
the way I understand it is you can access the NAV webservices/crm webservices within internet explorer because you can add the webservices as a trusted site. Adding this into the trusted sites helps the kerboros authentication, which explains why you can often access it using internet explorer.
If you can’t get any other url’s (ip address, localhost, servername, full servername) then you are going to have look at the SPN settings (Service Principal Settings).
If like me you are not sure what a SPN is, this is probably the time you start to talking to the IT experts internally and on the customer site.
I found a quick explanation about what an SPN is here
http://msdn.microsoft.com/en-us/library/windows/desktop/ms677949(v=vs.85).aspx
A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. For more information about SPN format and composing a unique SPN, see Name Formats for Unique SPNs.
Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the logon account of a service instance changes, the SPNs must be re-registered under the new account. For more information, see How a Service Registers its SPNs.
When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate. For more information, see How Clients Compose a Service’s SPN.
My basic understanding of this is you are setting up exe’s and computers to be trusted and put into a sort of list, so when a connection is attempted e.g. from the connector to a computer then if it’s on the list the kerboros authentication works. Now my explanation could be a load of nonsense buts that how I imagine it works.
This issues are always tricky to resolve because often the IT staff won’t want to get involved and say it’s a problem with NAV/CRM/Dynamic Connector and it’s nothing to do with the IT setup. It’s highly likely you won’t have access to the domain controller to be able to tinker with the SPN settings so you haven’t really got any choice but to keep explaining to the IT staff.
I have had days wasted trying to figure out these kind of problems and I hope your connector installations don’t suffer from this problem.
Like this:
Like Loading...
Hosk's Dynamic Blog 