-
Title
VAS users cannot login, or are only able to login intermittently -- though users are in cache and -
Description
VAS Active Directory (AD) users cannot login through VAS, or are only able to login sporadically. Though users cannot login, they show up in VAS' users cache, when performing a 'vastool list users', root can also 'su' to the accounts. -
Cause
CAUSE 1:
Often the inability to login, especially when it is sporadic, and the users accounts appear in cache, is related to timing issues. VAS uses Kerberos for authentication; and the Kerberos protocol is time-sensitive, allowing only a defined amount of time for the authentication key-exchange to occur, to thwart "man-in-the-middle" attacks -- further details of the specifics of the Kerberos protocol can be found in RFC 1510. The default window of time, for VAS' Kerberos implementation, is 10 seconds -- meaning that after the user enters their password, there is 10 seconds for the Kerberos key-exchange to complete. VAS uses an internal utility to handle its Kerberos key-exchanges: /opt/quest/libexec/vas/vasauth_helper. This binary can be called directly to test aspects of the Kerberos authentication or service ticket requests.CAUSE 2:
DNS is not working or not setup properly.
-
Resolution
To check the time required for a user to complete VAS authentication, try running the below command (replace values in "<>"):
# echo <VAS User password> | time /opt/quest/libexec/vas/vasauth_helper --user=<VAS User> --debug-stderr --auth-ad-get-tgt --auth-ad-store-user-ccache auth
If the time appears to be exceeding 10 seconds, and the user is failing authentication, often the issue can be attributed to issues with DNS. Invalid "nameserver" or "search" entries in the /etc/resolv.conf can cause DNS resolution to take longer than 10 seconds, thus causing VAS to fail Kerberos authentication. Another common cause is network latency, which can be due to the VAS client and the DC it is talking to being separated by a WAN link.
RESOLUTION 1:
For DNS related issues: check and remove invalid domains entered in the "search" entry of the /etc/resolv.conf, as well as "nameserver" entries that are no longer valid.
RESOLUTION 2:
For network related issues: if DCs in the domain exist locally, as well as over a WAN, create an AD "site" to restrict the DCs VAS will communicate with to those located on a local network. Please refer to Microsoft documentation on how to create sites in Windows 2000/2003 domains.
Below is a link to Microsoft's Step-by-Step Guide to Active Directory Sites and Services:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/adsrv.mspx
RESOLUTION 3:
You can increase the window of time VAS allows for the entire Kerberos exchange to take place. To do this, you need to add the "helper_timeout" argument, and set a integer value (measured in seconds), to all the pam_vas3 entries in the "auth" section of the /etc/pam.conf or add the global auth_helper value to the [libvas] stanza of the vas.conf:
/etc/pam.conf.
auth [ignore=ignore success=done default=die] pam_vas3.so create_homedir get_tgt helper_timeout=30
/etc/opt/quest/vas/vas.conf
[libvas]
auth-helper-timeout = 30
RELATED SOLUTIONS:
Solution 17200 "User unable to login through VAS when primary DNS server is unreachable.":
https://support.quest.com/SUPPORT/index?page=solution&id=SOL17200