Setting Up Users, Groups, and Ports

Defining User Accounts

There are two types of user accounts to understand when deploying SAS:

Internal user accounts are accounts known only to SAS and are created and authenticated internally in metadata rather than externally.
External user accounts are user accounts defined outside of SAS metadata. These accounts are local to a machine or are defined in a network directory service of which the machine is a member, such as LDAP.

The following sections describe the user accounts that SAS and third-party software require, and provide information to help you answer these questions:

What are internal and external user accounts?
What user rights or to what groups must each account be assigned?
Should I create local or network directory service accounts?
What password policies should I enforce?

This section contains the following topics:

Internal User Accounts

Internal user accounts are accounts known only to SAS and are created and authenticated internally in metadata rather than externally. SAS identifies internal accounts by appending a special string to the user ID. This string begins with an at sign (@) and contains saspw: @saspw. For two of the required user accounts, the SAS Administrator and the SAS Trusted User, the SAS Deployment Wizard prompts you by default to create internal user accounts.

The following table shows the default internal user accounts required by SAS. (SAS internal accounts are authenticated on the metadata server.)

SAS Internal User Accounts
Description	User ID
SAS Administrator-- The user account that has privileges associated with the SAS Metadata Unrestricted Users role.	sasadm@saspw
SAS Trusted User-- The user account that can impersonate other users on connections to the metadata server. Some SAS processes use this account to communicate with the metadata server on a client's behalf.	sastrust@saspw

For more information about SAS internal user accounts and their purposes, see Overview of Initial Roles, Groups, and Users in the SAS Intelligence Platform: System Administration Guide.

Here are some benefits of internal accounts:

less maintenance.

The account is defined only once in SAS, and you do not define this account externally using the authentication provider.
isolation from the host machine security policy.

The SAS Administrator and the SAS Trusted User credentials are referenced in many locations within SAS. For example, forcing a recurring password change (a common security policy) might make unnecessary work for the person administering SAS.
independence from IT.

You can create additional SAS unrestricted user and administrative user accounts for metadata management without involvement of your IT department.
reduced "headless" external user accounts.

The SAS Trusted User is an account used for SAS inter-process communication, and it will not be mistaken for a human user.
minimal security exposure to your enterprise.

The SAS Administrator and the SAS Trusted User are highly privileged accounts and only provide access to SAS--not to operating system resources.

Required External User Accounts for SAS

External user accounts are user accounts defined outside of SAS metadata. These accounts are local to a machine or are defined in a network directory service of which the machine is a member, such as LDAP. SAS requires certain external user accounts for two purposes: installation and running certain SAS server processes.

During installation and configuration, the SAS Deployment Wizard must run under an external account with the necessary privileges on the target machine to write SAS program and log files. To run servers such as the stored process server and the pooled workspace server, SAS requires an external user account to be the server process owner. For more information about external user accounts and their purposes, see the SAS Intelligence Platform: System Administration Guide.

As you set up external accounts, remember to use different external accounts for the SAS First User and the SAS Spawned Servers user. Otherwise, your configuration will end in errors and the SAS pooled workspace server will not be functional.

As you create these external user accounts, record information about them in Pre-installation Checklist for External User Accounts for SAS on Windows and UNIX or in Pre-installation Checklist for External User Accounts for SAS on z/OS. You will need this information when you run the SAS Deployment Wizard later.

Note: To validate your SAS deployment, you will need an external user account that is representative of a SAS client user, such as SAS Data Integration Studio, that must be the temporary process owner when its jobs are run on a standard workspace server. If Integrated Windows authentication (IWA) is not being implemented, it can be helpful to have the SAS Deployment Wizard create a SAS First User account in metadata during deployment for validation purposes. The wizard will also assign the required Log on as a batch job Windows user right for you. [cautionend]

The following table shows external user accounts required by SAS and the machines on which they are authenticated.

Required External User Accounts for SAS
Description	Recommended User ID	Machine Where Authenticated
SAS Installer-- The account used to install SAS.	sas	Every machine
SAS Spawned Servers account-- The process owner for stored process servers and pooled workspace servers.	sassrv	Stored process server Pooled workspace server

Note:

For information about the user rights that each external account requires, see Rights Required by External User Accounts for SAS.
UNIX: the SAS Installer generally overrides the default configuration directory with the site's preferred location (for example, /opt/sas/config). The installer must have Write permission on this path.
Windows: The SAS Installer user ID must be available in the long term for future SAS maintenance.
UNIX: Do not use root for the SAS Installer user ID.
AIX: For both user IDs, make sure that the User can LOGIN? setting is set to true.
z/OS: The SAS Installer and the SAS Spawned Servers account must have a TSO segment defined.
z/OS: By default, the SAS Installer:
- is the started task owner for the servers.
- is the owner of the configuration directory structure.
- must have a writable home directory in the UNIX file system.
- must have an OMVS segment definition with the following minimum settings:
  - ASSIZEMAX of at least 2 GB
  - CPUTIMEMAX of at least 5000 seconds
  - PROCUSERMAX of at least 50 users

Rights Required by External User Accounts for SAS

Operating systems require that you assign certain rights to the external user accounts used to deploy and to run SAS.

The following table describes the user rights needed by the required external user accounts to deploy and run SAS.

Rights Required by External User Accounts for SAS
External User Account	Operating System	User Rights Needed
SAS Installer	Windows	Administrator rights
	UNIX	Member of a group that is the primary group for the SAS Spawned Servers account
	z/OS	Default member of a group that also includes the SAS Spawned Servers account
SAS Spawned Servers account	Windows¹	Log on as a batch job
	UNIX	Member of a group that is the primary group for the SAS Installer
	z/OS	Member of a group that also includes the SAS Installer user
1 The SAS Deployment Wizard automatically assigns the Windows user right Log on as a batch job to the SAS Spawned Servers account.

On Windows, if you choose how to run your SAS servers using management scripts--instead of running them as Windows services--then the user account that runs the object spawner must meet the following requirements on the object spawner machine:

be the administrator or a member of the Windows Administrator's group
have the following Windows local user rights:
- Adjust memory quotas for a process
- Replace a process level token

Required External User Accounts for Third-Party Software

The following table describes the external user accounts required by third-party software and the machines on which they are authenticated--either as local accounts or in a network directory service that the machine can access.

Required External User Accounts for Third-Party Software
Description	Recommended User ID	Machine Where Authenticated
LSF Administrator-- Process owner for Platform LSF services and daemons. Required if you install Platform Suite for SAS to support scheduling or grid computing. Also owns the LSF configuration and log files and has permission to perform cluster-wide operations, edit configuration files, and reconfigure a cluster.	lsfadmin	Every Platform Process Manager and Platform LSF machine
LSF User-- Sometimes referred to as the scheduling user. Required by SAS Web Report Studio to run the Output Generation Tool, which creates scheduled reports in batch mode.	lsfuser	Platform Process Manager

As you create these external user accounts, record information about them in Pre-installation Checklist for External User Accounts for SAS on Windows and UNIX. You will need this information when you run the SAS Deployment Wizard (in Chapter 6).

Note: For information about the user rights that each account requires, see Rights Required by External User Accounts for Third-Party Software. [cautionend]

Rights Required by External User Accounts for Third-Party Software

The following table describes the user rights needed by the required external user accounts to deploy and run third-party software:

Rights Required by External User Accounts for Third-Party Software
External User Account	Operating System	User Rights Needed
LSF Administrator	Windows	Administrator rights Adjust memory quotas for a process Debug programs Log on as a service Replace a process level token
LSF User	Windows	Log on as a batch job or Log on locally

Local or Directory Service Accounts?

SAS relies on its various server machines to authenticate external user accounts. In turn, the SAS server machine authenticates user accounts using an authentication provider. An authentication provider refers to an authentication service that is one of the following:

local to a machine and used to authenticate local host user accounts
available to a machine through a computer network and used to authenticate directory service accounts such as LDAP or Active Directory

You can create either local or directory service accounts for external users. The only requirement is that each user shown in Required External User Accounts for SAS can be authenticated by the machine's authentication provider--be that an authentication provider that is local to the machine, or an authentication provider that is available to the machine through a directory service.

The main advantage of local accounts is that if account information were to get into the wrong hands, the credentials could be used only to log on to the machine or machines that can authenticate the credentials. A secondary benefit is that the host could continue to authenticate users even if the directory service authentication provider were unavailable.

The advantage of directory service accounts is that you do not have to create the same accounts on multiple machines or keep the account information synchronized across machines--the directory service authentication provider does this for you.

For example, setting up the SAS Spawned Server user account is usually straightforward. The spawned server account must be able to be authenticated by the pooled workspace server and stored process server machine. If these servers are distributed on more than one machine, then each machine must be a member of the same directory service or in different directory services between which a trust has been established.

Password Policies

Note: In this section, we are talking only about the passwords for the few external user accounts SAS requires, not the passwords for regular users of the system. [cautionend]

When you set up passwords for your SAS system users, we highly recommend that these passwords do not have to be reset when a user first logs on. If, for some reason, it is required that you create passwords that have to be reset, you will have to log on using each account and change the password before you install and configure your software. And, of course, you will need to know the changed password for each account.

By default, passwords for internal accounts are set not to expire. When passwords for system accounts change, you must update a set of configuration files and some metadata objects. SAS provides instructions for updating these files and metadata objects. However, you can save yourself some time if the passwords do not expire.

Pre-installation Checklist for External User Accounts for SAS on Windows and UNIX

Use the following pre-installation checklist to create the necessary external user accounts to deploy and run SAS on Windows and UNIX.

Note: These checklists are superseded by more complete and up-to-date checklists that can be found at http://support.sas.com/installcenter/plans. This Web site also contains a corresponding deployment plan and an architectural diagram. [cautionend]

Pre-installation Checklist for External User Accounts for SAS on Windows and UNIX
Account	Recommended User ID	Actual User ID
SAS Installer	Windows: my-domain\installer-ID¹ UNIX: sas^{2, 3}
SAS Spawned Servers account	Windows: my-domain\sassrv UNIX: sassrv²
1 On Windows, the user ID should be available in the long term for future SAS maintenance. 2 On AIX, make sure that the User can LOGIN? setting is set to true for the user. 3 On UNIX, do not use root.

Note these important items:

For information about the user rights that each external account requires, see Rights Required by External User Accounts for SAS.
The SAS Deployment Wizard prompts you for the Installer account and the SAS Spawned Servers account information, and you cannot complete the installation without supplying it.
On UNIX systems, the SAS Deployment Wizard requires that you supply the root password during configuration. Certain SAS products and features use functionality that requires SAS to check user ID authentication and file access authorizations. This in turn necessitates that certain files within your SAS installation have setuid permissions and be owned by root.
If your UNIX system uses an authentication method other than /etc/passwd or /etc/shadow, then you must configure authentication before you begin your SAS software deployment, or SAS 9.2 will not function properly. For more information, see the Configuration Guide for SAS 9.2 Foundation for UNIX Environments available at http://support.sas.com/installcenter.

Pre-installation Checklist for External User Accounts for Third-Party Software

Use the following pre-installation checklist to create the necessary external user accounts to deploy and run third-party software.

Note: The SAS Deployment Wizard prompts you for this information, and you cannot complete the installation without it. [cautionend]

Pre-installation Checklist for External User Accounts (Third-Party)
Account	Recommended User ID	Actual User ID
LSF Administrator	Windows: my-domain\lsfadmin UNIX: lsfadmin
LSF User	Windows: my-domain\lsfuser UNIX: lsfuser

Note: For information about the user rights that each account requires, see Rights Required by External User Accounts for Third-Party Software. [cautionend]

Pre-installation Checklist for External User Accounts for SAS on z/OS

Use the following pre-installation checklist to create the necessary external user accounts to deploy and run SAS on z/OS.

Note: The SAS Deployment Wizard prompts you for this information, and you cannot complete the installation without it. [cautionend]

Pre-installation Checklist for External User Accounts for SAS on z/OS
Account	Recommended User ID	Actual User ID
SAS Installer	sas
SAS Spawned Servers account	sassrv

Note:

For information about the user rights that each external account requires, see Rights Required by External User Accounts for SAS.
The SAS Installer and the SAS Spawned Servers account must have a TSO segment defined.
By default, the SAS Installer:
- is the started task owner for the servers.
- is the owner of the configuration directory structure.
- must have a writable home directory in the UNIX file system.
- must have an OMVS segment definition with the following minimum settings:
  - ASSIZEMAX of at least 2 GB
  - CPUTIMEMAX of at least 5000 seconds
  - PROCUSERMAX of at least 50 users

Top of Page