We are seeing the following Kerberos errors when accessing SharePoint Web Services:424.3552> Kerb-Warn: KerbVerifyPacSignature contacting domain XXX.XXX.ORG for user XXX424.536> KSupp-Warning: Failed authenticator (replay/time_skew) check: 0x22424.536> Kerb-Warn: Failed to verify AP request (need u2u? false): 0xc000006d. d:\nt\ds\security\protocols\kerberos\client2\ctxtapi.cxx, line 3648424.1372> Kerb-Warn: KerbVerifyPacSignature contacting domain XXX.XXX.ORG for user XXX424.5156> KSupp-Warning: Failed authenticator (replay/time_skew) check: 0x22This seems to result in IIS 401.1 access denied messages when accessing these services. Given the SharePoint site works, but the child Web Services virtual directory doesn't work (e.g. in /_vti_bin/Lists.asmx), we are left confused. Kerberos SPNs and full-delegation is configured for a SharePoint Server and a SQL Server. Service accounts are also configured. User accounts however remain as NTLM. IIS is configured for "Negotiate,NTLM".The time on the AD and SharePoint servers appears to be correct to the second. We have ruled-out the LoopBackCheck causing the 401.1 and it doesn't appear to be caused by IE or DNS settings. Interestingly we can access the WSDL for the Web Service (http://server.example.com/_vti_bin/Lists.asmx?WSDL) but not the Web Services Documentation (non-WSDL) ASMX page.Any thoughts?

Hi,Firstly, I suggest that you confirm if the system time is synchronized between the domain workstation and DC. Please also check if the time zone is configured correctly.And then, please try accessing other domain resource such as accessing a share folder using UNC path (\\FileServer\ShareFolder) to narrow down the cause of the issue. If you can access the share folder, I think that Kerberos authentication works properly and the issue is more related to SharePoint. You can post to the SharePoint forum for further assistance:http://social.technet.microsoft.com/Forums/en-US/category/sharepointThanks.This posting is provided "AS IS" with no warranties, and confers no rights.

Turns out this was a <httpHandlers> issue in a web.config file for SharePoint. Will add more info when it comes to hand.