Return
-
Title
Quest Single Sign of for Java failed to authentication a user when a domain controller was una -
Description
Authentications are failing when a domain controller becomes unavailable. Quest Single Sign of for Java is not moving on to the next domain controller.
-
Cause
To verify this is what really happened you might be able to find something similiar to this in the logs. You will see we send a TCP request to a DC but over three minutes laters it is unsuccessful, by this time QSJ has given up.[DEBUG] Mon Jul 26 15:42:56 BST 2010 jcsi.kerberos: Resolving KDC for realm: EXAMPLE.COM
[DEBUG] Mon Jul 26 15:42:56 BST 2010 jcsi.kerberos: Available KDC found: DC1.EXAMPLE.COM/10.10.10.10:88
[DEBUG] Mon Jul 26 15:42:56 BST 2010 jcsi.kerberos: Sending message to KDC: DC1.EXAMPLE.COM/10.10.10.10:88
[DEBUG] Mon Jul 26 15:42:56 BST 2010 jcsi.kerberos: Sending TCP request: DC1.EXAMPLE.COM/10.10.10.10:88
[DEBUG] Mon Jul 26 15:46:05 BST 2010 jcsi.kerberos: Message send unsuccessful to KDC: DC1.EXAMPLE.COM/10.10.10.10:88When connections are being established in TCP and a domain controller becomes unavailable the OS + JVM spends too long trying to get a connection, sometimes over three minutes before returning a failure to QSJ. By the time the OS + JVM returns the failure QSJ has timed out. -
Resolution
For faster timeouts, you can explicitly set this to a nonzero value that will fit comfortably in a single Ethernet packet (i.e. won't exercise UDP fragmentation) -- e.g. -Djcsi.kerberos.maxpacketsize=1450 would fit with room to spare. Once you're using UDP (i.e. a nonzero maxpacketsize) then "jcsi.kerberos.sotimeout" comes into play. The default is 15000 (i.e. 15 seconds) and is generally fine.
-
Additional Information
TCP Failover will still be available if required.