Does your site have multiple people maintaining a single deployment of SAS? Is it important for them to maintain a clear audit trail of who is doing what exactly? Or do you need to update your SAS deployment using different userids? Let's take a look at some techniques to manage these activities as you work with the SAS Installer account.

Many organizations increasingly avoid the use of shared user accounts to ensure that their IT departments can track and report which people are using (or modifying!) the hardware and software services.  The SAS Installer account, which is used to install and configure SAS deployments, is frequently targeted as the subject of such audit control.

Often, the SAS Installer account is not tied directly to an individual. For many SAS deployments, a group of systems administrators may know how to log into the environment using the SAS Installer account. If they use the same account, for audit purposes, it’s difficult to look at the normal logs and determine who is acting as SAS Installer for a given action.  Depending on your host operating system, here are three different methods for overcoming this issue:

Secret credentials--simple, but impractical

Of course, the SAS Installer's account credentials could be kept secret, known to just one person. The obvious problem here is that there's just one person who can log on and fix any problem with the environment. While secure and auditable, it's just not sustainable for any enterprise deployment of SAS.

Shared account with different users

Using a common or shared userid like the SAS Installer account definitely has some major benefits. Having a single account for maintaining software makes it simpler to keep all historical collateral (such as configuration files or environment variables) in one place for future reference. It also provides greater control to manage runtime settings like ulimits and filesystem access. And, of course, avoiding an individual person's userid for an enterprise installation of SAS is helpful when that person moves on to other work.

For many platforms, a proven practice is that the user account that installed SAS be the only one that can update it later. If you installed originally with the sas id, then all subsequent hotfixes and updates should use that same sas id. But if your organization wants to track which individual person is actually performing this work, what should you do?

Fortunately, this issue is easy to resolve: Establish a procedure that prohibits anyone from logging onto the SAS installer account directly. Using the UNIX operating system as an example, the system administrator should follow these steps:

1. Log on with his or her personal credentials
2. Submit the su - sas command to switch user to operate as the SAS Installer account
3. Modify or update the SAS software
4. Log out of the su identity and return to your own shell

When any kind of logon activity occurs, including switching users, the UNIX operating system logs that action in a file such as /var/log/secure. The log will state something similar to:

Nov 1 08:22:00 localhost su: pam_unix: session opened for user sas by sallysmith

where

• sallysmith = personal user id on the system
• sas = the SAS Installer account
• Date, time, location, authorization mechanism for contextual details

Now, if a system auditor wants to know who updated the SAS deployment with the SAS Installer account on the morning of November 1, that information is stored in the standard log location.

Using the su command to switch users sometimes lead to complications, especially with X windows and software (like the SAS Deployment Wizard) that rely on it. See Getting X11 forwarding through ssh working after running su on the Debian Administration site for a work-around.

Updating SAS with a different user account

There may be times when you must update your SAS deployment with a different userid than the original SAS Installer account. Perhaps the original installer has moved on to a new role elsewhere in the company, or there’s been some procedural change where designating a new installer userid for the SAS installation is necessary. The SAS Deployment Manager has a feature to support this scenario; however, it’s recommended that you work with a Technical Support representative when by-passing the same-user guideline.

The SAS Deployment Manager is often used to deploy hotfixes to SAS. Before updating an installation, it performs a check to confirm that it's running under the same userid that installed SAS in the first place.

The SAS Deployment Manager executable, or sasdm command (.exe, .rexx, .sh), can be invoked with the optional -skipusercheck parameter if there is a need to install hotfixes with a different user account. Before doing so, it’s important to meet the following requirements:

• The logged-in user should have the same permissions as the user that performed the deployment
• The userid installing the hot fix must have the authority to create new data sets with the same high-level qualifier as the existing installation and modify the existing data sets
• For UNIX and z/OS, the ownership of the entire SAS tree also must be changed to the new installer ID
• For Windows, the new installer ID needs the same administrator-level privileges as the original installer.

Caution for UNIX and z/OS:  While the -skipusercheck functionality is supported by SAS, making mass ownership changes to the execution files of a SAS enterprise deployment should treated as a significant risk and managed appropriately.

Caution for Windows: While updates with a different account from the original SAS Installer is supported, using just any person’s administrative account for updating SAS is not recommended.

Conclusion

In closing, I highly recommended that you become familiar with the SAS® Deployment Wizard and SAS® Deployment Manager 9.4: User's Guide. It explains many of the system requirements and concepts necessary to support installing and updating SAS software, including how different user accounts can be supported.

Image provided by jenny downing//attribution by creative commons