DB Locking and authentication failures seen with vasd debug. (4380944)

DB Locking and authentication failures seen with vasd debug: 

libvascache_grent_update_by_groupkey: group_getby_groupkey failed. Necessary for grent table update. Failed Key 394. Error 2
libvascache_group_add: libvascache_grent_update_by_groupkey failed for key 394 with error 2
libvascache_user_has_uidconflict: step failed, err = 5, msg = database is locked
GenerateAuthResult: Entry for user <username> found, error <2543>, removing, error </Allow Group - Domain\group (users.allow)>
pam_vas*: pam_vas_am_do_account_check: Got a NOT OK account status 10.
pam_vas*: pam_vas_do_account_and_access_check: Account check returned non-zero: 25
Authentication <failed> for <Active Directory> user: <username> account: <Domain\group> service: <servicename> reason: <>

By default, vasd updates the cached information for access control groups every 15 minutes. 

This is to keep the cached access control list up to date with AD for every single user for reporting purposes and some passwordless cross domain / domain local group situations.

For example, the output of /opt/quest/bin/vastool list users-allowed.

This can cause a spike of CPU/Disk/Network activity every 15 minutes, scaling with the number of access control groups in use.

This activity does nothing for logins. During login, the user's PAC or tokenGroups are used to determine access at the moment of log-in.

The forced updates can be disabled by the touch file:

touch /var/opt/quest/vas/vasd/.disable_ac_group_updating