Issue with oneway keytab file...password not correct

Hello,

We sometimes are facing the problem described in this article:

https://support.oneidentity.com/safeguard-authentication-services/kb/267418/failure-417-vas_host_services-password-in-file-etc-opt-quest-vas-oneway-keytab-for-principal-oneway-account-domain-com-is-not-correct

However, what could be the cause of why the password is not matching what is in Active Directory ?  The article talks about how to resync them back, but doesn't give any reason why it happens.  With the oneway script, the service account in the trusted AD domain  gets created with "password never expires".  So, the password is not being changed on the trusted AD domain side.  So, we just want to know what is causing it.  We use one keytab file per system so at least the outage when this happens is limited to that system.  But, still we would like to get to the bottom of it.  Thanks.

  • Thank you for the question.

    If you review the pwdLastSet attribute, does it match the timestamp you expect for the last change, or does the pwdLastSet timestamp indicate that the password has indeed been changed?

    Further in-depth review of this issue would require a service request – if you do wish to create a service request for further review, please also provide within the service request:

    1. A snapshot; generated by running this command as root:     /opt/quest/libexec/vas/scripts/vas_snapshot.sh

        When executed the snapshot will collect a variety of information about the system and the state and configuration of Authentication Services. It must be executed with root level privileges.

       The script will create a file in /tmp in the following format.
             vas_snapshot.hostname.date.tar.gz

      It is typically small enough to attach directly to the Service Request.

    2. The output of attributes for the service account, eg: “/opt/quest/bin/vastool -u host/ attrs <service_account>”

  • Hello Adrian,

    Thanks for the suggestion on what to look for next time this happens..  The pwdlastset attribute changed quite a few times as there were attempts by the team to resync the password the last time this happened.  So, a little bit difficult to know if password changed to cause the issue.  Hard to imagine anything or anyone touching these accounts.  Right now, things are stable after a new keytab file was created.  If it happens again, we will open a service request with the snapshot and output of the attributes.