Failed to refresh site cache in Commerce Server 2007 due to Kerberos negotiation issue
While we open Catalog Business Tool, and click the “Refresh site cache” link, we may get this HTTP 401 error message:
The server 'MyServer' of the application 'OrdersWebService' returned HTTP status code 401 (Unauthorized). The cache refresh URL used was 'https://MyServer/OrdersWebService/SiteCacheRefresh.axd?CacheToRefresh=CatalogCache'.
In many situations, it is usually caused by:
1. The “Windows Integrated Authentication” option was not enabled for the OrdersWebService web site.
2. NTFS permission restriction in the path.
3. The Authorization section in web.config was not set correctly for the web site. This part has been well discussed in this article:
931290 You receive error messages when you update the catalog cache or the profile cache in Commerce Server 2007
https://support.microsoft.com/default.aspx?scid=kb;EN-US;931290
Following above check methods should resolve the issue, but not always. Here is a different sample:
True Problem
=============
One of my customer get the same HTTP 401 error for this “Refresh site cache” link, however the above checklist doesn’t work. The most interesting thing is if we manually access
https://<ip address>/OrdersWebService/SiteCacheRefresh.axd?CacheToRefresh=CatalogCache
The page can show without issues (a blank page), but when we use Computer Name instead of IP address:
https://<Computer Name>/OrdersWebService/SiteCacheRefresh.axd?CacheToRefresh=CatalogCache
The 401 authentication happens immediately, even we typed correct user name and password.
Analysis
==============
We worked out this problem through below action plan:
1. Make sure there is no proxy configured on IE. Same issue
2. Added IP address and Computer Name into the same Local Intranet zone> IP address still worked, Computer Name still failed.
3. Suspect it is caused by some Kerberos issue because:
a. For the IP address, default we cannot use Kerberos because for IP address there is no SPN name set in AD.
b. For the Computer name, Kerberos will be negotiated at the beginning, if there is some special Kerberos failure, the problem may happen.
c. In order to verify this behavior, we used a quick way to uncheck the “Enable Integrated Windows Authentication” option in IE. Use this method, IE will only use NTLM to communicate with web server.
The result is: Computer Name works in this situation. This confirmed our assumption. For this IE option, please refer to:
299838 Unable to negotiate Kerberos authentication after upgrading to Internet Explorer 6
https://support.microsoft.com/default.aspx?scid=kb;EN-US;299838
d. Start working on troubleshooting Kerberos. We captured Network trace on Web Server and Client sides. Found the Kerberos Modified Error on Server Side:
e. The root cause of this Kerberos failure is:
Customer configured one domain user account as the Application Pool Identity, but the SPN name wasn’t registered on the account.
When the SPN isn’t registered, the DC will select an account’s password in the domain according to some rule to encrypt the Kerberos authentication package. But the account may not be this account pool account. So when the IIS server received the package, it would not be able to decrypt it using the Application Pool Account password.
Here we have narrowed down the Commerce Server issue to an IIS web application Kerberos authentication problem.
To resolve this
=============
1. Follow this article to setspn for the Application pool domain account by such a command:
Setspn –A HTTP/iis6server1 mydomain\appPoolaccount
929650 How to use SPNs when you configure Web applications that are hosted on IIS 6.0
https://support.microsoft.com/default.aspx?scid=kb;EN-US;929650
2. After the SPN set, it is required to synchronize the IIS server and the DC. On one hand, to make sure DC using the same account password encrypt the package, on the other hand, to force the password synchronization between DC and IIS server. Restart the IIS application pool will perform synchronization (re-enter the password of the application pool and restart the IIS application pool).
Now everything back to track.
Regards,
Freist Li