Authentication Tasks. SAS 9.2 Security Administration Guide

C H A P T E R

13

Authentication Tasks

How to Configure SAS Token Authentication

161

How to Configure SAS Internal Authentication

162

How to Change Internal Account Policies

163

Server-Level Policies

163

Per-Account Policies

165

How to Configure Web Authentication

166

Overview of Configuring Web Authentication

166

Vendor-Specific Instructions for Web Authentication

166

Logins for Users Who Participate in Web Authentication

166

How to Configure Direct LDAP Authentication

167

How to Configure Integrated Windows Authentication

169

How to Force Use of Kerberos

172

How to Store Passwords for the Workspace Server

173

How to Store Passwords for a Third-Party Server

174

How to Reduce Exposure of the SASTRUST Password

176

About the Workspace Server’s Options Tab

177

How to Configure SAS Token Authentication

For metadata-aware connections to the stored process server, the pooled workspace server, and the OLAP server, SAS token authentication is always used and no configuration is involved. See “SAS Token Authentication” on page 153.

To configure the standard workspace server to use SAS token authentication:

Note:

This is not a universally necessary task. Configuring the standard workspace server to use SAS token authentication is one of several solutions to a mixed provider situation. See “Mixed Providers” on page 135.

4

1

Log on to SAS Management Console as someone who has user administration capabilities (for example, sasadm@saspw).

2

On the Plug-ins tab, expand Server Manager and the application server

3

(for example, SASApp). Right-click the logical server

Logical Workspace Server

) and select Properties.

(for example, SASApp -

On the Options tab, select SAS token authentication. Click OK to save this setting.

4

5

Expand the logical server

Properties

.

, select the server , right-click, and select

On the Options tab, from the Launch Credentials drop-down list, select a login and click OK. The most basic choice is the SAS Spawned Servers account (the

161

162 How to Configure SAS Internal Authentication

4 Chapter 13

6 sassrv

login). If you want to use another account, see “Criteria for a Designated

Launch Credential” on page 184.

To make the changes take effect, refresh the spawner’s metadata.

a b c

Expand the object spawner

Connect

.

, right-click the computer , and select

Right-click the computer again and select Refresh Spawner. In the message box, click Yes.

Right-click the computer a third time and select Disconnect.

7

To validate the configuration, select the logical workspace server and select Validate.

, right-click,

Metadata layer access from the server (for example, library pre-assignment, PROC

OLAP code, and metadata LIBNAME engine use) will still be based on each requesting user’s identity. However, all host access from the server will now be under the designated launch credential. See “Example: Multiple Levels of Host Access” on page

190.

How to Configure SAS Internal Authentication

Note:

There are no server configuration activities for SAS internal authentication.

The metadata server always accepts valid internal account credentials. Internal accounts aren’t intended for regular users. See “SAS Internal Authentication” on page

150.

4

To create and use an internal account:

1

Log on to SAS Management Console as someone who has user administration capabilities (for example, sasadm@saspw).

2

3

4

On the Plug-ins tab, select User Manager. Make sure you are in the foundation repository.

Right-click User Manager and select New

I User. On the General tab, enter a short word such as test in the Name field.

On the Accounts tab, click Create Internal Account. In the New Internal

Account dialog box:

a b

Notice that the user ID is constructed from the name that you entered on the

General

tab and an @saspw suffix.

Enter and confirm a simple initial password such as 123456.

Note:

These instructions assume that the default server-level policies for internal accounts are in place.

4

5

6 c d

Select the Set a custom password expiration period check box and the

expires every

radio button. Leave the password expiration period at the default number of days.

Click OK to save the new internal account.

Notice that the new account appears at the bottom of the Accounts tab. Click OK to save the new user.

To log on to SAS Management Console as the new internal user:

a b

From the main menu, select File

I Connection Profile. In the informational message box, click Yes.

In the Connection Profile dialog box, select Create a new connection

profile

and click OK.

Authentication Tasks

4 Server-Level Policies

163 c d

In the Connection Profile wizard, name the profile internal, provide the machine name and port of the metadata server, and enter the internal credentials (for example, test@saspw and 123456). Click Finish.

In the Change Password dialog box, enter the original password again, enter and confirm a new password (such as 223456), and click OK.

7

Note:

You are forced to change the password because this is your first use of the account. This happens only for accounts that have a password expiration period (which you set in step 4c), and can also be affected by server-level policies.

4

f e

In the message box, click OK. In the connection profile, enter the new password and click Finish.

If necessary, provide your internal credentials once again to log on.

Notice that you have the permissions and capabilities of the SASUSERS and

PUBLIC groups (because you didn’t make any additional group or role assignments for the test user in step 4).

Note:

To clean up, log back on as someone who has user administration capabilities.

In User Manager, delete the user that you created for this exercise. To delete the test user’s home directory and MyFolder, select the Folders tab, navigate to SAS Folders

I

Users

, right-click the test folder, and select Delete.

4

See Also

“How to Unlock an Internal Account” on page 29

“How to Change Internal Account Policies” on page 163

“How to Create a Dual User” on page 29

How to Change Internal Account Policies

Server-Level Policies

Here are the initial server-level policies for internal accounts:

3

Accounts don’t expire and aren’t suspended due to inactivity.

3

3

Passwords must be at least six characters, don’t have to include numbers or mixed case, and don’t expire.

The five most recent passwords can’t be reused.

3

After three failed attempts to log on, an account is locked for one hour. An administrator can unlock the account by accessing the Accounts tab in the user’s definition in SAS Management Console.

3

A forced password change occurs on first use and after a password is reset. This policy applies only to accounts with passwords that periodically expire. By initial policy, passwords don’t expire, so forced password changes don’t occur.

To change these settings for all internal accounts (except those that have an overriding per-account setting), edit the metadata server’s omaconfig.xml file and restart that server. Here is the syntax:

Note:

The following option names are case-sensitive.

4

Note:

A value of T has aliases (1 or Y). A value of F has aliases (0 or N).

4

164 Server-Level Policies

4 Chapter 13

ChangeDelayInMinutes="number" specifies the number of minutes that must elapse between password changes.

Applies only when you are resetting your own password.

Range:

0–1440

Default:

0

DigitRequired="T | F" specifies whether passwords must include at least one digit. To enforce this requirement, specify T.

Default:

F

ExpirationDays="number" specifies the number of days after password is set that the password expires. A value of 0 prevents passwords from expiring.

Range:

0–32767

Default:

0

ExpirePasswordOnReset="T | F" specifies whether a forced password change occurs on first use and after an administrative password reset. To disable this requirement, specify F.

Default:

T

Exceptions:

This option affects only accounts with passwords that expire and doesn’t apply when you reset your own password.

MinLength="number-of-characters" specifies the minimum length for passwords.

Range:

1–32

Default:

6

MixedCase="T | F" specifies whether passwords must include at least one upper case letter and at least one lower case letter. To enforce this requirement, specify T.

Default:

F

NumPriorPasswords="number" specifies the number of passwords that are maintained in each account’s password history. A user can’t reuse a password that is in the user’s account history.

Range:

0–5

Default:

5

InactiveDaysToSuspension="number" specifies the number of days after which an unused account is suspended. A value of 0 prevents suspensions due to inactivity.

Range:

0–32767

Default:

0

LockoutDurationInMinutes="number" specifies the number of minutes for which an account is locked following excessive login failures.

Range:

1–2

31

Default:

60

NumFailuresForLockout="number" specifies the number of consecutive unsuccessful logon attempts that cause an account to be locked. We recommend that you do not specify 0, because doing so can make your system vulnerable to password guessing attacks.

Authentication Tasks

4 Per-Account Policies

165

Range:

0–100

Default:

3

Per-Account Policies

4

5

To override server-level policies on a per-account basis:

1

2

Log on to SAS Management Console as someone who has user administration capabilities.

On the Plug-ins tab, select User Manager (in the foundation repository).

3

In the display pane, clear the Show Groups and Show Roles check boxes.

Right-click the user definition of the user whose SAS internal account policies you want to change. Select Properties.

At the bottom of the user’s Accounts tab, click Update.

Make changes in the Custom Settings box. Not all server-level settings can be modified on a per-account basis.

Note:

There are two distinct expiration settings. Don’t confuse the account expiration date with the password expiration period.

4

Note:

To minimize administrative maintenance effort for any predefined or service identities that have internal accounts, don’t add expiration dates to these accounts or expiration periods to these passwords.

4

The following table maps server-level policies to corresponding account-level policies. Not all policies can be set at both levels.

Table 13.1

Internal Account Policy Mapping

Server-Level Policy

ExpirationDays

LockoutDurationinMinutes

NumFailuresForLockout

NumPriorPasswords

Related Account Level Setting

Set a custom password expiration period.

Exempt from account lockout policy.

Exempt from password reuse policy.

For example, if you want to force a particular user to change his or her internal password after you create (or reset) the user’s internal account, but you don’t otherwise want the password to expire, set per-account settings as depicted in the following display.

166 How to Configure Web Authentication

4 Chapter 13

By using the maximum password expiration period, 32767 days (approximately 89 years) you force a password change on first use but don’t require any further password updates in a plausible time frame.

See Also

“SAS Internal Authentication” on page 150

“How to Configure SAS Internal Authentication” on page 162

How to Configure Web Authentication

Overview of Configuring Web Authentication

Note:

Before you configure Web authentication, verify that this is an appropriate choice in your environment. See “Web Authentication” on page 156.

4

Configuring Web authentication consists of the following high-level tasks:

1

2

Make configuration changes to SAS components (for example, edit the SAS login.config file to reference the web domain, add security information to the SAS

Logon Manager application, and adjust the classpath for the Remote Services application).

Make configuration changes to your Web environment (for example, add login modules and make SAS JAR files available).

3

4

Rebuild and redeploy the SAS Web applications. Update and restart the Web application server.

Verify or adjust user information in the SAS metadata so that each user who participates in Web authentication has an appropriate login in his or her metadata definition.

Vendor-Specific Instructions for Web Authentication

Many of the implementation details for Web authentication differ by product. For this reason, instructions for setting up Web authentication in JBoss, WebSphere, and

WebLogic are available in separate documents from support.sas.com/

thirdpartysupport

.

Logins for Users Who Participate in Web Authentication

If you choose to configure Web authentication, make sure that user metadata definitions include logins as explained in this topic.

Someone who uses only Web applications should have a login in the web authentication domain. For example: web | joe | (no password)

Someone who uses both Web and desktop applications might need two logins. One login contains the user’s authenticated ID after logging on to a desktop application, and the other login contains the user’s authenticated ID after logging on to a Web application. For example:

Authentication Tasks

4 How to Configure Direct LDAP Authentication

167

DefaultAuth web

| WIN\joe

| joe

| (no password)

| (no password)

In the preceding example, two logins are needed because the format of the authenticated user ID differs in each context as follows:

3

When Joe logs on to a desktop application (as joe), SAS obtains his user ID in down-level format (WIN\joe), and that string is matched to the user ID in Joe’s

DefaultAuth login.

3

When Joe logs on to a Web application (as joe), SAS obtains his user ID in short format (joe), and that string is matched to the user ID in Joe’s web login.

However, if the authenticated user ID is identical in both contexts, the web login is not needed. If SAS obtains both authenticated user IDs as joe, the web login is not needed. In the following example, the metadata server is not authenticating against

Windows accounts and the web login is not needed. When Joe logs on to a Web application, the presence of his DefaultAuth login (which contains the correct user ID) is sufficient for the metadata server to successfully determine his metadata identity.

DefaultAuth web

| joe | (no password)

| joe | (no password)

Note:

If your Web environment uses Integrated Windows authentication, you must pay careful attention to the format in which SAS obtains user IDs from the Web realm.

If you find that users of Web applications have only the PUBLIC identity, it is likely that the user ID in each web login is not in the same format as the user ID that SAS obtains from the Web realm.

4

Note:

This isn’t a comprehensive discussion of logins; some users might have additional logins for other purposes.

4

See Also

“How Logins Are Used” on page 139

“Add Regular Users” on page 10

“Authentication to the Metadata Server” on page 126

“User ID Formats” on page 32

How to Configure Direct LDAP Authentication

Note:

This is not a universally necessary task. Before you use these instructions, make sure that this is an appropriate choice in your environment. See “Direct LDAP

Authentication” on page 146.

4

To make a metadata server on UNIX directly recognize Active Directory accounts, locate the sasv9_usermods.cfg file that is in your equivalent of SAS/Config/Lev1/

SASMeta/MetadataServer

and add lines such as these:

/* Environment variables that describe your AD server */

-set AD_HOST myhost

/* System options that make AD the primary authentication provider */

-authpd ADIR:company.com -primpd company.com

You can reference only one Active Directory server. You might choose to use a Windows domain name (for example, ADIR:MyWinDomain instead of ADIR:company.com).

The preceding settings cause these results:

168 How to Configure Direct LDAP Authentication

4 Chapter 13

Table 13.2

Example: User ID Formats if -authpd ADIR:company.com -primpd company.com

How a User Logs On Where the Metadata Server

Sends the Credentials

user-ID or user-ID@company.com

To Active Directory

WinDomain\user-ID

To Active Directory

user-ID@saspw

user-ID@host

user-ID@anything-else

To its internal provider

To its host

To its host

How the User ID Must Be Stored in SAS

Management Console

1

user-ID@company.com

WinDomain\user-ID or user-ID@WinDomain

No login for an internal account

user-ID user-ID@anything-else

1 If the ID isn’t stored in the correct format, the user can log on but has only the PUBLIC identity. Put the SAS copy of each user’s ID in a login on that user’s

Accounts

tab. Assign each login to DefaultAuth.

Or, to make a metadata server on UNIX or Windows directly recognize some other

LDAP provider, use lines such as these:

/* Environment variables that describe your LDAP server */

-set LDAP_HOST myhost

-set LDAP_BASE "ou=emp, o=us"

/* System options that make LDAP the primary authentication provider */

-authpd LDAP:company.com -primpd company.com

You can reference only one LDAP server.

The preceding settings cause these results:

Table 13.3

Example: User ID Formats if -authpd LDAP:company.com -primpd company.com

How a User Logs On Where the Metadata Server

Sends the Credentials

user-ID or user-ID@company.com

To LDAP

user-ID@saspw To its internal provider

user-ID@host To its host

user-ID@anything-else

To its host

How the User ID Must Be Stored in

SAS Management Console

1

user-ID@company.com

2

No login for an internal account

user-ID user-ID@anything-else

1 If the ID isn’t stored in the correct format, the user can log on but has only the PUBLIC identity. Put the SAS copy of each user’s ID in a login on that user’s

Accounts

tab. Assign each login to DefaultAuth.

2 When you use the LDAP version of -authpd, you must append the @primpd-value suffix in the SAS copy of each user ID that is authenticated by your LDAP provider.

To make the changes take effect, restart the metadata server. After you complete the configuration, verify that access to the workspace server isn’t compromised. If access fails, see “Mixed Providers” on page 135.

Table 13.4

Reference: Environment Variables

AD_HOST

AD_PORT

LDAP_HOST

LDAP_PORT

The host name of the machine where Active Directory is running.

The port number for Active Directory. The default is 389.

The host name of the machine where LDAP is running.

The port number for LDAP. The default is 389.

Authentication Tasks

4 How to Configure Integrated Windows Authentication

169

LDAP_BASE

LDAP_IDATTR

LDAP_PRIV_DN*

The base DN to use. For example: o=People, dc=orion, dc=com.

(Optional) an alternative LDAP attribute that the SAS server can use to find your DN. The default is uid.

The privileged DN that is allowed to search for users. For example, cn=useradmin.

LDAP_PRIV_PW* The password for LDAP_PRIV_DN. You can use the PWENCODE procedure to provide an encoded password.

* Set this variable only if users connect with a user ID instead of a DN, and the LDAP server does not allow anonymous binds.

Table 13.5

Reference: System Options

AUTHPD

PRIMPD

Use this option to register and name your Active Directory provider or other LDAP provider. For complete syntax, see the AUTHPROVIDERDOMAIN SAS system option.

Use this option to designate your Active Directory server or other LDAP provider as the primary authentication provider for the metadata server. The metadata server directly uses its primary provider when the submitted user ID has an @your-primpd suffix or no @ suffix at all. Using this option enables users to log on using their usual user IDs (no special suffix is required at log on time). For complete syntax, see the PRIMARYPROVIDERDOMAIN SAS system option.

Here are some additional details:

3

On UNIX, an alternate location for specifying the environment variables is in the

MetadataServer.sh shell script. For example:

AD_HOST=myhost export AD_HOST

3

3

On z/OS, a TKMVSENV file is used to make a list of pseudo environment variables available. A TKMVSENV PDS is created at installation. To define the environment variables, create a member in the PDS that specifies the necessary variables, and then reference this PDS member in the TKMVSENV DD statement in your started task.

Don’t move inbound logins (logins that provide access to the metadata server) out of the DefaultAuth authentication domain. Doing so can interfere with credential reuse. See “Credential Management” on page 144.

How to Configure Integrated Windows Authentication

Note:

This is not a universally necessary task. Before you use these instructions, verify that this is an appropriate choice in your environment. See “Integrated Windows

Authentication” on page 148.

4

Configuration of Integrated Windows authentication (IWA) can involve three distinct locations:

3

Client participation in IWA is determined by a setting in each connection profile.

If IWA isn’t selected by a client, it isn’t used for that client.

3

Server participation in IWA is affected by invocation commands. For example, the metadata server can’t use IWA if that server’s start command includes -nosspi.

170 How to Configure Integrated Windows Authentication

4 Chapter 13

3

For the workspace server, participation in IWA also requires certain settings in that server’s metadata definition.

To configure IWA:

1

In a Java desktop application such as SAS Management Console, edit your connection profile. In the Connection Information panel, select the Use

Integrated Windows authentication

check box. Click Advanced and verify that the advanced IWA settings in your profile are as depicted in the following display.

Click Finish and then click OK. If you are now logged on to SAS Management

Console, IWA to the metadata server is working. If the connection fails, verify that the metadata server’s startup command includes -sspi (this is the standard setting).

Note:

If you don’t have a well-formed user definition that includes your Windows account ID, the status bar in SAS Management Console indicates that you are a

PUBLIC-only user. In order to log back on as an administrator, you must edit your connection profile again or create a new profile.

4

2

If the workspace server is on Windows, complete these steps:

a b

Log on to SAS Management Console as someone who has user administration capabilities (for example, sasadm@saspw).

On the Plug-ins tab, expand Server Manager and the application server

c

(for example, SASApp). Right-click the logical server (for example,

SASApp - Logical Workspace Server

) and select Properties.

On the Options tab, define settings as follows:

i ii iii iv

Select the Host radio button. IWA is a form of host authentication.

Select the Negotiate security package.

Leave the Service principal name field empty. In a standard configuration, servers register a default SPN and clients know how to construct that value. Entering a value here or on the client side interferes with this default process.

If the workspace server doesn’t require access to network resources (such as UNC pathnames), leave the default value of Kerberos,NTLM in the security package list. Or, if you want to ensure that the workspace server can access network resources, force that server to use only Kerberos. See

“How to Force Use of Kerberos” on page 172.

Here is an example of IWA settings:

Authentication Tasks

4 How to Configure Integrated Windows Authentication

171

3

Note:

If a user accesses the workspace server seamlessly but the spawner log indicates that credential-based authentication occurred (instead of IWA), the user’s context includes credentials for the workspace server’s host. This can happen if the user didn’t use IWA to get to the metadata server or if the user’s DefaultAuth login includes a password. Even when IWA is properly configured, any available credentials are used.

4

Tell users that they can select the IWA check box when they log on to desktop applications such as SAS Information Map Studio, SAS Data Integration Studio,

SAS OLAP Cube Studio, SAS Management Console, and SAS Enterprise Guide.

In general, users shouldn’t make changes to the advanced settings that are depicted in step 1.

IWA requires agreement between client and server about which security protocol to use when exchanging authentication packets. The following table provides details:

172 How to Force Use of Kerberos

4 Chapter 13

Table 13.6

Integrated Windows Authentication Settings

Server

Setting

Negotiate security package

Associated Requirements

3 The client must select the Negotiate security package. To verify client-side settings, click

Advanced

in the connection profile.

3

3

3

The server must have a security package list. By default, servers have a security package list that offers the Kerberos and NTLM protocols.

At least one of the protocols in the server’s security package list must be offered by the client.

At least one of the protocols that are offered by both parties must actually be supported by both parties.

3

The Kerberos protocol can be used only if the client knows the server’s SPN, as explained in the following row.

Kerberos security package

NTLM security package

3

3

3

The client must select the Kerberos security package.

Both client and server must actually support the Kerberos protocol.

The client must know the server’s service principal name (SPN). In a standard configuration, this is transparent. SAS servers run as services under the Local System account and automatically register their SPN as

SAS/

machine-name:port. Clients can construct the default SPN (because they know the format, machine name, and port) so you don’t have to explicitly provide the SPN anywhere.

If you need to use a custom SPN:

1

In Windows, use the

setspn

command. For example: setspn -A sas/customValue myServer

This code registers

sas/customValue

as the SPN for all servers that run as services under the

Local System account on a machine that is named

myServer

. You must be a Windows domain administrator in order to use the

setspn

command.

2

Update all client-side connection profiles and the logical workspace server definition (if applicable) to include

sas/customValue

in the SPN field.

3

3

The client must select the NTLM security package.

Both client and server must actually support the NTLM protocol.

Note:

If your SAS servers use DNS aliases, you must manually register those aliases (as custom SPNs) in order to support Kerberos-based IWA connections.

4

How to Force Use of Kerberos

If you choose to use the SAS implementation of Integrated Windows authentication

(IWA), and you need to ensure that the Kerberos protocol is always used, complete the following instructions. These instructions assume that you have already completed the steps in “How to Configure Integrated Windows Authentication” on page 169.

Note:

You can’t use local accounts with this configuration, because local accounts can’t use Kerberos.

4

1

Specify -secpackagelist "Kerberos" in your equivalent of the following locations:

Authentication Tasks

4 How to Store Passwords for the Workspace Server

173

3

3

3

SAS\Config\Lev1\SASMeta\MetadataServer\sasv9_usermods.cfg

(for the metadata server)

SAS\Config\Lev1\SASApp\OLAPServer\sasv9_usermods.cfg

(if you need to support direct IWA connections to an OLAP server on Windows)

SAS\Config\Lev1\ObjectSpawner\ObjectSpawner.bat

(if the object spawner is on Windows). If the spawner runs as a service, complete these steps:

a b

From the Windows Start menu, select Programs

I SAS I SAS

Configuration

I <Level> I Object Spawner – Stop.

From the object spawner’s configuration directory, type:

ObjectSpawner.bat -remove

c d

Add the -secpackagelist "Kerberos" setting to the Set CMD_OPTIONS= line of ObjectSpawner.bat. Also, make sure that the -sspi setting is present.

To reinstall the spawner service, type:

ObjectSpawner.bat -install

2

If the workspace server is on Windows, make sure that its metadata definition includes only Kerberos in the Security package list field. This setting is located in SAS Management Console, on the Plug-ins tab under Server Manager.

The setting is on the Options tab of the logical workspace server definition.

Note:

If the workspace server accesses network resources (such as UNC pathnames), you must also mark the account under which the spawner runs as

trusted for delegation

. See “Windows Privileges” on page 36.

4

3

Restart the metadata server.

In general, it is not necessary to also change the default IWA setting in client-side connection profiles. If a server accepts only Kerberos, then clients with the default setting of Negotiate (and both Kerberos and NTLM in the security package list) use

Kerberos. However, in some circumstances, the client’s Windows system chooses to initiate communication using NTLM and is unable to comply with the server requirement by switching to Kerberos. For example, if the client and server are on the same machine, the client chooses NTLM. In these circumstances, you must adjust the client-side settings to specify only Kerberos.

Note:

In their 4.2 and earlier releases, SAS Enterprise Guide and the SAS Add-In for Microsoft Office don’t expose the advanced IWA settings.

4

Note:

If your SAS servers use DNS aliases, you must manually register those aliases in order to support Kerberos-based IWA connections. See the discussion of custom SPNs in Table 13.6 on page 172.

4

How to Store Passwords for the Workspace Server

Note:

This is not a universally necessary task. This is one of several solutions to a mixed provider situation. See “Mixed Providers” on page 135.

4

1

Log on to SAS Management Console as someone who has user administration capabilities (for example, sasadm@saspw).

2

On the Plug-ins tab, expand Server Manager, the application server example, SASApp) and the logical server

Workspace Server

).

(for

(for example, SASApp - Logical

174 How to Store Passwords for a Third-Party Server

4 Chapter 13

3

(Optional) Right-click the logical server, select Properties, and select the

Options tab. Make sure that the Authentication service is set to use Host with Username/Password. Click OK to close the dialog box and return to Server

Manager.

Below the logical server

Workspace Server

).

, select the server (for example, SASApp -

4

5

In the display panel, right-click the server’s connection object

Properties

.

and select

On the Options tab, notice the value in the Authentication domain drop-down list. If the value is something other than DefaultAuth, proceed to step 6.

Otherwise, complete these steps:

6 a b c

Next to the Authentication domain drop-down list, click New.

In the New Authentication Domain dialog box, enter a name such as

UNIXAuth

or WorkspaceAuth (you can use any name that is meaningful to you). Click OK.

On the Options tab, make sure the new authentication domain is selected in the Authentication domain drop-down list. Click OK.

Create a SAS copy of credentials that are known to the workspace server’s host operating system. In most cases, you will store shared credentials on a group’s

Accounts

. You can also store a unique set of individual credentials on each user’s

Accounts

tab. Each login must be assigned to the workspace server’s authentication domain. Each login must include both a user ID and a password.

For example, for a workspace server on UNIX:

UNIXAuth | myID | mypassword

For example, for a workspace server on Windows:

WINAuth | Win\myID | myWINpassword

If you store credentials for a workspace server that runs on Windows, give users the Log on as a batch job privilege. See “Windows Privileges” on page 36.

Note:

If you don’t store the passwords, users are prompted for such credentials when they make a request that requires access to the workspace server. Only desktop applications and SAS Web Report Studio provide such secondary logon prompts.

4

Note:

Do not instead leave the workspace server in DefaultAuth and move inbound logins to some other authentication domain. Failure to follow this recommendation won’t affect the initial logon process, but it will interfere with access to the workspace server. By default, all clients insert the credentials that a user submits at the logon prompt into that user’s context as a DefaultAuth entry. This cached DefaultAuth entry has priority over any DefaultAuth credentials that are retrieved from logins in the metadata.

4

See Also

“Credential Management” on page 144

“How Logins Are Used” on page 139

How to Store Passwords for a Third-Party Server

Note:

This is not a universally necessary task. Use these instructions to provide seamless access to a third-party server that uses a proprietary authentication provider

Authentication Tasks

4 How to Store Passwords for a Third-Party Server

175

(for example, Oracle). These instructions associate the database logins with a user or group, not directly with a database library.

4

1

Verify that the third-party server is registered in the metadata and is in its own authentication domain.

a

Select the third-party server’s definition under Server Manager on the

Plug-ins

tab in SAS Management Console.

2 b

In the display panel, right-click the server’s connection object and select

Properties

. The server’s authentication domain assignment is on the

Options

tab.

In the server’s authentication provider, identify or create accounts. Use any of the following approaches (here, Oracle is used as an example):

3

Create an individual Oracle account for each user. This provides the greatest accountability, but can also necessitate storing many Oracle user IDs and passwords in the metadata.

3

3

Create one Oracle account that all users will share. This greatly reduces the need to store Oracle user IDs and passwords, but also results in a loss of individual accountability.

Create a few Oracle accounts, each of which will be shared by several users.

This middle-of-the-road approach enables you to make some access distinctions in Oracle and store only a few Oracle user IDs and passwords in the metadata.

3

In the metadata, store the user IDs and passwords for each account as follows

(here, Oracle is used as an example):

3

If you created individual accounts on the Oracle server, add an Oracle login to each user definition.

3

If you created one shared account on the Oracle server, identify or create a group that contains the users who will access the Oracle server. Give that group a login that includes the user ID and password for the Oracle shared account.

Note:

If you want to provide access for all registered users, give the login to the SASUSERS group.

4

Note:

If you want to provide access for all users (including users who do not have an individual SAS identity), give the login to the PUBLIC group.

4

3

If you created several shared accounts on the Oracle server, identify or create a user group in the metadata for each shared account. Give each group a login for the Oracle server, and assign each user who connects to Oracle to one of the groups.

Assign these logins to the third-party server’s authentication domain. Store both an ID and a password in each login.

For example, for an Oracle server:

OracleAuth | myORAid | myORApassword

Note:

If you don’t store the passwords, users of desktop applications are prompted for such credentials when they make a request that requires access to the server.

SAS Web Report Studio has an interactive password management feature. Other

Web applications don’t support interactive logons to secondary servers.

4

See Also

“Credential Management” on page 144

“How Logins Are Used” on page 139

176 How to Reduce Exposure of the SASTRUST Password

4 Chapter 13

How to Reduce Exposure of the SASTRUST Password

Note:

This is not a universally necessary task. This is an optional configuration that can reduce the exposure of a privileged service account. Consider using these instructions if the standard protections (host protection of configuration files and encryption of the sastrust password in those files) is not sufficient for your environment.

On hosts other than Windows, these instructions might not provide a clear security benefit.

4

In the standard configuration, the OLAP server and the object spawner read the sastrust ID and password from their configuration files during initialization. These components use the sastrust credentials to connect to the metadata server and read the metadata that they use to perform their tasks. For example:

3

3

The spawner uses the SAS Trusted User identity to read metadata about the servers that it launches.

The OLAP server uses the SAS Trusted User to discover schemas and cubes and to impersonate each requesting user.

The primary reason to remove the sastrust credential from configuration files is to enhance security in a Windows environment. For sites that don’t use Integrated

Windows authentication, removing the sastrust credentials makes sense only if you prefer the exposure of using the trusted peer protocol to the exposure of storing the credentials in two host-protected files.

Note:

Another reason might be to avoid having to update the sastrust password in the configuration file. However, maintenance isn’t usually a concern because sastrust is usually an internal account with a password that doesn’t expire.

4

To remove the sastrust credentials from configuration files:

1

Locate the sasv9_meta.cfg file that is in your equivalent of SAS/Config/Lev1/.

Make a backup copy of the file. In the original file, delete your version of these lines:

-metauser "sastrust@saspw"

-metapass "{sas002}3CD4EA1E35CA49324AOC4D63"

2

Locate the file metadataConfig.xml file that is in your equivalent of SAS/Config/

Lev1/ObjectSpawner

. Make a backup copy of the file. In the original file, delete your version of this entry:

<Login Name="Metadata Login" UserId="sastrust@saspw"

Password="{sas002}3CD4EA1E35CA49324AOC4D63"/>

3

Determine which account (or accounts) are used for the connections and, on

Windows, what format you should use for the account ID in the following steps.

For example:

3

On UNIX, the spawner and the OLAP server run under a designated account that is identified during installation.

3

On Windows, if these components run under the local system account, use the format system@machine-name (if you are using trusted peer) or

machine-name$@Windows-domain (if you are using IWA). Otherwise, use the usual Windows qualified format (such as user-ID@Windows-domain).

4

To enable the spawner and the OLAP server to read the same metadata that sastrust reads, add a login such as this to the SAS Trusted User’s Accounts tab in SAS Management Console:

DefaultAuth | connecting-account-ID | (no password)

Authentication Tasks

4 About the Workspace Server’s Options Tab

177

If the components use different accounts, add one login for each account. For example:

DefaultAuth | myMachine$@myWinDomain | (no password)

DefaultAuth | invoker | (no password)

5

You can ignore any messages about multiple logins within an authentication domain.

To make the connecting accounts trusted users, add their account IDs to your equivalent of the SAS/Config/Lev1/SASMeta/MetadataServer/

trustedUsers.txt

file. Use the same format for the user ID that you used in step

3. For example, the updated contents might look like this: sastrust@saspw myMachine$@myWinDomain invoker

6

Note:

The OLAP server uses its trusted user status to impersonate clients for metadata access control evaluations. The spawner uses its trusted user status to determine which servers each requesting user is permitted to use.

4

Restart the metadata server. Verify that the spawner and the OLAP server can still contact the metadata server. In the metadata server log, you should see a separate connection from each component. The connections will be either IWA

(Integrated Windows authentication) or trusted peer.

Note:

In most configurations, IWA happens if the metadata server and the connecting component are on Windows and trusted peer happens on other hosts. If you expect IWA but instead see trusted peer, make sure the metadata server has

-sspi in its invocation command. If you expect trusted peer but the connection fails, make sure the metadata server has the trustsaspeer object server parameter specified.

4

See Also

“Integrated Windows Authentication” on page 148

“Trusted Peer Connections” on page 154

“Trusted User Connections” on page 155

“Passwords That Are Managed By the SAS Deployment Manager” on page 215

About the Workspace Server’s Options Tab

The following figure depicts the Options tab for a logical workspace server .

178 About the Workspace Server’s Options Tab

4 Chapter 13

Figure 13.1

The Options Tab for a Logical Workspace Server

This setting specifies standard access control enforcement for the ReadMetadata permission on server definitions.

This setting specifies that credentialbased host authentication is always used.

These settings specify that IWA is used for clients that select IWA

(unless credentials are available).

With this setting, you must also select a launch credential on the Options tab of the server .

This setting is similar to Host with Username/Password, but it prevents SAS Enterprise Guide and the SAS Add-In for

Microsoft Office from silently storing passwords in metadata (and forces those applications to prompt users).

Here are some additional details about this tab:

3

Because these settings are in the metadata, they can affect only metadata-aware connections.

3

The Host with Username/Password setting can cause SAS Enterprise Guide and the SAS Add-In for Microsoft Office to silently store user passwords in metadata.

The storage occurs only if the workspace server is in its own authentication domain (for example, ServerAuth) and users interactively provide credentials when they access that server. If both of these circumstances apply to your deployment, consider selecting Prompt instead of Host with Username/Password.

3

3

The Host with Username/Password setting doesn’t eliminate prompting for credentials. With this setting, all desktop applications prompt users to interactively supply credentials in any circumstance where credentials are needed and are not otherwise available.

The Prompt setting is the same as the Host with Username/Password setting, except that it has the following additional effects in SAS Enterprise Guide and the

SAS Add-In for Microsoft Office:

3

3 prevents silent storage of user passwords in metadata increases interactive prompts for user credentials, preventing single sign-on from those applications to the workspace server

3

3

3

If a workspace server is converted to client-side pooling, this tab is disabled and might not accurately depict settings that apply if the server is accessed as a standard workspace server. To avoid confusion, don’t use the same workspace server for both client-side pooling and standard use. Instead, if you choose to set up client-side pooling, use a dedicated workspace server (inside a separate application server).

Configuring a workspace server to use SAS token authentication can be useful in a multi-host environment. See “Mixed Providers” on page 135.

Don’t turn off enforcement of the requirement for ReadMetadata permission. This setting is provided only in case a site needs it for backwards compatibility.

Authentication Tasks

4 About the Workspace Server’s Options Tab

179

3

Choosing one of the Integrated Windows authentication (IWA) packages doesn’t guarantee that IWA will always be used and doesn’t turn off credential-based host authentication. For example:

3

Users who don’t choose IWA in their client-side connection profiles don’t use

IWA. The client-side profile setting affects whether the initial connection to the metadata server uses IWA. In a session in which that initial connection doesn’t use IWA, IWA can’t be used to launch a workspace server.

3

If a user’s stored login includes a password for the workspace server’s authentication domain, those credentials are added to the user’s context and credential-based host authentication occurs, even if IWA is chosen by both server and client.

Note:

This information is provided to assist in troubleshooting when you expect IWA to occur but it does not. In most cases, a user’s login doesn’t have to include a password. When you view a user’s logins (on the Accounts tab of his or her user definition), the password field always displays eight asterisks, regardless of whether a password is stored.

4

3

Changes that you make on this tab take effect after you refresh the object spawner.

See Also

“Integrated Windows Authentication” on page 148

“SAS Token Authentication” on page 153

180