{question}
How do you fix the AD Authentication error 'Cannot find key for HTTP/account@DOMAIN.LOCAL kvno 4 in keytab' in the logs after updating the keytab file from the Kerberos server?
{question}
{answer}
The below error is received when we recreate the keytab file kerberos and update it. The users will not be able to log in anymore, and we will receive the "The credentials are incorrect. Please verify them and try again" in the studio, and the message is:
Access denied for user 'username'@'10.3.2.1' (using password: YES)
On checking the memsql.logfile on MA, we could find the following messages:
ERROR: Failed while trying to call gss_accept_sec_context() during login:
ERROR: GSS Major Error: Unspecified GSS failure. Minor code may provide more information
ERROR: GSS Minor Error: Cannot find key for HTTP/account@DOMAIN.LOCAL kvno 4 in keytab
ERROR: ProcessHandshakeResponsePacket() failed. Sending back 1045: GSS Major Error: Unspecified GSS failure. Minor code may provide more information. GSS Minor Error: Cannot find key for HTTP/account@DOMAIN.LOCAL kvno 4 in keytab
ERROR: ProcessHandshakeResponsePacket() failed. Sending back 1045: Access denied for user 'user'@'10.3.2.1' (using password: YES)
Cannot find key for HTTP/account@DOMAIN.LOCAL kvno 4 in keytab
If the logs display the above errors, we have to follow the steps below to identify and fix the issue.
Troubleshooting the issue:
Let's check the previous keytab file using the klist utility:
user@ss-masteraggregator:/etc/memsql$ klist -t -k memsql.old.keytab
Keytab name: FILE:memsql.old.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
4 01/01/70 00:00:00 HTTP/account@DOMAIN.LOCAL
And now the new keytab file using the klist utility:
user@ss-masteraggregator:/etc/memsql$ klist -t -k memsql.keytab
Keytab name: FILE:memsql.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
6 01/01/70 00:00:00 HTTP/account@DOMAIN.LOCAL
We could notice that the KVNO for the second file is different.
Resolving the issue:
To solve the issue while creating a new keytab, we will need to add the parameter /kvno <key version number> to the ktpass.exe command line, in this case, we will need to recreate the keytab file using the parameter -kvno 4,
ktpass -princ HTTP/account@DOMAIN.LOCAL -mapuser account@DOMAIN.LOCAL -pass <passwd> -crypto all -ptype KRB5_NT_PRINCIPAL -mapop set -out memsql.keytab -kvno 4
Copy the file to the correct location, and then restart the SingleStore cluster to resolve the issue.
Reference links:
Configuring SingleStoreDB for Kerberos Authentication
{answer}