Recently I deployed an AIF service to a customer environment. Everything was working fine in my single server development environment, but after deploy to the distributed customer environment, calls to the webservice resulted in the error “A call to sspi failed”.
- My service – a simple document service. No hex about that.
- I needed to deploy the service to IIS in order for it to be consumable from a corporate website
- The customer environment contained a standalone server for the AOS and a standalone server for IIS
- I created a simple test webform – my test client, in order to being able to test that everything was working ok.
Having deployed the service, the service was browsable. The identity of the application running the AIF site was the same as the one used for the Business connector proxy account (System administration –> setup –-> service accounts) The app pool was configured like this:
Authentication was configured like this:
From AX my service was configured to use a customBinding using NTLM and my clienct was also configured to use NTLM. Any call from the client to the service would result in the error “A call to SSPI failed – see inner exception…” – and no inner exception were to be found.
Trying to narrow down the problem a basicHTTPBinding was tried – still the same error.
As different kinds of blogposts suggested, I was able to call the AIF/WCF service when the service itself was using the ipaddress (to avoid the use of kerberos) of the aos server instead of the url. However this wasn’t an acceptable solution, as any new deployment of the service from AX, would result in a non working webservice, since the web.config would be overwritten when deploying from AX. And as it turned out, it was not possible to alter settings in AX forcing ax to deploy the service and having the endpoint in web.config reference the ip address instead af the FQDN. However the problem was now narrowed down to be caused by kerberos. I found this great blogpost explaining some basic things about Kerberos.
Another thing we tried out was to set the spn for the user running the service:
Setspn –A HTTP/2012webtest.myDomain.local myDomain\sa-proxy-lon
Having done that we tried to setup trust for delegation in AD according to this. We are not sure whether this had any effect, but we didn’t reverse the process.
This blogpost (see comment from Eric Ledoux and Brian Kinser) suggested that this might be caused by a kernel error. My customer recently upgraded to R2CU7 and I was expecting this to be fine, but talking with the technician from the customer revealed that IIS might not have been updated in that process with the new AX components. Running the setup file from the CU7 install media, suggested to update some core AX components. Choosing yes to update, restarting IIS and the AOS service, fault messages from ax started to show up when calling the webservice – meaning that everything was starting to work as expected.
In my case the “a call to sspi failed” error turned out to be resolved when upgrading to CU7. The problem I was facing was just caused by the fact that only the AOS had been upgraded – not IIS. Resolving this mismatch solved the problem.
Thanks to my colleague Morten Uldall for both moral and technical support:-)