Server Configuration, Data Retrieval, and Risk

Launch Credentials

	About Launch Credentials
	Criteria for a Designated Launch Credential
	How to Create and Designate a New Launch Credential
	Who Can Launch a Standard Workspace Server?

About Launch Credentials

Workspace servers and stored process servers use different process instances (SAS sessions) for different requests. Each process instance is launched by a spawner under a host account as follows:

For the stored process server, the pooled workspace server, and a standard workspace server that uses SAS token authentication, the spawner launches process instances under a designated service account. That account is called a launch credential (or, sometimes, a multi-user credential) and is specified as part of the server's metadata definition. For example, in the initial configuration, the SAS Spawned Servers account (sassrv) is the only designated launch credential.
For a standard workspace server that uses host authentication, the spawner launches a new process instance on-demand for each requesting user. The server's metadata definition doesn't include a designated launch credential. Instead, each requesting user's personal host account is used to launch that user's process instances. Or, if the server is accessed using group logins, a group account might be used. As a result, only users who can authenticate to the workspace server's host can get a workspace server.

The following figure depicts a deployment where the sassrv account is the launch credential for all servers that run under a designated account. The last server in the figure is shaded because it depicts a specialized configuration and can't coexist within an application server that includes another standard workspace server.

Example: Launch Credentials for Processing Servers

[Example: Launch Credentials for Processing Servers]

Note: If you use client-side pooling, the puddle login is comparable to the launch credential. [cautionend]

Criteria for a Designated Launch Credential

The Launch credentials (or Multiuser credentials) setting is available on the Options tab for a standard workspace server that uses SAS token authentication, the stored process server, and the pooled workspace server.

Choosing a Launch Credential

[Choosing a Launch Credential]

Note: In the preceding display, the values within parentheses indicate the authentication domain of the credential. These values aren't part of the service account ID. For example, the selected account ID is WIN\sassrv, not WIN\sassrv (DefaultAuth). [cautionend]

You should carefully select each server's launch credential for these reasons:

Not all of the choices are viable without additional configuration.
Each server retrieves SAS data from the operating system under the host identity of its designated launch credential. Anyone who can use a particular server can potentially access all of the data that is available to that server's launch credential.

The following list explains the choices in the launch credential list:

(None)

prevents proper functioning of the server. If the Multiuser credentials or Launch credentials drop-down list is present and enabled on the Options tab for a server [icon] , that server is not functional when (None) is selected.

Use spawner identity

can introduce the following complications:

On Windows, using the spawner's host identity as a launch credential causes launched processes to run with restricted access. For example, even if the spawner runs under the local system account, the host identity of the launched process isn't a member of Windows groups such as Administrators and Power Users. The downgrade is necessary in order to avoid security exposures. The downgrade can interfere with legitimate operation of the server.

Note: In the initial configuration, a spawner on Windows runs as a service under the local system account. You can reconfigure the spawner to run under some other account.
In the standard configuration, the spawner's SAS identity (PUBLIC) can't launch a pooled workspace server or a stored process server. As a PUBLIC-only identity, the spawner lacks the necessary grant of the ReadMetadata permission on the server definition.

Note: One solution is to create an individual SAS identity for the spawner account. For example, create a user definition named SPAWNER and store the user ID of the spawner account as a login on the Accounts tab of that user definition. In the initial configuration, all registered users (SASUSERS) have ReadMetadata permission for server definitions. If you narrow access, you might have to add a grant of ReadMetadata permission on the server's Authorization tab for the SPAWNER user.

Note: Ensure that the server's launch credential has any necessary host access to the SAS Web Report Studio query cache library (wrstemp) and distribution library (wrsdist). See the SAS Intelligence Platform: Web Application Administration Guide. [cautionend]

A listed login (for example, WIN\sassrv) or a login that you access by selecting More logins

is the standard choice. In order to successfully function as a launch credential, a login must meet all of the following criteria:

The login that must be visible to the spawner. All of the logins on the Accounts tab of the SAS General Servers group are visible to the spawner.

Note: The SAS Trusted User is a member of the SAS General Servers group. The spawner uses the SAS Trusted User to gather the metadata information needed to launch servers.
The login must include the user ID and password for an account that is known to server's host. It doesn't matter which authentication domain the login is in.

Note: If the server is on Windows, the user ID in the login must be in a qualified format (for example, WIN\serviceID).
The login must be owned by a SAS identity that has the ReadMetadata permission for the server definition. In the standard configuration, this requirement is met because the SAS General Servers group, like all other registered identities, has ReadMetadata permission for all server definitions. However, if you choose to limit ReadMetadata permission on a server definition, you must preserve access for the SAS General Servers group.
The login must reference an account that has host layer access to any SAS data that it retrieves.
If the server is on Windows, the login must reference an account that has the Log on as a batch job privilege.

Note: The login should reference a service account. This login shouldn't correspond to a real person. [cautionend]

Note: Ensure that the server's launch credential has any necessary host access to the SAS Web Report Studio query cache and distribution libraries. See the SAS Intelligence Platform: Web Application Administration Guide. [cautionend]

The preceding discussion assumes that your deployment uses the standard predefined metadata groups and users. You can choose to configure variations (for example, create a group other than the SAS General Servers group to hold logins for launch credentials). In general, such variations aren't recommended because they unnecessarily increase complexity and reduce consistency.

How to Create and Designate a New Launch Credential

Identify or create the host account.
- If the server will retrieve SAS data, make sure the host account has appropriate access to those files.
- If the server is on Windows, assign the Log on as a batch job privilege to the account. See Windows Privileges.
Log on to SAS Management Console as someone who has user administration capabilities (for example, sasadm@saspw). Other users can't add logins to a group definition or see logins that they don't own.
In User Manager, create a login on the Accounts tab of the SAS General Servers group. This login must include both a user ID and a password.

Note:   If the server is on Windows, the user ID in the login must be in a qualified format (for example, WIN\serviceID).

Note:   You can ignore any warnings about having multiple logins in the same authentication domain. These logins are directly associated with servers. These logins aren't looked up by authentication domain.

Note:   You can't reuse a login that already exists on the Accounts tab for some other user or group. The metadata server's integrity constraints prevent you from assigning the same user ID to two different SAS identities.

Note:   You can use the same login as a launch credential for more than one server.

Note:   Users should not be members of the SAS General Servers group. This group is for service identities only. Users don't retrieve these credentials, so users shouldn't have access to these logins. In a standard configuration, these logins are available only to the privileged service identity that the spawner uses to read all server metadata (the SAS Trusted User).
In Server Manager, on the server's Options tab, select the login as the server's launch credential (or multiuser credential).

Note: The launch credential is designated at the level of the server component , not at the level of the logical server .

Note: To locate a login that isn't displayed in the drop-down list, select the More logins entry. Although all logins are displayed in the secondary dialog box, any login that isn't visible to the SAS Trusted User isn't a viable choice.
To make the changes take effect, re-initialize the spawner.
1. Expand the object spawner , right-click the computer , and select Connect.
2. Right-click the computer again and select Refresh Spawner. In the message box, click Yes.
3. Right-click the computer a third time and select Disconnect.
Validate the server.

Who Can Launch a Standard Workspace Server?

In order to launch a standard workspace server that uses any form of host authentication, a user must have access to an individual or group account that meets all of the following criteria:

The account must be known to the workspace server's host. An internal account (such as sasadm@saspw) doesn't meet this requirement.
The account must have host layer access to any SAS data that it retrieves.
If the server is on Windows, and the user doesn't connect through Integrated Windows authentication, the account must have the Log on as a batch job privilege.
If the user supplies credentials interactively (for example, at a secondary logon prompt), the account must correspond to a SAS identity that has the ReadMetadata permission for the workspace server definition. In the initial configuration, all registered users meet this requirement, but a PUBLIC-only identity (someone who doesn't have a well-formed user definition) doesn't meet this requirement.

Note: If the Use Server Access Security check box on the Options tab of the logical server is cleared, this requirement doesn't apply.

	Identity Passing
	Host Access to SAS Tables
	Choices in Workspace Server Pooling