Just for context, our Hadoop cluster is kerberized and is backed by Active Directory that also hosts the other accounts running our .NET apps on Windows.
One of our .NET apps opens a connection to Impala using the .NET OdbcConnection class. The OdbcConnection instance is supplied with an ODBC connection string that specifies the use of the Impala ODBC driver (2.6.7) and points to our Impala daemon nodes. We want to run our Impala queries using a different account from the one that is running the .NET app, so we do WindowsIdentity.RunImpersonated (WindowsIdentity.RunImpersonated Method (System.Security.Principal) | Microsoft Learn) to run the ODBC connection code as the user that we want. Here's a simple example of how the code looks:
WindowsIdentity.RunImpersonated(safeAccessTokenHandle, () =>
{
var connectionString = "Driver=Cloudera ODBC Driver for Impala;...;AuthMech=Kerberos;SSL=1;UseSystemTrustStore=1;";
OdbcCommand command = new OdbcCommand("SELECT 1");
using (OdbcConnection connection = new OdbcConnection(connectionString))
{
command.Connection = connection;
connection.Open();
command.ExecuteNonQuery();
}
});
What we found is that we hit the following error when we use impersonation:
ERROR [HY000] [Cloudera][DriverSupport] (1100) SSL certificate verification failed because the certificate is missing or incorrect.
but if we remove the impersonation then the ODBC connection is successful. This makes us think that the issue lies not with the certs but with how WindowsIdentity.RunImpersonated interacts with the Impala ODBC driver.
We also tried turning on LOG_TRACE on the driver to look at the logs, but the logs don't have anything beyond the error message as shown above.
