Later on in the thread, Danny Alvares points out that in the Identity and Access Management Series 1.4 under Chapter 5: Identity Aggregation and Synchronization there are some recommendations when performing password synchronization to set the "KdcWaitTime" from the default 10 seconds to 30 seconds. This would give the MIIS Server some additional time before giving up on its authentication attempt. Presumably this would be evident in large distributed Active Directory deployments where network latency is very evident or the Domain Controllers themselves are taxed.
In my experience, there are two "common" Kerberos authentication issues that I have had to deal with and one rather rare one concerning replication:
-
Kerberos Time Skew - By default (you haven't altered the default Kerberos options in your Default Domain Policy GPO) all computers in the forest must have their clocks set to within 5 minutes of each other (time zones notwithstanding). The most important relationship is between the client and the authenticating Domain Controller - if the time is skewed by more than 5 minutes then the built-in security methods within the Kerberos protocol will consider the authentication requests to be compromised and deny the request. For this reason - ensure that the time on your MIIS Server and the time on the Domain Controllers in your site are all synchronized. A well built environment should have a skew of only a few seconds max. To confirm a time skew problem you can use the w32tm program from the command line:
w32tm /monitor /domain:
or to just check your local site DCs:
w32tm /monitor /computers:[computer1],[computer2],...
The NTP results should indicate an offset of less than 5 minutes. If you are seeing offsets greater than 5 minutes then you can force a manual reset by using the net time command:
net time <\\computertosyncto> /SET
To resolve this for good, consult the following KB article:
How to configure an authoritative time server in Windows Server 2003
-
UDP Filtering - By default, all Kerberos authentication traffic utilizes UDP port 88; however issues with token size can increase the size of the packet and force it to use TCP port 88. If you are dealing with firewalls that are not enabled for both TCP and UDP port 88 or routers that are filtering UDP then you will have difficulty with authentication between distributed hosts. This can manifest itself through extended logon times (several to tens of minutes or longer). One method that I have used to troubleshoot whether or not the network is, in fact, filtering UDP requests is to force all Kerberos authentication traffic to use TCP instead of UDP. By setting the "MaxPacketSize" to 1 you can force Kerberos to use TCP.
See the for the MaxPacketSize option which allows you to adjust the value from the default (2000 in Windows 2000, 1436 in Windows 2003).