SAS Viya 3.2 CAS Kerberos Out-bound

4 Likes

As a follow-on from my previous post, where we looked at some Kerberos Principles, in this blog I want to explorer further what is required to enable Kerberos out-bound authentication from SAS Cloud Analytic Services to a Secured Hadoop environment.

Specifically, in this blog I want to focus on the first Use Case we presented previously. As a reminder, here is the picture we presented:

In the previous post I was quite vague on just what is required to setup this form of authentication. I merely stated we need to provide some credentials in the form of a Kerberos keytab to the CAS Controller. We will look at this in a little more detail.

First what should be inside this keytab?

This keytab needs to contain the Kerberos long-term key(s) for a specific principal.

But what principal is required?

In SAS Viya 3.2 we are restricted in the form of this principal. This principal must be in the form of a Service Principal Name, so of the form <Service Class>/<Fully Qualified Hostname>. The default Service Class is sascas, but this can be changed by defining an environment variable for CAS. If we set the following environment variable in the casconfig.lua:

-- Add Env Variable for SPN
env.CAS_SERVER_PRINCIPAL = 'CAS/HOSTNAME.COMPANY.COM'

We can change the value of the Service Class. However, this must still be a Service Principal Name format. Even if we skip the "/HOSTNAME.COMPANY.COM" the CAS Controller will automatically substitute its own fully qualified hostname.

What does CAS do with the keytab?

So, in this use case what is the CAS Controller going to do with this credential in the Keytab? We need the CAS Controller to be able to obtain a Kerberos Ticket-Granting Ticket (TGT) using these credentials. Which means that we need to be able to perform a kinit using those credentials. Specifically, if we want to test we need to be able to do the following:

kinit -V -kt /etc/sascas.keytab sascas/hostname.company.com@REALM.COM

And should see something like the following:

Using default cache: /tmp/krb5cc_2220
Using principal: sascas/hostname.company.com@REALM.COM
Using keytab: /etc/sascas.keytab
Authenticated to Kerberos v5

That seems simple enough.

Active Directory Service Accounts

But what does this mean when we are using Active Directory as the Kerberos Key Distribution Center? For Active Directory if we want to be able to kinit as a principal, then that principal must be a User Principal Name. This means that the account which has the CAS Service Principal Name registered against it must have the User Principal Name set to the same value.

Where should the keytab be?

By default the CAS Controller is going to look for the keytab in the /etc directory and will expect the file to be called sascas.keytab, therefore the default is going to be /etc/sascas.keytab. However, the /etc directory is normally locked down and you might not want to put a file specific to the CAS Controller in the /etc directory. Again, by setting an environment variable in the casconfig.lua we can put the keytab anywhere on the system. We can use the following to point to the keytab:

-- Add Env Variable for keytab location
env.KRB5_KTNAME = '/opt/sas/cas.keytab'

How do we enable it

Finally, we need to tell the CAS Controller to use this keytab to initialize the Kerberos credentials. To do this we need to update the provider list in the casconfig.lua. The value initkerb needs to be added to the existing list so that the result looks like the following:

cas.provlist = 'oauth.ext.initkerb'

With all this in place we can restart the CAS Controller and during startup it will read the keytab and initialize the Kerberos credentials. Then we will be able to use the Visual Interfaces to access the Secured Hadoop environment.

What if something is wrong?

However, what if something is wrong? If the provider list is updated, but we either get the environment variable for the keytab wrong, or the file permissions wrong so the CAS Controller cannot access the keytab then the CAS Controller will abort. This means the CAS Controller will start and then stop. In the log file for the CAS Controller we will see:

2017-06-23T08:45:34,099 INFO  [00000003] cas local MAIN NoUser  [tkidentgss.c:121] - Kerberos authentication failure in function gss_acquire_cred: Unspecified GSS failure.  Minor code may provide more information.
2017-06-23T08:45:34,099 INFO  [00000003] cas local MAIN NoUser  [tkidentgss.c:162] - Additional information: Keytab FILE:/etc/sascas.keytab is nonexistent or empty.
2017-06-23T08:45:34,099 ERROR [00000003] cas local MAIN NoUser  [tkident.c:4168] - Invalid provider list specified: oauth.ext.initkerb.
2017-06-23T08:45:34,099 FATAL [00000003] cas local MAIN NoUser  [cas.c:1492] - TKIDENT second phase initialization failed.

Alternatively, if the keytab is present and readable, but the principal is incorrect the CAS Controller will start and continue running. However, we won’t have any Kerberos credentials to access the Secured Hadoop environment and in the CAS Controller log we will see:

2017-06-23T08:28:39,624 WARN  [00000016] sas.monitoring local MAIN NoUser  [tkidentgss.c:279] - Kerberos failure in function krb5_get_init_creds_keytab: Client 'sascas/hostname.company.com@REALM.COM' not found in Kerberos database (96C73A06).
2017-06-23T08:28:39,624 ERROR [00000016] sas.monitoring local MAIN NoUser  [tkidentgss.c:1495] - Failed to initialize credentials using keytab /etc/sascas.keytab.

Both these sets of messages are available at the default level of logging. No additional logging needs to be enabled to see these messages.

I hope that this assists you in getting Kerberos authentication working outbound from SAS Cloud Analytic Services. In future posts we will look at the use case of Remote HDFS and look at what changes in Viya 3.3.

Stuart Rogers