Password resets are failing when the reset request takes longer than the default timeout or vastool status fails periodically (4267840)

Machines joined to AD are becoming disconnected without apparent cause due to the password reset not completing successfully. /opt/quest/bin/vastool status fails periodically when called in a loop 

In some instances this can occur due to timing issue. In some environments it has been observed that it takes a litte longer to get the confirmation back concerning a password reset than what the default timeout value is for Quest Authentications services.

This results in QAS trying to use a bad or invalid password and thus becoming disconnected. This can occur if responses from the PDC are delayed at all.

Workaround #1

In the '/etc/opt/quest/vas/vas.conf' we can increase the timeout value so ensure we wait longer. You can set the KDC timeout to 10 seconds or 20 seconds instead of the default 3 seconds.

[libdefaults]
kdc_timeout = 10

Here is the man page entry for this setting.

This option controls how many attempts to contact each KDC will be made when trying to communicate. Note that retries are only performed when use-tcp-only is false, but the max_retries value is used to
determine the total timeout for a TCP connection. When use-tcp-only is false, the first attempt will be performed using UDP; if no response is received from the KDC, the connection will automatically try
the remaining max_retries with TCP. The following example shows how to decrease the max_retries to 2.

Quest has also logged Product Defect # 25099 in order to investigate the possibility of of a method for being more robust in this scenario to try and avoid this situation completely in the future.