Hello @AndyWilliams86 & @JuanS_OCS,
I’d like to take some time to present some additional information on some of the further Kerberos related topics. If you’d like further information beyond this please keep an eye out for my paper “Extending the Reach of Kerberos Authentication from SAS® Viya® 3.4 to Apache Hadoop” at SAS Global Forum this year, and if you are attending in person please come by the Quad and say hello.
At the time of this writing, there is a software bug that prevents this from working completely as designed. The fix has been identified and is being packaged – watch the Hot fix Announcements board for availability. If you need more proactive tracking of issues please work with SAS Technical Support who can look at your environment in much closer detail.
Scheduling
Scheduling within an environment configured for Kerberos authentication presents challenges. Kerberos tickets, by design are only valid for relatively short periods of time. Kerberos defines two lifetimes for a given ticket, the current lifetime of the ticket, and if configured with the Key Distribution Center (KDC) a renewable lifetime. A ticket still within its initial lifetime can be renewed up to its renewable lifetime. Once the renewable lifetime has expired, the end-user must authenticate again. Not all tickets are renewable, in which case they expire as soon as the ticket lifetime expires.
If we consider Microsoft Active Directory, by default your user’s Kerberos Ticket-Granting Ticket (TGT) will be valid for 10 hours and can be renewed for 7 days. So, if you log into your SAS Viya 3.4 environment at 9am and schedule a task to run every day at 9pm, you can see that you would expect to have issues. Even the first run of the task is going to take place 12 hours after you logged in, so your TGT will have expired before the task is run.
SAS provides a couple of technologies to assist with the expiring credentials. First, so long as you remain logged into the SAS Viya 3.4 visual interfaces your Kerberos credentials are refreshed. The keep alive messages triggered by the different visual interfaces, such as SAS Environment Manager or SAS Visual Analytics, trigger re-authentication to SAS Logon Manager. This means that the stored TGT is refreshed if you are logged in. So, in our example above if you stay logged in until 5pm, your TGT will now be valid for running that task at 9pm.
But what about the weekends or when you take vacation. The other technology SAS provides is the ability for SAS Cloud Analytic Services and the SAS Launcher Server to fallback to using a username & password. This username & password are not prompted for; they must be stored before-hand. The username & password are stored in an Authentication Domain in SAS Environment Manager, by default called DefaultAuth. This username & password could be stored individually for a user or associated with a group and made available to all members of the group. Only one username & password set should be available to a given user. This authentication flow is illustrated here:
Finally, for a SAS Viya 3.4 environment on Linux, SAS Cloud Analytic Services can also fall back to directly launching the session. This session, for your users who are members of CASHostAccountRequired, will not have access to any Kerberos credentials and so cannot access your secured third-party data source. However, it will be able to access data already loaded into memory, which is useful for running scheduled reports.
Therefore, you can see scheduling adds complexity to the Kerberos configuration, but does not become impossible. You just need to carefully plan who will be able to schedule depending on what they need access to.
SAS Administration CLI & SAS Visual Analytics App
With either SAS Viya 3.4 on Windows or the September 2018 release of SAS Viya 3.4 on Linux, Kerberos can be used with both the SAS Administration Command-Line Interface (CLI) and the SAS Visual Analytics App on mobile devices. Even when SAS Logon Manager is configured for Kerberos authentication, both applications still allow for connections using username & password. This is due to these applications accessing a different end-point of SAS Logon Manager that is not secured with Kerberos. However, when a connection is made using a username & password, SAS Logon Manager initializes a Kerberos credential for your end-user. This Kerberos credential is then stored with the Credentials microservice, and is available for further connections, for example to SAS Cloud Analytic Services.
In addition, the latest version of the SAS Administration CLI, available here: https://support.sas.com/downloads/package.htm?pid=2133, can also use Kerberos authentication for logging into your SAS Viya 3.4 environment. Kerberos support for logging in with the SAS Administration CLI is split based on the execution platform (Windows, Linux, OS-X):
The Windows support utilizes the Windows SSPI via system calls.
The Linux support utilizes a GSSAPI implementation using CGO to call the underlying GSSAPI C libraries.
The direct OS-X support is currently disabled.
If you will run the SAS Administration CLI from a Linux host, the correct underlying GSSAPI C libraries must be installed. On a RedHat system this can be completed with the following command as root:
yum install -y krb5-devel
which will provide the /usr/lib64/libgssapi_krb5.so library. On a SUSE system this can be installed with the following command as root:
zypper install krb5
This provides the necessary infrastructure for the SAS Administration CLI to leverage Kerberos for authentication. Before using the SAS Administration CLI that you have downloaded, you need to install the CLI plug-ins and setup the profile. These steps are covered in detail in the documentation. Even if using the SAS Administration CLI on a Linux host where the original version has been run you must still set up the profile again.
Using Kerberos authentication to log into the SAS Administration CLI requires that you change the initial command to log into the SAS Viya 3.4 environment. You must use the following:
./sas-admin auth kerberos
You should see the following message:
Login succeeded. Token saved.
If you include --verbose on the command, you can review the HTTP requests/responses sent to SAS Logon Manager. You will then see the 401 HTTP response from the request to SAS Logon Manager with the Www-Authenticate: Negotiate header, notice this GET request is to /SASLogon. Alternatively, when using username & password the command line is:
./sas-admin auth login
Again, including --verbose, now shows a POST message sent to /SASLogon/oauth/token after entering your username & password.
Hopefully this gives you a better understanding of the use of Kerberos authentication, especially in conjunction with scheduling. As mentioned, if you have more questions specific to your environment, please feel free to contact SAS Technical Support.
Thank you
Stuart
... View more