2月 102017

Since the SAS 9.4 M2 release in December 2014, there have been several refinements and updates to the middle tier that are of interest to installers and administrators. In this blog, I’m going to summarize them for you. What I’m describing here is available in the newest SAS release (9.4 M4). I’ll describe them at a high level, and refer you to the documentation for details and how to implement some of these changes.

Security enhancements

Preserve your TLS Customizations:
For security purposes, many of you will manually add TLS configurations, either to the SAS Web Server, the SAS Web Application Server, or both. In addition, you may prefer to use your own reverse proxy server (such as IIS), either instead of, or in addition to, the SAS Web Server. Before the 9.4 M4 release, when upgrading or applying maintenance, you had to undo these custom configurations, perform the upgrade, and then apply the custom configurations again. Now, the upgrade will preserve them, making the process much easier. See Middle-Tier Security in the Middle Tier Administration Guide, Fourth Edition for full details.

Newer versions of OpenSSL are now provided (see doc for specific version numbers):
A Java upgrade enables enforcement of TLSv2. TLS is now considered the security standard for https connections, (SSL is obsolete) and this can be enforced with configurations to the SAS Web Server and the SAS Web Application Server. The new version of Java SAS is using (Ver 1.7+) now allows for this. One important thing to be aware of is that certificates are completely independent of which protocol you are using, and therefore any certificates you may have been using with SSL should work equally with newer TLS protocols.

Management of the trusted CA (Certificate Authority) bundle:
SAS now has a trusted CA bundle, that can be managed by the SAS Deployment Manager, in a new location:  SASHome/SASSecurityCertificateFramework/1.1/cacerts/. The CA certificates can be root certificates, intermediate certificates, or both. Here’s what the menu item looks like:

Middle Tier Changes and Upgrades in SAS 9.4 M4

Previously it was necessary to manually add your root/intermediate certificates to the Java truststore “cacerts,” located inside the JRE; now it’s done through the new interface. If you are on Windows, you must also add trusted CAs to the Windows store (as before), which will make them available to any browsers running there. This is documented at and elsewhere online.

Security Support for SAS Web Applications – white list external sites, and HTTP request methods:
For added security, web sites hosting SAS web applications can now maintain a white list of external URLs that are allowed to connect in. This provides protection against Cross Site Request Forgeries, and other vulnerabilities. This is what the prompt looks like in the SDW:

Middle Tier Changes and Upgrades in SAS 9.4 M4

HTTP request methods can also be specified as allowed/not allowed. The list of URLs can be specified during installation in the SDW (shown above), or using the SAS Management Console. You can disable whitelist checking entirely, and you can add a “blacklist” or specific sites to always block. You can also block based on request method–ie, GET, POST, PUT, etc. See the Middle Tier Administration Guide for details.

Forward Proxy Configuration:
You can now set up SAS web applications to forward external URL requests through a proxy–here it’s called a forward proxy server. Many organizations do this behind their firewalls. See details for how to set this up in the administration guide.

Other miscellaneous changes:
As an administrator you can now force users to Log Off using SAS Web Administration Console.    You can also send emails to one or more users from the same window.  This is what the menu looks like:

Middle Tier Changes and Upgrades in SAS 9.4 M4

Faster start-up time for the SAS Web Application Server

JMS Broker (ActiveMQ) now uses Version 5.12.2 (fixed bugs).

SAS Web Server now uses version 5.5.2 and includes an updated mod_proxy_connect module for TLS tunneling.


SAS 9.4 Intelligence Platform: Middle Tier Administration Guide, Fourth Edition

Encryption in SAS 9.4, Sixth Edition


tags: SAS 9.4, SAS Administrators, SAS Professional Services, security

Middle Tier Changes and Upgrades in SAS 9.4 M4 was published on SAS Users.

8月 232016

Managing Server Access for SAS Mobile BI UsersTablets, phablets, smartphones.

These mobile devices not only travel to different corners of the earth with their owners; they participate in certain adventures that can result in an unexpected turn of events.

Thanks to their mobility, these devices can be misplaced. And they could be found later. In rare cases, they can get lost. In the event that a user is separated from his or her mobile device, there are security mechanisms in place for protecting access to your organization’s server where data and reports reside.

Whether mobile devices accompany their SAS Mobile BI 7.33 users to the Himalayas or to the Sahara Desert, they certainly need to be tracked and managed by administrators. In my last blog, I talked about how an app-specific passcode protects access to the SAS Mobile BI app by preventing anyone other than the SAS Mobile BI user from accessing the app on the mobile device. Now, let’s take a look at how your administrators manage and protect access from the SAS Mobile BI app on your devices to connect to servers in your organization.

The SAS Visual Analytics 7.3 suite of applications includes the Administrator application with the Mobile Devices tab. The Mobile Devices tab is somewhat like an air traffic control system for an airport. Just as airplanes that land and take off are monitored and managed at the air traffic control tower by personnel, mobile devices that connect to your organization’s server with the SAS Mobile BI app are monitored and managed in the Administrator application’s Mobile Devices tab.

SAS Visual Analytics Administrator runs on the same server where your SAS Visual Analytics reports are stored and accessed. It maintains a logon history that informs your administrator details regarding mobile devices that logged on or attempted to log on to the server from the SAS Mobile BI app. For example, a timestamp indicates when a device connected to the server. A management history equips administrators with data on mobile devices that were whitelisted, blacklisted, or removed from either the whitelist or the blacklist.

Managing Mobile Devices

Regardless of how many mobile devices are installed with the SAS Mobile BI app, security administration is required for every device that accesses data and reports on the server. Every mobile device has a unique identifier, and this unique identifier is used by SAS Visual Analytics Administrator to determine if the device is allowed to access the server.

To control mobile devices’ access to your organization’s server, your administrator manages server access by implementing either a whitelist or a blacklist from the server. By default, blacklisting is enforced on servers that are accessed by the SAS Mobile BI app.

Inclusion Approach to Managing Devices

The whitelist scenario follows the inclusion approach. By default, you cannot connect to the server via SAS Mobile BI until your device ID is added to the whitelist by your administrator. If the unique device ID is added to the whitelist by your administrator, you can use the device to subscribe, view, and interact with SAS Visual Analytics reports (via the SAS Mobile BI app).

Exclusion Approach to Managing Devices

In the blacklist scenario, it is the exclusion approach. By default, everyone can connect to the server from SAS Mobile BI on their mobile devices unless their device IDs are added to the blacklist by the administrator. Any device whose unique device ID is not added to the blacklist can connect to the server from the SAS Mobile BI app. For instance, if you lost your mobile device, your administrator can go to the Logon History, select the device (listed by device ID, user name etc), and add it to the blacklist. Then, you cannot use the device to log on to the server from the app.

The Easy Way to Switch from Blacklisting to Whitelisting

By default, blacklisting is enforced on the server that is accessed by the SAS Mobile BI app, and the configuration property in SAS Management Console (SAS Configuration Manager for SAS Visual Analytics Transport Service) is set to false. If you are an administrator, and wish to switch from blacklisting to whitelisting, the easiest way to do it is to select whitelisting in the Administrator’s Mobile Devices tab and add the device IDs to the whitelist. Then, the configuration property in SAS Management Console is automatically updated and set to true. This is an easier method for switching from blacklisting to whitelisting because it does not require a restarting of the server. If you were to go to SAS Management Console first and set the configuration property to true, this action requires you to restart the server.

Request to Add Devices to a Whitelist

There are a couple of different ways that your administrator can obtain and add device IDs to a whitelist. If the unique device ID is already known to your administrator, he or she can easily add it to the whitelist in the Administrator application’s Mobile Devices tab. Alternatively, if you happen to install SAS Mobile BI app on a new mobile device that is not being managed from the server, the app can take you to your email with template text that includes your mobile device ID – just send that email to your administrator requesting server access from your mobile device.

Suspending or Allowing Server Access from the App

Now here is my most favorite part of device management. Access from SAS Mobile BI to the server, as we have just noted, is determined by either whitelist or blacklist management of devices, not by user accounts. This approach extends flexibility for SAS Mobile BI users. For example, I have an iPhone and a Galaxy Tab Pro tablet – I have SAS Mobile BI app on both devices, and I use both of them to access the server, subscribe to SAS Visual Analytics reports, view, and interact with them. If I happen to misplace my Galaxy Tab Pro tablet and can’t seem to find it, I notify my administrator so that server access from the app on this device can be removed.

My administrator, who follows the whitelist approach, removes my Galaxy Tab Pro’s unique device ID from the whitelist. Then, I can no longer use the SAS Mobile BI app on this device to log on to our server and subscribe to SAS Visual Analytics reports. However, I can continue to use my iPhone (which has remained in the whitelist) to log on to the server, subscribe, view and interact with reports on the server.

Few days later, I find my misplaced Galaxy Tab Pro tablet. I email my administrator indicating that the device is back in my possession. My administrator adds the unique device ID for my Galaxy Tab Pro back to the server’s whitelist. Voila – I am back in business, using SAS Mobile BI to connect to the server from my Android tablet.

In a Nutshell

There are several mechanisms available for securing the SAS Mobile BI app and access to your organization’s servers is one of them. In my next blog, we will take a look at how tethering works to protect data access for SAS Visual Analytics reports from the SAS Mobile BI app.

tags: SAS Mobile BI, SAS Visual Analytics Administrator, security

Managing Server Access for SAS Mobile BI Users was published on SAS Users.

8月 082016

Passcode security for SAS Mobile BIMobile devices travel with humans pretty much anywhere that humans want to go. Unlike desktop computers that stay fixed and grounded within brick and mortar walls, mobile devices are used in all sorts of locales – offices, homes, cars, planes, swimming pools, soccer fields, movie theaters – the list goes on. So, it’s no surprise that your SAS administrator would want to protect SAS Visual Analytics reports that are viewed from the SAS Mobile BI 7.33 app running on mobile devices.

Several security strategies are available for SAS Mobile BI users. Let’s take a look at how passcode security, along with Touch ID for Apple devices, protects access to the app.

Required vs. Optional Passcode

There are two ways to apply passcode protection to SAS Mobile BI. Your administrator can enforce a passcode requirement for the server where the SAS Visual Analytics reports reside. On the server, this is done by enabling the Require Passcode on Mobile Devices capability and adding users as members of the group that is required to create and use a passcode for accessing SAS Mobile BI.

If a passcode is not required by your administrator, you can create an optional passcode to protect access to the app on your mobile device. In either scenario, if your mobile device is used by someone other than you, then you have the peace of mind that only you can access SAS Mobile BI by entering your passcode.

Creating an Optional Passcode

To set up an optional passcode for SAS Mobile BI, go to Settings for the app. Tap on the toggle switch for Passcode lock and create a passcode.

Passcode security for SAS Mobile BI

Optional Passcode Lock in Settings.

When presented with the Passcode dialog, create a 4-digit passcode for SAS Mobile BI.

Passcode security for SAS Mobile BI01

Creating a Passcode

By default, anytime that you access SAS Mobile BI after 5 minutes of inactivity (or for the period of inactivity that is set by your administrator), you are prompted by the Passcode dialog to enter your passcode.

Passcode security for SAS Mobile BI02

Entering Your Passcode to Access the App

If the passcode is mandated and not optional, then your administrator can customize and set a different inactivity timeout before a passcode needs to be entered.

What Happens If You Enter Incorrect Passcodes?

If you enter an incorrect passcode, you are given a total of 10 attempts to enter your correct passcode. This is the default behavior when you have an optional passcode for the app. Administrators that mandate the need for a passcode with the Require Passcode on Mobile Devices capability on the server can customize the settings for the server to determine the number of wrong passcode attempts.

Passcode security for SAS Mobile BI03

Entering an Incorrect Passcode

If you enter an incorrect passcode 10 times, you are locked out for 15. When the lock-out expires, you are prompted again to enter your passcode.

Passcode security for SAS Mobile BI04

Application Reset

When the lock-out expires, you are prompted again to enter your passcode.  On the second attempt, if you exceed the allowed number of passcode entry attempts, SAS Mobile BI removes all reports, data, and server connections from your mobile device. The app is reset to its default settings.

Passcode security for SAS Mobile BI05

Just Can’t Remember Your Passcode?

If you forget your passcode, the easy thing to do is delete the app, download and reinstall the app, create a new passcode, and set up your connections to the servers with SAS Visual Analytics reports.

Touch ID for Apple Devices

If you are an Apple device user who has simplified life further by using a Touch ID instead of a passcode, you can use the Touch ID to access the SAS Mobile BI app. To enable Touch ID on your iPhone or iPad, follow these instructions from Apple to add your fingerprint and create a Touch ID for your Apple device.

If Touch ID is enabled for your device, and there is an inactivity period with SAS Mobile BI, the app prompts you for your Touch ID fingerprint:

Passcode security for SAS Mobile BI06

Touch ID Prompt for SAS Mobile BI on Apple Devices

If your Touch ID fingerprint is incorrect, then the app prompts you to enter your passcode:

Passcode security for SAS Mobile BI07

Passcode Prompt if Touch ID is Incorrect

Now, you are familiarized with securing access to SAS Mobile BI on your devices. We will continue this journey to learn about various other security options available for the app.



tags: SAS Mobile BI, security

Passcode security for SAS Mobile BI was published on SAS Users.

8月 032016

Some weeks have passed since the United Kingdom voted, by a margin of 52 per cent for and 48 per cent against, to leave the European Union, the organization it's been a leading member of since 1973. The tumultuous global reaction to the vote has those of us in information […]

How will Brexit impact cybersecurity? was published on SAS Voices.

6月 142016

“Good afternoon, Mr. Yakamoto. How did you like that three-pack of tank tops you bought last time you were in?” Washington D.C. Year 2054. Chief of PreCrime John Anderton is running from the law for a crime he has not committed yet. After a risky eye transplant in order to […]

Location analytics and the 'Minority Report' approach was published on SAS Voices.

7月 312015

SecurityEncryption and SAS is a wide ranging topic – so wide it gets its own book and features strongly in both the SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition and SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Third Edition. In this blog we’ll take a high level look at what is involved in using HTTPS encryption in-transit within a SAS deployment.

This blog will provide an overview of considerations when designing for security requirements that include encryption and will be the first in a series of blog discussions around encryption.

Why use encryption?

Many customers both from a business and IT perspective are becoming more concerned about encryption. For some, this concern comes from industry regulation (think here of the banking sector). For many others, the sheer number of news stories about data breaches and the costs to business are raising the priority of encryption. We are definitely moving towards a world where the default is to encrypt.

This greater focus on security in general can be seen here at SAS as well. We have the Security Assurance page on and the associated SAS® Software Security Framework. We also have a place for security bulletins on

One aspect of security that is becoming more and more common for SAS customers is the use of encryption for data in-transit. Customers’ are either externalizing resources, making them available to the wider internet, moving towards cloud based deployment models, or even becoming more concerned over network security within their own organizations.


Does that mean it’s in a van? Nope – what we mean when we say data in-transit is that it is data passing from one process to another. The end points might be on the same host or on different hosts. For encryption, we split the topic into two areas: data being transmitted or in-transit, and data sitting in a file or database, so at-rest. Whilst many principles of encryption apply to either data in-transit or at-rest, most methods of applying encryption are different depending on whether the data is at-rest or in-transit.

The most common use of encryption for data in-transit is to wrap encryption around traditional HTTP transmissions. The move away from using HTTP as a default and defaulting to secure HTTP (HTTPS) can be seen in many areas of the World Wide Web. We expect our webmail or banking systems to encrypt the traffic from the browser to the server by using HTTPS, but this is now starting to extend through to many other sites as concerns over confidentiality spread. Google, Facebook, and even Wikipedia now use HTTPS as the default rather than HTTP.


The expectation is that you can use HTTPS to replace HTTP connections. So, let’s highlight the use of HTTPS within a typical SAS deployment.


Most SAS administrators and security professionals will expect several items on this diagram. Obviously, if a customer is asking for HTTPS we would expect to see the SAS Web Server called out along with the browser based clients. Some of the other SAS components that need to communicate over HTTPS might not be so obvious.

  • The SAS Environment Manager Server includes a web application server that can be configured for HTTPS on the default port of 7443.
  • The SAS Web Application Server instances can also be configured for HTTPS instead of the default HTTP. There might be multiple instances of the SAS Web Application Server deployed to support scalability and redundancy of the SAS web applications. With multiple instances, the proven practice is to configure the connections for each instance in the same way, either with HTTP or HTTPS.
  • Clients such as SAS Management Console can make connections to the SAS Content Server and will need to communicate over HTTPS if the SAS Web Server is configured for HTTPS.
  • The analytical clients like SAS Enterprise Miner & SAS Forecast Studio make all their connections to the server tier via the middle-tier and are built to enable HTTPS communication, but this must be configured.
  • The SAS Application Servers, such as Workspace Servers are also clients of the middle-tier for actions such as publishing to WebDAV, interacting with the LASR Authorization Service and components like the SAS Information Retrieval Studio.

What this illustrates is that just the requirement of having encryption for the SAS Middle-Tier i.e. HTTPS connections to the SAS Web Server can be quite complex, and requires understanding the interactions of the different components.

Setting up complete use of HTTPS requires a mixture of automatic and manual configuration. More details of these configuration steps can be found in the SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Third Edition. The options for how to configure the components to use HTTPS vary, and need to be managed carefully. The SAS Deployment Wizard is able to configure HTTPS with the SAS Web Server and SAS Environment Manager Server but does not configure the SAS Web Application Server.

Where does it end?

Important questions for the use of HTTPS with the middle-tier include: Just where does it end? How far do you want the encryption to go? Is it important to encrypt everything or just to encrypt the traffic to and from the SAS Web Server? The diagram below illustrates encrypting all the way through the middle-tier.


One issue which can impact on how far you carry the encryption is that of secure cookies. If you have a requirement to secure the cookies used in the environment, then you need to configure HTTPS for all the connections to and from SAS Web Server and SAS Web Application Server.

Who do you trust?

In addition to working out which components you need to configure for HTTPS, you also need to think about trust. The client, even if that client is a SAS Workspace session, needs to be able to trust the certificate presented by a server. Trust in the case of HTTPS means that the client must be able to “know” or “trust” who validated or signed the server certificate. When the client trusts the validator, it can then trust that the server is who it claims to be. So the client is able to trust that the bank is really the bank and not someone pretending to be the bank.

If you’ve gone with site-signed, self-signed, or even some third-party signed certificates, how do you tell the clients to trust them? You are not going to see a pop-up message from a remote Workspace session asking you if you are sure you want to trust the certificate, in the way a browser prompts the user as shown here:


Separate configuration steps need to be taken to make this trust automatic. This is an area where administrators can run into problems when implementing HTTPS. The issues of trust are important enough to warrant their own posting, so look out for my next blog where we’ll discuss trust in more detail.


Hopefully, this blog posting has given you a high level feeling for the considerations that can be involved in deploying some encryption technologies in your environment. Remember this blog only touched on the subject of TLS with the SAS Middle-Tier. Encryption for other parts of a SAS environment are provided with SAS/SECURE which is included with all SAS deployments (unless prohibited by import/export restrictions). I encourage you to review the Encryption in SAS® 9.4, Fifth Edition book and start to explore what is required for installing and configuring TLS and certificates. More implementation details can be found in in both the SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition and SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Third Edition.

Look out for my next blog where we’ll look at issues around trust in a little more detail.

tags: encryption, SAS Administrators, security

SAS 9.4: Transport Layer Security (HTTPS) and SAS was published on SAS Users.

12月 242014

In researching material for an upcoming project, I investigated the SAS Deployment Backup and Recovery Tool available in SAS 9.4. Here are some of my findings on identifying what directories are included in a Backup and Recovery session and how to add custom directories to a backup configuration.

The SAS Backup and Recovery Tool is designed to provide an integrated method for backing up and recovering your SAS content across multiple tiers and machines. Note that this utility is a system-wide tool. It’s intended to back up an entire environment as opposed to a single machine in a multi-machine deployment.

What directories are included in a backup?

There is a directory called Backup created in the SAS configuration directory on the first execution of the Backup and Recovery Tool. This directory is created on every machine that is participating in the backup. It is used to contain the backup files and configuration information and is updated on each execution of the utility. In this directory, the file backupserver.log contains the log information associated with backups. Looking in this file, at the component, you can see the list of directories included in the backup.

List of files in SAS Backup and Recovery Tool

Specifying additional directories for the backup

The Backup and Recovery Tool does not back up the entire contents of your SAS configuration directories. As you can see from the list above, it backs up only these directories:

  • data directories
  • SASEnvironment directories
  • server configuration directories for each server in the SAS Server tier.

To back up additional directories under the SAS configuration directory, you must use the  sas-add-backup-customdir command. This command requires an input file, specified in JavaScript Object Notation (JSON) format, which contains the file specifications for the custom directory. This JSON file supplies the hostname and directory path that is to be backed up along with a unique identifier for each custom directory. Here is an example JSON-formatted input file:

JSON-formatted file

The custom directory is added to the backup configuration by using the sas-add-backup-customdir command in the batch tools directory (at SASHOME/SASPlatformObjectFramework/9.4/tools/admin). To display a list of additional directories that have been specified for backup, use the sas-display-backup-customdir command.

Backup command format

When performing an ad hoc backup, you will see the custom directory listed in the backup locations.


To learn more

More detail on the use of the Deployment Backup and Recovery Tool can be found in the SAS 9.4 Intelligence Platform: System Administration Guide under Backing Up and Restoring Your SAS Content.

There’s additional information about Using Backups and Restoring Customizations in the SAS 9.4 Guide to Software Updates.

tags: SAS Administrators, security
10月 152014

hadoop-HPAIn this post we dig deeper into the fourth recommended practice for securing the SAS-Hadoop environment through Kerberos authentication:

When configuring SAS and Hadoop jointly in a high-performance environment, ensure that all SAS servers are recognized by Kerberos.

Before explaining the complex steps in connecting to secure Hadoop within a SAS High-Performance Analytics environment such as SAS Visual Analytics, let’s start by reviewing a simpler connection from a standard SAS session through SAS/ACCESS for Hadoop.

Making connections in a standard SAS session

Hadoop_standard_thumbnailHere's a behind-the-scenes look at the steps involved in the connection. Click on the thumbnail to view the full diagram. This graphic depicts an environment where the SAS Servers are configured to authenticate the users with the same back-end directory server as the Hadoop instance. The setup is relatively straight-forward.

Let’s say a SAS user (we’ll call this user Mary) logs into her machine, and the standard Windows logon procedure obtains the Ticket-Granting Ticket (TGT) from the main corporate Active Directory. This step happens on all domain machines: Kerberos is tied into the standard deployment of Active Directory. Also, this step is completely isolated from Mary’s access to SAS.

At some later point in the day (perhaps after grabbing her morning cup of coffee!), Mary may open SAS Enterprise Guide. As we know, starting the SAS session makes a connection to the SAS Metadata Server, and her credentials (username and password) in the connection profile are authenticated by the Metadata Server. As we noted in previous posts, the SAS servers have been configured to use the same directory server as Hadoop, so this authentication step uses Pluggable Authentication Modules (PAM) to validate our user.

Next, SAS Enterprise Guide initiates Mary’s Workspace Session by connecting to the Object Spawner. The Object Spawner runs a shell script ( as “Mary” and spawns the Workspace Session. In this step, as her credentials are authenticated, the PAM stack on the server obtains a Ticket-Granting Ticket (TGT) for Mary. This TGT is going to be placed in her Ticket Cache, ready to be made use of later.

To Mary, all of this has happened as SAS Enterprise Guide was opened. She has not been required to perform any special actions to get to this stage. All the “magic” has been taking place behind the curtain.

So Mary can submit her SAS code to connect to Hadoop using the standard LIBNAME statement with the required options. (Remember username and password are not valid when connecting using Kerberos. They specify the Kerberos security principals instead.) Also as discussed last time, the step for connecting to Hadoop in a SAS session can be moved behind the curtain by ensuring the principals are in the configuration file used to make the connection to Hadoop. The Hadoop client libraries then use the TGT to request the Service Tickets for HIVE and/or HDFS, and SAS makes the connection to Hadoop using the Service Tickets. Our SAS user Mary is authenticated on the Hadoop side by validating the Service Tickets provided in the connection.

How connections are made in a SAS High-Performance Analytics session

Hadoop_HPA_thumbnailSo, this is the setup in a standard SAS session. What now happens if the environment uses something like SAS High-Performance Analytics or SAS Visual Analytics to make the connection to the secured Hadoop environment? Let’s look at the steps involved if our SAS user Mary wants to make a connection to SAS Visual Analytics. Click on the thumbnail to view a larger graphic showing these steps. Wow – that looks a bit more complicated under the covers! We’ll start with understanding how the connections are made and then look at some of the configuration options.

So, the starting points in this process are the same as before. We have the same steps occurring up to making the connection to Hadoop (step 7 in the diagram.) At this point, we’ll want to explore a little more detail about the connection that is made by the LIBNAME statement in Mary’s SAS code.

What wasn’t necessary to know when connecting with a standard SAS session is the fact that the XML configuration file is actually written to a temporary location in HDFS when Mary connects to Hadoop from SAS. This XML file will be used later by the distributed processes in the SAS High-Performance Analytics environment.

After submitting the LIBNAME statement to connect to Hadoop, Mary must now submits a PROC LASR or HP PROC statement to access the high-performance environment. Submitting these procedures initiates the SSH connection from the Workspace Session to the SASHigh-Performance Analytics Environment. Since Mary needs her SAS High Performance Analytics session to be Kerberos-aware, the SSH connection must be made using Kerberos. At this point, the SSH client uses the TGT to obtain a Service Ticket for HOST on the HPA General or LASR Root Node. SAS then uses the SSH client to start the HPA General and passes details of how to connect to HDFS.

The SSH Daemon (a server process running on the HPA General) generates a TGT for Mary on the HPA General as part of authenticating her credentials. This TGT on the HPA General is then used to request Service Tickets for all the worker nodes, and the parallel SSH connections are made to initialize the HPA Captains. With the HPA processes now running, the HPA General initiates the connection to Hadoop using the TGT—this time to request service tickets for HDFS and HIVE.

The HPA General connects to HDFS to retrieve the XML file placed there by the LIBNAME statement. Our SAS user Mary is authenticated using the Service Ticket for HDFS. The HPA General now submits a Map Reduce job. This Map Reduce job initiates the SAS Embedded Process (EP) running on the Hadoop nodes. The SAS Embedded Process connects first to the HPA General and then makes connections to the assigned HPA Captains using UNIX sockets. This process is not authenticated since the two sets of processes were already authenticated.

The SAS Embedded Process runs as a standard MapReduce job and has corresponding MapReduce tasks running on each node of the Hadoop environment. The MapReduce tasks connect as necessary to HDFS and HIVE using the standard Hadoop internal tokens. These tokens are used by the tasks of a MapReduce job rather than Kerberos tickets. More details about these internals of the Hadoop system can be found in the Hortonworks Technical Report:  Adding Security to Apache Hadoop. Each SAS Embedded Process then passes the data back and forth in parallel as required by the HPA processes.

Configuration requirements for SAS High-Performance Analytics

So while the diagram looks complicated, I believe we can distill this down into the following two requirements:

  1. The SAS Workspace Server must still have access to the users TGT.
  2. HPA General or LASR Root Node must have access to the users TGT.

The simplest method of ensuring that both the SAS Workspace Server and the HPA General or LASR Root Node have access to the user’s TGT is to configure SSH to use Kerberos and to ensure the following options are set.

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Setting these options on all SAS High-Performance Analytics Environment machines should ensure all SSH connections made using Kerberos will have a valid TGT obtained for each open session. Remember for SSH to use Kerberos, the HOST Service Principal must be registered in the Kerberos Key Distribution Center and the HOST keytab must be available on each machine (normally stored in /etc/krb5.keytab).

If you have questions about configuring SAS High-Performance Analytics to access a Kerberos-authenticated Hadoop environment or have other suggestion, please share them in the comment area below.

tags: Hadoop, Kerberos, SAS Administrators, security