Configuring Kerberos for Data Source Authentication¶
When you connect to a Kerberized data source, Alation takes the credentials you provided as a service account and attempts to authenticate by reaching out to the Key Distribution Center (KDC) you have provided in the Kerberos configuration file for Alation. The KDC verifies the credentials and sends back an encrypted ticket granting ticket (TGT) and a session key. Then Alation forwards the session key to the DB service to prove that the user has access, and the DB service grants access.
Kerberos can be configured on the server before Alation installation if you plan to add Kerberized databases to the catalog. It can also be configured after you have already installed Alation, but with a slightly different set of steps. Choose the scenario that applies to your case.
Configure Kerberos Before Installation¶
On the server where you plan to install Alation, configure a valid /etc/krb5.conf. The default_realm should be set to the realm having the user principal which you are planning to use as the database service account in Alation.
Example:
krb5.conf content will depend on your database environment. This is a generic example:
[libdefaults] default_realm = TEST.ALATIONDATA.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = true [realms] TEST.ALATIONDATA.COM = { kdc = 10.11.21.205 admin_server = 10.11.21.205 } [domain_realm] .alationdata.com = TEST.ALATIONDATA.COM alationdata.com = TEST.ALATIONDATA.COM
You can test the Kerberos credentials by running KINIT as the service account and, after KINIT then running KVNO for the service principal of the database resource. KINIT establishes that the host reached the KDC and got a valid TGT. KVNO fetches a service ticket for the service principal Both need to be authenticated from Alation:
kinit <USER_PRINCIPAL_NAME> kvno <SERVICE_PRINCIPAL_NAME/HOST@REALM>
For example:
kinit alation_user kvno hive/[email protected]
If using keytabs, do the following, substituting <path to keytab> with the path to your keytab file:
kinit -k -t <path to keytab> <USER_PRINCIPAL_NAME> kvno <SERVICE_PRINCIPAL_NAME/HOST@REALM>
Alation does not use Kerberos ticket cache. The above tests validate the Kerberos configuration: if KINIT and/or KVNO fail, this would be a Kerberos configuration issue that needs to be resolved in your infrastructure before you try to connect to your Kerberized source from Alation.
Configuring Kerberos After Installing Alation¶
If Kerberos configuration is added after Alation is installed, you will need to create a valid krb5.conf file on the host running Alation then copies it to the Alation environment.
To import the krb5.conf into Alation,
Copy the valid krb5.conf file into the Alation file system:
sudo cp krb5.conf /data/site_data/krb5.conf
Enter the Alation shell:
sudo /etc/init.d/alation shell
Run the following actions to copy and deploy the configuration:
alation_action copy_krb5_conf alation_action deploy_conf_kerberos
Exit the shell:
exit
Restart Alation:
sudo service alation restart
Check that the configuration values are stored in the Alation configuration, from inside the Alation shell:
alation_conf kerberos
Troubleshooting¶
You can turn on Kerberos debugging in Alation logs to help you troubleshoot issues with connection in Alation. Kerberos debugging logs into taskserver_out.log and taskserver.log at /opt/alation/site/logs.
To add debugging,
Enter the Alation shell and change user to alation:
sudo service alation shell sudo su alation
Make sure you don’t already have extra flags set that may be overwritten by any new flags:
alation_conf extra
If extra flags already exist for Taskserver and Connector, edit the corresponding line to include the new flag:
-Dsun.security.krb5.debug=true
Example:
alation_conf extra alation_conf taskserver.extra_flags -s ' -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true'
Deploy the changes and restart the java component:
alation_conf extra alation_action deploy_conf_supervisor alation_supervisor restart java:*