Description:
Workbench native Kerberos connection method is inconsistently connecting to the database. In my environment, it is having valid Kerberos ticket available and cached locally but it still fails to load the SQL Editor. After a couple of consecutive try it loads the SQL Editor. I have tried in multiple machines located in different regions the pattern is the same.
Workbench version:8.0.33
Observation:
==========
*Test connection in workbench is always successful
*MYSQL Client CLI always gets connected successfully without any issues
*The Problem is only with the workbench. Sometime it loads the editor in the first try and sometime after couple of consecutive tries.
Native Kerberos configuration:
========================
1) GSS APPI Mode
2) Advanced tab - Kerberos Configuration path and Kerberos Credential cache contains the path to files
3) Plugin authentication_kerberos
4) database Aurora MYSQL 3.03.1 Compatible 8.0.26
Experience
=========
Working Experience: Workbench loads the SQLEdition
Not working Experience: Workbench prompts the dialog windows to enter the user and password. This should not be prompted when we have valid credentials cache and configuration. if we try a couple of times, its get connected successfully and loads the SQL editor.
For reference attached logs and screenshot
How to repeat:
1) Kinit user@REALM
2) make sure krb5.ini and krb5_cc is valid and configured in WB
3) configure the parameters like hostname, port, username, and mode should be GSSAPI
4) test connection should be successful
5) try to open the connection to load the SQL editor. Now it may load the editor in success scenario or pop up the dialog box to enter user credentials, in case of failure.
6) if SQL editor is loaded, file menu and select the close connection tab option. and try "step 5 ". The issue will be reproduced
7) Also, this can be reproduced by closing the WB and launch immediately and try open the connection. The problem surfaces .
It is not consistently opening the connection, if it fails it works after couple of consecutive tries
Suggested fix:
It should always open the Kerberos connection consistently without prompting the user for credentials if the ticket is valid.
