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 'http://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


http://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


 


http://<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:


 


http://<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


http://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:


 



Network Trace on Web Server 


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


http://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

Comments (0)

Skip to main content