Based on the behavior, it seems to be the case that the execution environment for sqoop list-databases is local to the client host and so has access to the user's ticket cache on that host. Sqoop is a wrapper for the creation and submission of MapReduce jobs (and everything here is with respect to MRv2 on YARN).
When sqoop import is invoked from the client, resources for the associated Map tasks are allocated by the YARN Resource Manager in the form of YARN containers that are scheduled to run on the cluster's worker nodes. These containers are not forwarded Kerberos tickets, instead they are given delegation tokens (requested by the client and associated with the container's launch context). More details are available here and here.
These delegation tokens can be used to access Hadoop resources, such as HDFS, under the authorization context of the client. My speculation is that since the execution context for the Map tasks does not contain the original TGT, this poses an issue for authenticating via Kerberos to services outside of Hadoop that don't interact with Hadoop delegation tokens, like SQL Server.
Sqoop SQL Server data import to HDFS worked with manual
parametric the authentication(using windows credential) with added parameter on
the SQL Server JDBC driver, as integrated security is not supported by the SQL
driver as of now due to the Kerberos authentication(Delegated tokens
distributed over cluster while running MR job).
So we need to pass the windows authentication with password and
with the integrated security disabled mode to import the data to the system. As
normal SQL server driver does not support, so I had used the jtds.jar and the
different driver class to pull the data to the Hadoop Lake.
Note* In the above
example you need to change the username to your username and database name in
the list-tables or pull to the one you need (note the AD account you use will
require access to the data).