Each user must have an account that provides access to the metadata server, either directly or through a trust relationship. Determine which of the following situations applies to you and complete any tasks as indicated.

• In the simplest case, users already have accounts that are known to the metadata server's host, so no action on your part is required. For example, the metadata server is on UNIX, and users have accounts in an LDAP provider that the UNIX host recognizes. Or the metadata server is on Windows, and users have Active Directory accounts.

• In some cases, users have accounts that are not currently recognized by the metadata server's host. Consider the examples in the following table.

Table 12.1 Incorporating Unrelated Accounts

Scenario

You have Active Directory accounts but the metadata server is on UNIX.

Possible Solution

Enable the UNIX host to recognize the

accounts. See “Pluggable Authentication

Modules (PAM)” on page 142

You have accounts in an LDAP provider that is not known to the metadata server's host.

Enable the metadata server itself to recognize the LDAP provider. See

“Direct LDAP Authentication” on page

136 .

You have accounts that are known at your web perimeter but are not known to the metadata server's host.

Enable the metadata server to trust users who have authenticated at the web

perimeter. See “Web Authentication” on page 149 .

Note: This is only a partial solution, because users of desktop applications still need accounts that can be validated by the metadata server or its host.

• In other cases, you must add accounts to your environment. Although it is technically possible to instead use SAS internal accounts for this purpose, those accounts are not intended for regular users.

• Anyone who directly connects to the OLAP server (without first connecting to the metadata server) needs an account with the OLAP server.

Note: Regardless of the location of your user accounts, you must also create

corresponding user information in the SAS metadata. Without such information, users have only the generic PUBLIC identity in the SAS realm. By default, this identity has no access to metadata and cannot log on to most applications. See

“Authentication to the Metadata Server” on page 114 .

How to Configure SAS Token Authentication

157

Coordinate the Workspace Server

Seamless access to the workspace server depends on coordination between that server and the metadata server. By default, this coordination is necessary because authentication to the workspace server is performed by the workspace server's host. The following table provides general recommendations:

Table 12.2 Coordinate the Workspace Server with the Metadata Server

Scenario

The servers run on

Windows or UNIX.

The servers run on z/OS.

The servers do not recognize the same accounts.

Recommendation

Use host authentication (either credential-based or Integrated Windows authentication). See

“Host Authentication” on page 137

or “Integrated Windows Authentication” on page 139 .

Use credential-based host authentication for both servers.

To minimize requirements for and exposure of host credentials, SAS provides several alternate

configurations. See “Mixed Providers” on page 117 .

Note: Similar coordination is not necessary for OLAP servers and stored process

servers, because they use SAS token authentication (instead of host authentication) for metadata-aware connections.

How to Configure SAS Token Authentication

Note: 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. For the standard workspace server, configuring

SAS token authentication is one of several solutions to a mixed provider situation.

The tasks in this section might have been automatically configured by the SAS

Deployment Wizard during deployment. If you chose to configure SAS token authentication at that time, no further configuration steps are required. If, however, you decided to set up SAS token authentication after installation, this section documents the steps to follow.

To configure the standard workspace server to use SAS token authentication, complete these steps:

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 (for example, SASApp). Right-click the logical server (for example, SASApp -

Logical Workspace Server) and select Properties.

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

4. Expand the logical server , select the server , right-click, and select

Properties.

158

Chapter 12 • Authentication Tasks

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

(the

sassrv

6. To make the changes take effect, refresh the object spawner’s information about the server context. a. Connect to the object spawner server. Expand the object spawner , select the server , right-click, and select Connect. b. Refresh the object spawner server. Right-click the server, select Refresh

Spawner, and click Yes.

c. Disconnect from the object spawner server. Right-click the server and select

Disconnect.

7. To validate the configuration, select the logical workspace server , right-click, and select Validate.

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

PROC OLAP code, and metadata LIBNAME engine use) is still based on each requesting user's identity. However, all host access from the server is under the designated launch credential.

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 149 .

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

1. Make configuration changes to SAS web applications (for example, add security information to the SAS Logon Manager application).

2. Make configuration changes to the SAS Web Application Server (for example, configure a realm to authenticate users against an LDAP or other source).

3. Rebuild and redeploy the SAS web applications. Update and restart the web application server.

4. 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.

How to Configure Web Authentication

159

Step-By-Step Instructions for Web Authentication

For complete instructions for setting up web authentication, see

SAS Intelligence

Platform: Middle-Tier Administration Guide

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:

DefaultAuth | WIN\joe | (no password) web | joe | (no password)

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

• When Joe logs on to a desktop application (as joe), SAS obtains his user ID in downlevel format (WIN\joe), and that string is matched to the user ID in Joe's DefaultAuth login.

• 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 | joe | (no password) web | 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.

Note: This is not a comprehensive discussion of logins; some users might have

additional logins for other purposes.

How to Configure Direct LDAP Authentication

Before You Begin

Before you use these instructions, make sure that this is an appropriate choice in your

environment. See “Direct LDAP Authentication” on page 136 .

Active Directory

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 settings as follows:

/* 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

After you restart the metadata server, the preceding settings cause these results:

Table 12.3 Example: User ID Formats If -authpd ADIR:company.com -primpd company.com

How a User Logs On

user

user@company.com

Where the Metadata Server

Sends the Credentials

To Active Directory

How the User ID Must Be Stored in

Metadata

user@company.com

user@unrecognized-qualifier

WinDomain\user

user@saspw

user@host

To Active Directory

To its internal provider

To its host

user@unrecognized-qualifier

WinDomain\user or user@WinDomain

No login for an internal account

user

If the ID is not 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 in that user's metadata definition. Assign these logins to DefaultAuth.

Note: To optimize credential reuse, do not move inbound logins (logins that provide

access to the metadata server) out of the DefaultAuth authentication domain.

Note: If you use external accounts for the SAS Administrator (sasadm) or the SAS

Trusted User (sastrust), certain configuration files that include those user IDs must conform to the format requirements in the third column of the preceding table. Only configuration files that contain the user ID for the purpose of matching an authenticated user ID must conform (for example, the adminUsers.txt and trustedUsers.txt files).

The following table provides reference information for environment variables that are used with the Active Directory provider.

How to Configure Direct LDAP Authentication

161

Table 12.4 Environment Variables for Active Directory

AD_HOST

AD_PORT

AD_STYLE

AD_TIMEOUT

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

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

Specifies one of the following user ID formats as the only format to be used in authentication.

"OLD" the down-level format (domain\user)

"UPN" the user principal name format (user@UPNsuffix)

"USERNAME" the short format (user)

Consider setting the AD_STYLE environment variable if user accounts are being locked due to exceeding the permitted number of unsuccessful log on attempts. If AD_STYLE is not set, as many as three authentication attempts are made (each format is tried sequentially, until an attempt succeeds or all formats fail). See

“Windows User ID Formats” on page 21 .

Specifies the number of seconds before time-out on the first attempt to connect. Secondary attempts use the default time-out (30 seconds).

AD_TLSMODE Enables Transport Layer Security (TLS) encrypted communication between the metadata server and the Active Directory server. Set this variable to 1 to activate (for example,

-set

AD_TLSMODE 1

Additional configuration is required. See

“How to Configure TLS between the Metadata Server and an LDAP Server” on page 207 .

Other LDAP Providers

To make a metadata server on UNIX or Windows directly recognize some other LDAP provider, locate the sasv9_usermods.cfg file that is in your equivalent of

SAS/Config/

Lev1/SASMeta/MetadataServer

and add settings as follows:

/* 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

After you restart the metadata server, the preceding settings cause these results:

Table 12.5 Example: User ID Formats If -authpd LDAP:company.com -primpd company.com

How a User Logs On

user

user@company.com

user@unrecognized-qualifier

Where the Metadata Server

Sends the Credentials

To LDAP

How the User ID Must Be Stored in

Metadata

user@company.com

To LDAP

user@company.com

user@unrecognized-qualifier@company.com

162

Chapter 12 • Authentication Tasks

How a User Logs On

user@saspw

user@host

Where the Metadata Server

Sends the Credentials

To its internal provider

To its host

How the User ID Must Be Stored in

Metadata

No login for an internal account

user

Note: To optimize credential reuse, do not move inbound logins (logins that provide

access to the metadata server) out of the DefaultAuth authentication domain.

The following table provides reference information for environment variables that are used with other LDAP providers.

Table 12.6 Environment Variables for Other LDAP Providers

LDAP_HOST The host name of the machine where LDAP is running.

LDAP_PORT

LDAP_BASE

The port number for LDAP. The default is 389.

The base DN to use. For example:

o=People, dc=orion, dc=com

LDAP_BASE_SUFFIXES Makes a blank-delimited set of domains (LDAP groups) available as suffixes for the

LDAP_BASE and LDAP_IDATTR environment variables. See “Multiple LDAP Groups” on page 163 .

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

LDAP_PRIV_DN

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.

LDAP_TIMEOUT Specifies the number of seconds before time-out on the first attempt to connect. Secondary attempts use the default time-out (30 seconds).

LDAP_TLSMODE Enables Transport Layer Security (TLS) encrypted communication between the metadata server and the LDAP server. Set this variable to 1 to activate (for example,

-set

LDAP_TLSMODE 1

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

Additional configuration is required. See

“How to Configure TLS between the Metadata Server and an LDAP Server” on page 207 .

Advanced Configurations

Multiple LDAP Servers

SAS can recognize multiple LDAP servers as authentication providers, regardless of whether there are trust relationships among those servers.

How to Configure Direct LDAP Authentication

163

For example, to cause the metadata server to search three Active Directory servers

(AD1, AD2, and AD3) when authenticating users, set the AUTHPROVIDERDOMAIN system option as follows:

-authpd (ADIR:AD1, ADIR:AD2, ADIR:AD3)

To enable SAS to locate all three LDAP servers, supply information about each server through associated environment variables. To indicate which LDAP server each variable describes, append the server's name to the variable name. For example, with the preceding AUTHPD syntax, you might set server-specific variables as follows: set AD_HOST_AD1=machine1.company1.com

set AD_HOST_AD2=machine1.company2.com

set AD_HOST_AD3=machine1.company3.com

T I P

Notice that the suffix of each server-specific variable corresponds to a value that is already set in the AUTHPD system option.

Note: From the perspective of a SAS server, loss of contact with a particular LDAP

server is not distinguishable from other possible causes of authentication failure

(such as invalid credentials). For this reason, configuring multiple LDAP servers does not provide failover support across those LDAP servers.

Multiple LDAP Groups

SAS can customize identity search behavior for different LDAP groups within an LDAP server. For each LDAP group, you can set a starting point for search (the LDAP base

DN) and designate an attribute on which to search (as an alternative to the default, which is to search by uid).

To enable SAS to differentiate among multiple LDAP groups, you first set an environment variable (LDAP_BASE_SUFFIXES) that registers the LDAP group names.

For example, if your LDAP user store has an LDAP group for each of two organizations

(EUROPE and AMERICAS), and you want SAS to use a different search strategy for each of those organizations, you set an environment variable as follows:

LDAP_BASE_SUFFIXES=EUROPE AMERICAS

You can then set additional environment variables to establish a base DN and an identity search attribute for each group. To indicate which LDAP group each variable should affect, you append the group name to the variable name, as depicted in the following partial example:

LDAP_BASE_EUROPE=OU=Europe...

LDAP_IDATTR_EUROPE=CN

LDAP_BASE_AMERICAS=OU=Americas ...

LDAP_IDATTR_AMERICAS=samaccountname

T I P

Notice that the suffix of each group-specific variable corresponds to a value that is already registered in the LDAP_BASE_SUFFIXES environment variable.

Like LDAP server-specific values, LDAP group-specific values are inherited if they are not explicitly set.

Inherited Values for Environment Variables

If a variable is not set at the server-specific level, SAS obtains a value for that variable from the corresponding shared variable. The preceding example assumes that all three servers are on the default port of their respective machines (389), so no AD_PORT variable is explicitly set. However, if all three of the servers were instead on the same

(non-default) port on their respective machines, you would add a shared AD_PORT= variable as follows:

164

Chapter 12 • Authentication Tasks

set AD_PORT=123 set AD_HOST_AD1=machine1.company1.com

set AD_HOST_AD2=machine1.company2.com

set AD_HOST_AD3=machine1.company3.com

If the third server was on another port, you would also set a server-specific variable as follows: set AD_PORT=123 set AD_HOST_AD1=machine1.company1.com

set AD_HOST_AD2=machine1.company2.com

set AD_HOST_AD3=machine1.company3.com

set AD_PORT_AD3=456

With the preceding settings, the AD1 and AD2 servers use port 123 on their respective machines. Because no server-specific port value is set for AD1 and AD2, those servers inherit the value from the shared AD_PORT variable. The AD3 server uses an explicitly set server-specific port value (456).

This pattern of inheriting shared values if there are no more specific settings applies to all of the AD_ and LDAP_ environment variables, except that any server that is listed as an LDAP value in the AUTHPD option must have a corresponding server-specific

LDAP_BASE_SUFFIXES variable.

Compound Suffixes for Environment Variables

You might need to append two suffixes to an environment variable if both of the following circumstances exist:

• You want SAS to directly authenticate users against multiple LDAP servers.

• You want SAS to use different search behavior for different LDAP groups within at least one of those LDAP servers.

If you need to specify two suffixes, append the LDAP server suffix first and the LDAP group suffix last (for example, LDAP_BASE_LDAPserver1_LDAPgroup1=value).

For example, suppose you specify the AUTHENTICATIONPROVIDERDOMAIN system option and associated environment variables as follows:

-authpd (LDAP:SERVER1, LDAP:SERVER2)

LDAP_HOST=hostname

LDAP_BASE=CN=Users,DC=us,DC=company,DC=com

LDAP_IDATTR=CN

LDAP_PRIV_DN=CN=useradmin

LDAP_PRIV_PW=pwd

LDAP_BASE_SUFFIXES_SERVER2=GROUPA GROUPB

LDAP_BASE_SERVER2_GROUPA=CN=Groupa,DC=us,DC=company,DC=com

LDAP_IDATTR_SERVER2_GROUPA=CN

LDAP_BASE_SERVER2_GROUPB=OU=GroupB,DC=us,DC=comnpany,DC=com

LDAP_IDATTR_SERVER2_GROUPB=CN

The results are as follows:

• SERVER1 uses all of the shared values.

• SERVER1 searches the base DN that is set by the shared LDAP_BASE variable.

• SERVER2 uses shared values for the LDAP_HOST, LDAP_PRIV_DN, and

LDAP_PRIV_PW variables.

How to Configure Integrated Windows Authentication

165

• SERVER2 searches within the base DN that is set in the

LDAP_BASE_CARYNT_GROUPA. If the identity is not found within that area,

SERVER2 also searches within the baseDN that is set in the

LDAP_BASE_CARYNT_GROUPB variable.

About AUTHPD and PRIMPD

Table 12.7 Reference: SAS System Options

AUTHPD

PRIMPD

Use this option to register and name your Active Directory provider or other LDAP provider. See

“AUTHPROVIDERDOMAIN System Option” in SAS System Options: Reference .

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 no qualifier, the -primpd qualifier, or an unrecognized qualifier. Using this option enables users to log on using their usual user IDs (no special qualifier is required at logon time). See “PRIMARYPROVIDERDOMAIN= System Option” in SAS System Options: Reference .

About Setting Environment Variables

UNIX Specifics

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

z/OS Specifics

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.

For more information about setting environment variables, see the SAS system option

SET= in the documentation for your host:

•

SAS Companion for Windows

•

SAS Companion for UNIX Environments

•

SAS Companion for z/OS

How to Configure Integrated Windows

Authentication

Overview

Note: These instructions are for configuring Integrated Windows authentication (IWA)

from SAS desktop applications to the metadata server and the workspace server.

Before you configure IWA, verify that this is an appropriate choice in your environment. See

“Integrated Windows Authentication” on page 139

166

Chapter 12 • Authentication Tasks

Configuration of IWA for desktop applications can involve three distinct locations:

• Client participation in IWA is determined by a setting in each client-side connection profile. If IWA is not selected by a client, IWA is not used for that client.

• Server participation in IWA is affected by invocation commands. For example, to use

IWA, the metadata server and object spawner start commands must include the option

-sspi

Note: This is the default on Windows and UNIX

• For metadata-aware connections to a workspace server, participation in IWA is also affected by settings in that server's metadata definition.

Instructions

1. If the metadata server or workspace server runs on UNIX, complete the UNIX prerequisite tasks. Before you can use IWA for a SAS server that runs on a UNIX host, you must prepare and configure the UNIX environment. For example:

• You must acquire, install, and configure the required software. For the first maintenance release for SAS 9.4, the only supported implementation of IWA on

UNIX requires Quest Authentication Services (QAS) 4.0.1.23 or later. For the second maintenance release for SAS 9.4 on Linux systems and the fourth maintenance release for SAS 9.4 on Solaris systems, any shared library

(including QAS) that implements the GSSAPI with Kerberos 5 extensions can be used. If QAS is present on the host, SAS attempts to load its libraries before attempting to load others to retain legacy behavior.

Note: In a single deployment, do not use Quest with other shared libraries.

• You must create a service account and corresponding keytab file. Participating

SAS processes on UNIX must be able to read the keytab file. A keytab file is functionally equivalent to a user's password and should be secured in the same way. The keytab file should be owned by the user and group that is accessing it, and it should have the least permissive access mask (preferably 0600).

• You must set certain environment variables.

These prerequisite tasks should be performed during the installation and initial configuration phases of your deployment. Some of the implementation details differ by UNIX host. For these reasons, detailed instructions for preparing your UNIX host to support IWA are in a separate document. See the chapter "Configuring Integrated

Windows Authentication" in Configuration Guide for SAS Foundation for UNIX

Environments at

http://support.sas.com/documentation/installcenter .

2. If the metadata server is clustered and runs on Windows, or if your SAS servers are configured using DNS aliases, manually register SPNs. See

“Manual Registration” on page 169

3. Verify an IWA connection to the metadata server.

a. In a client-side connection profile, select the check box that enables Integrated

Windows authentication and then attempt to connect.

T I P

For example, in the Connection Profile dialog box in SAS Management

Console, click Edit. On the Connection Information page of the Edit

Connection Profile wizard, select the Use Integrated Windows

authentication (single sign-on) check box.

b. If the connection fails, verify the following:

How to Configure Integrated Windows Authentication

167

• The metadata server's start-up command includes

-sspi

• The advanced IWA settings in your client-side connection profile are

Negotiate for the security package, blank (no value) for the service principal name, and Kerberos,NTLM for the security package list.

• Your metadata user definition includes a login that contains your user ID in

the correct format. See “User Logins” on page 168

• You are using a Windows desktop client (the SAS implementation of IWA is not for web applications or UNIX clients).

• If the metadata server runs on UNIX, the prerequisite steps have been successfully completed. (See step 1 above.) c. After the connection succeeds, examine the metadata server log to confirm that an IWA connection was used. If a credential-based connection occurred, make sure that your password is not cached in the client application.

T I P

In SAS Management Console, you can clear the credentials cache by selecting File

Clear Credentials Cache from the main menu.

4. Configure the workspace server’s metadata definition for IWA, and verify an IWA connection to that server.

T I P

If you use IWA for the metadata server, there are no cached credentials from an initial logon. For this reason, it is a good idea to configure IWA for the standard workspace server also, if possible (IWA is not supported on z/OS).

a. On the Plug-ins tab in SAS Management Console, expand Server Manager and the application server (for example, SASApp). Right-click the logical server

(for example, SASApp - Logical Workspace Server) and select Properties.

b. On the Options tab, select the Host radio button (IWA is a form of host authentication).

• Select the Negotiate security package.

• Leave the Security package list as Kerberos,NTLM.

• Leave the Service principal name blank. In a standard configuration, clients expect (and know how to compose) the default SPN. Entering a value here

(or on the client side) overrides this default process.

c. Log on to SAS Management Console using IWA. Right-click the Logical

Workspace Server and select Validate.

d. If the connection fails, verify the following:

• The object spawner's start-up command includes

-sspi

• Your metadata user definition includes a login that contains your user ID in

the correct format. See “User Logins” on page 168

• If the workspace server runs on UNIX, the prerequisite steps have been successfully completed. (See step 1 above.) e. After the connection succeeds, examine the object spawner log to verify that the connection to the workspace server was made using IWA. If the spawner log indicates that credential-based authentication occurred (instead of IWA), the user's context includes credentials for the workspace server's host. Make sure that the user does not have a cached or stored password for the workspace server’s authentication domain.

Note: Even if IWA is configured, any available cached or stored credentials are

preferentially used.

168

Chapter 12 • Authentication Tasks

5. If the workspace server needs to access Kerberized network resources (such as network file systems or IWA connections to databases):

• Edit the Security package list so that only Kerberos is specified.

• In Active Directory, make the object spawner account trusted for delegation to all services. See

“Windows Privileges” on page 19

6. Inform users that they can select the IWA option 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 should not make changes to the advanced IWA settings in their clientside connection profiles.

User Logins

If you choose to configure IWA, make sure that user metadata definitions include logins with properly formatted user IDs. The format of the stored user IDs must match the format in which authenticated user IDs are returned to the target server. Failure to meet this requirement causes the user to have only the generic PUBLIC identity (which, by default, cannot even log on to most applications).

In the standard configuration, the appropriate format varies as follows:

• If the target server is on Windows, the authenticated user ID is returned in qualified format, so the stored user ID should be qualified (for example, WIN\joe or

[email protected]).

• If the target server is on UNIX, the authenticated user ID is returned in short format

(it is not qualified), so the stored user ID should not be qualified (for example, joe or

fred.smith).

If you need to align formats, use the SASUSEKERBNAME environment variable. For example, you might use this environment variable in either of the following circumstances:

• The metadata server is on Windows, the workspace server is on UNIX, both are using IWA, and you do not want to store two logins for each user.

• You need to distinguish between two different users, in two different Kerberos realms, who happen to have the same sAMAccountName name (for example, [email protected] and [email protected]).

See

“Windows User ID Formats” on page 21

How to Configure Integrated Windows Authentication

169

Registering SPNs

Automatic Registration

In a standard configuration on Windows, you do not manually register service principal names (SPNs). Instead, each participating SAS server uses the local system account under which it runs to self-register two SPNs against the computer object of the machine where it runs. These Active Directory registrations are in the format SAS/fully-qualified-

machine-name and SAS/netbios-machine-name (for example,

SAS/machineA.company.com and SAS/machineA).

In a standard configuration on Windows, clients can construct a standard SPN (because they know the format and the target machine), so users do not have to supply an SPN when they initiate an IWA connection.

Manual Registration

In circumstances such as the following, manual registration of SPNs is necessary in order to support Kerberos connections:

• Your metadata server is clustered and runs on Windows. See

“IWA to a Clustered

Metadata Server” on page 173

• Your SAS servers use DNS aliases, so the SPNs must reference an alias instead of a machine name. See

“IWA to Servers That Use DNS Aliases” on page 174 .

• You are using IWA for servers on UNIX systems.

CAUTION:

SPNs must be unique among the objects that are in the same Active Directory forest.

A given SPN must not be assigned to more than one object. If a duplicate

SPN is found in response to a TGS request, the Key Distribution Center sends an error to the client that the principal was not found.

To manually register an SPN, use the Microsoft tool setspn . For example, the following command registers

customValue

as the SPN for all servers that run as services under the local system account on a machine that is named myServer: setspn -A customValue myServer

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

setspn

command.

Note: You must also make any necessary adjustments to client-side connection profiles

(and the logical workspace server definition, if applicable). For example, if you supplied a custom value for the SPN, specify the new customValue in the Service

principal name fields.

UNIX Specifics

On UNIX, the SPNs that are used must be listed in the keytab file. In addition to running

setspn

to set a custom SPN, and making sure that client connection profiles use that custom SPN, you must generate a new keytab file that includes the new SPN. See the chapter "Configuring Integrated Windows Authentication" in

Configuration Guide for SAS Foundation for UNIX Environments.

Manually Registering Object Spawner SPNs

Note: The following manual registration is required only on Windows systems. It does

not have to be completed on UNIX systems.

170

Chapter 12 • Authentication Tasks

By default, the SAS Object Spawner service runs as a local system. The best practice is to set this service to run under a service level account. Although the account must be an administrator, it allows system administrators to allow delegation to a single account rather than the whole computer if, delegation must be set to allow access to third-party resources (such as SQL and network shares).

When using a service level account to run the object spawner service in a SAS Grid environment, you need to configure the default SPNs: setspn –A SAS/computerNetbios –u domain\ObjectSpawnerServiceAccount setspn –A SAS/computerFullname –u domain\ObjectSpawnerServiceAccount

In non-grid environments, you can configure custom SPNs, such as the following: setspn –A SASWS/computerNetbios –u domain\ObjectSpawnerServiceAccount setspn –A SASWS/computerShortname –u domain\ObjectSpawnerServiceAccount

Note: The preceding SPN statements differ from the one that is built if you use the local

system.

Manually Registering SQL SPNs

When registering a SQL Server database to use IWA, additional configuration steps are needed. The following scenarios provide information about possible configurations.

In the first scenario, the SQL Server service runs under a service account and SQL

Server service is not on the same machine as the object spawner service. For this scenario, follow these steps:

1. To register custom SPNs for the service, run the following commands: setspn –A MSSQLSVC/computerNetboisName: sqlPort –u domain\sqlServiceAccount setspn –A MSSQLSVC/fullyQualifiedDomainName: port –u domain\sqlServiceAccount setspn –A MSSQLSVC/machineName: sqlInstance –u domain\sqlServiceAccount

Create the SPNs for each DNS alias, if any are being used.

2. Run the

setspn –x

command to verify that no duplicate SPNs exist.

3. Verify that the SQL Server is accepting Kerberos connections. Run the following command from the SQL Management Studio on the computer where the object spawner service runs:

SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid;

If the query does not return KERBEROS, the SPNs might not be created correctly, or there might be other issues, such as port 88 (the Kerberos ticketing service) is blocked.

4. Create an ODBC connection on the same machine where the spawner resides, by completing the following steps: a. From the Windows Start menu, select Control Panel

Administrative Tools

Data Sources (ODBC). The ODBC Data Source Administrator dialog box is displayed.

b. Select the System DSN tab and click Add.

c. Use the Create New Data Source wizard to configure the connection.

In the second scenario, the SQL Server service runs under a service account and is on the same machine as the object spawner service. In this scenario, since both services reside

How to Configure Integrated Windows Authentication

171

on the same machine, no delegation is required for the object spawner to access the SQL

Service.

Note: You need to configure delegation if the object spawner needs to delegate

credentials across the network, for example, to access a network share.

In the third scenario, the SQL Server service runs under a local system account and is on the same machine as the object spawner service. This configuration is not a best practice and is therefore not supported by Microsoft. If a custom SPN for the SQL Server service account is required or preferred, the Microsoft SQL Server 2012 Native Client needs to be installed and configured.

Forcing 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, follow these instructions. These instructions assume that you have already fully configured IWA.

Note: You cannot use Windows local accounts with this configuration, because those

accounts cannot use Kerberos.

1. Specify

-secpackagelist "Kerberos"

in your equivalent of the following locations:

•

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:

1. From the Windows Start menu, select Programs

SAS

Configuration

<Level>

Object Spawner – Stop.

2. From the object spawner's configuration directory, enter the following:

ObjectSpawner.bat -remove

3. Add the

-secpackagelist "Kerberos"

setting to the

Set

CMD_OPTIONS=

line of ObjectSpawner.bat. Also, make sure that the

-sspi

setting is present.

4. To reinstall the spawner service, enter the following:

ObjectSpawner.bat -install

2. Restart the metadata server.

3. Make sure that the workspace server’s 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: On Windows systems, if the workspace server accesses network resources

(such as network filesystems or IWA connections to databases), you must also mark the account under which the spawner runs as

trusted for delegation to all services

. See

“Windows Privileges” on page 19

Note: On UNIX systems, the account that the SAS SPN is registered against must be

trusted for delegation in Active Directory.

4. Restart the object spawner.

172

Chapter 12 • Authentication Tasks

T I P

In general, it is not necessary to also change the default IWA setting in clientside 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.

UNIX Specifics

It is not necessary to force use of Kerberos on UNIX, because IWA on UNIX supports only the Kerberos protocol.

Supported Protocols

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

Table 12.8 Integrated Windows Authentication Settings

Server

Setting Associated Requirements

Negotiate security package

• The client must select the Negotiate security package.

• 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.

The NTLM protocol is not supported on UNIX.

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

Kerberos security package

• 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. Clients expect (and know how to construct) a default SPN in the format

SAS/

machine (for example, SAS/machineA.na.company.com), so you do not have to explicitly provide the SPN.

Note: For a server on UNIX, the machine value must be specified as a fully qualified domain name

(FQDN). For a server on Windows, you can instead specify the machine’s NetBIOS name, but the

FQDN is preferred (because a NetBIOS name is not guaranteed to be unique).

NTLM security package

• The client must select the NTLM security package.

• Both client and server must actually support the NTLM protocol. The NTLM protocol is not supported on UNIX.

IWA to an OLAP Server

In the standard configuration, the OLAP server supports IWA for direct connections (for example, from an open OLAP client that uses an OLE DB Provider for OLAP). This support is similar to the metadata server’s support of IWA for direct connections from

How to Configure Integrated Windows Authentication

173

SAS desktop clients. In both cases, client-side connection information must request that

IWA is used.

Note: In the platform, most connections to the OLAP server are metadata-aware, not

direct (the client first connects to the metadata server and then connects to the OLAP server, rather than initially connecting to the OLAP server). Metadata-aware connections to the OLAP server use SAS token authentication (they do not use

IWA).

IWA to a Clustered Metadata Server

Introduction

A clustered metadata server on Windows runs under a domain account. No local system account is available to perform the usual self-registration of SPNs. Instead, you must manually register SPNs for all of the host machines in the cluster.

Example

For a metadata server that runs as [email protected] on three dedicated machines

(machineA, machineB, and machineC), you might register the following SPNs:

• SAS/machineA.company.com

• SAS/machineA

• SAS/machineB.company.com

• SAS/machineB

• SAS/machineC.company.com

• SAS/machineC

In this example, the SPNs are registered against the Active Directory principal that

corresponds to the [email protected] account. See “Manual Registration” on page

169 .

Shared Hardware

If other SAS servers that run as services share any of the clustered metadata server’s hardware, Active Directory conflicts can occur, because one SPN cannot be associated with two Active Directory identities.

You can work around such conflicts by using either of the following methods:

• Reconfigure the other servers to run under the metadata server’s domain account

(instead of running under the local system account).

Note: If you make this adjustment to the object spawner, the domain account must

be a Windows administrator on the spawner's host and must have the Windows user rights Adjust memory quotas for a process and Replace a process level

token. These user rights assignments are part of the local security policy for the

Windows computer that hosts the spawner.

• Adjust the configuration to reference the domain account’s user principal name

(UPN). For example, if the metadata server runs as [email protected], and the

UPN that is registered in Active Directory for that account is [email protected], then users should enter the value [email protected] in the Service principal name (SPN) field of the IWA Advanced Settings dialog box in their client-side connection profiles.

174

Chapter 12 • Authentication Tasks

IWA to Servers That Use DNS Aliases

To support Kerberos connections to a server that uses a DNS alias, manually register

SPNs that reference the alias (instead of referencing the machine name).

For example, for a metadata server on Windows that runs under the local system account and uses the alias DNSalias, you might register the following custom SPNs.

• SAS/DNSalias

• SAS/DNSalias.company.com

In this example, the SPNs are registered against the Active Directory computer object

that corresponds to the machine on which the metadata server runs. See “Manual

Registration” on page 169 .

About IWA from SAS Web Applications

The SAS implementation of IWA is for desktop applications only. Web applications can use IWA if they are configured for web authentication and the web application server supports IWA. See SAS Intelligence Platform: Middle-Tier Administration Guide.

How to Store Passwords for the Workspace

Server

Note: This is one of several solutions to a mixed provider situation (and it is not a

preferred approach). See

“Mixed Providers” on page 117 .

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 (for example, SASApp) and the logical server (for example, SASApp - Logical

Workspace Server).

(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.

3. Below the logical server , select the server (for example, SASApp -

Workspace Server).

4. In the display panel, right-click the server's connection object and select

Properties.

Note: If you do not 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.

Note: Do not instead leave the workspace server in DefaultAuth and move inbound

logins to some other authentication domain. Failure to follow this recommendation does not affect the initial logon process, but it does 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.

•

“Credential Management” on page 134

•

“How Logins Are Used” on page 121

•

“Windows Privileges” on page 19

How to Store Passwords for a Third-Party Server

Note: Use these instructions to provide seamless access to a third-party server that uses

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

176

Chapter 12 • Authentication Tasks

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.

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.

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

• 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.

• Create one Oracle account that all users 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 is 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):

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

• If you created one shared account on the Oracle server, identify or create a group that contains the users who 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.

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.

• 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.

Here is an example for an Oracle server:

OracleAuth | myORAid | myORApassword

Note: If you do not 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 do not support interactive logons to secondary servers.

How to Change Internal Account Policies

Server-Level Policies

Initial Settings

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

• Accounts do not expire and are not suspended due to inactivity.

• Passwords must be at least six characters, do not have to include numbers or mixed case, and do not expire.

• The five most recent passwords cannot be reused.

• 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.

• 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 do not expire, so forced password changes do not occur.

Current Settings

You can examine the current policies in SAS Management Console. On the Plug-ins tab, expand the Metadata Manager, right-click the Active Server node, and select

Properties. The Options tab displays any server-level internal account policies that have been explicitly set.

Note: You can also examine explicitly set policies by viewing the omaconfig.xml file.

Syntax for the InternalAuthenticationPolicy Element

To change the server-level policies, edit the

InternalAuthenticationPolicy

element in the metadata server's omaconfig.xml file, and then restart that server.

Here is the syntax for each policy option:

Note: The following option names are case-sensitive.

Note: A value of

has aliases (

). A value of

has aliases (

ChangeDelayInMinutes=

"number" specifies the number of minutes that must elapse between password changes. Applies only when you are resetting your own password.

DigitRequired="T | F"

specifies whether passwords must include at least one digit. To enforce this requirement, specify

ExpirationDays=

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

ExpirePasswordOnReset="T | F"

specifies whether a forced password change occurs on first use and after an administrative password reset. To disable this requirement, specify

178

Chapter 12 • Authentication Tasks

HashPasswords="SHA256 | MD5"

specifies how the internal account password is stored in the metadata.

SHA256 the SHA-256 hash function is used. SHA (secure hash algorithm) is

FIPS (Federal Information Processing Standard) compliant.

SHA-256 hashing is provided by SAS/SECURE. This is the default.

MD5 MD5 hashing is used. MD5 (message digest algorithm 5) is appropriate for preventing accidental exposure of information.

MinLength=

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

MixedCase="T | F"

specifies whether passwords must include at least one uppercase letter and at least one lowercase letter. To enforce this requirement, specify

NumPriorPasswords=

"number" specifies the number of passwords that are maintained in each account's password history. A user cannot reuse a password that is in the user's account history.

InactiveDaysToSuspension=

"number" specifies the number of days after which an unused account is suspended. A value of

0 prevents suspensions due to inactivity.

Note: Beginning in the fourth maintenance release for SAS 9.4, this option is no

longer supported.

LockoutDurationInMinutes=

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

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.

Example of the InternalAuthenticationPolicy Element

...

<InternalAuthenticationPolicy ChangeDelayInMinutes="0" DigitRequired="F"

ExpirationDays="0" MinLength="6" MixedCase="F" NumPriorPasswords="5"

InactiveDaysToSuspension="0" LockoutDurationInMinutes="60"

NumFailuresForLockout="3"/>

...

</OMAconfig>

Per-Account Policies

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

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

2. On the Plug-ins tab, select User Manager.

3. In the display pane, clear the Show Groups and Show Roles check boxes. Rightclick the user definition of the user whose SAS internal account policies you want to change. Select Properties.

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

About the Workspace Server's Options Tab

179

5. 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. Do not confuse the account

expiration date with the password expiration period.

Note: To minimize administrative maintenance effort for any predefined or service

identities that have internal accounts, do not add expiration dates to these accounts or expiration periods to these passwords.

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

Table 12.9 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.

T I P

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 do not otherwise want the password to expire, use the maximum custom password expiration period (32,767 days).

About the Workspace Server's Options Tab

The following tips help you interpret the Options tab for a logical workspace server in SAS Management Console.

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

• Because the displayed settings are in the metadata, they can affect only metadataaware connections.

• The Use Server Access Security check box should be selected. This enables standard access control enforcement for the ReadMetadata permission on the server definitions.

Note: An exception is if the workspace server is configured for client-side pooling.

In that case, the check box is disabled and cleared. Server access security is not supported with client-side pooling.

• The Host with Username/Password setting specifies that credential-based host authentication is always used. The other security packages cause IWA to be used for clients that select the IWA option (unless cached or stored credentials are available).

180

Chapter 12 • Authentication Tasks

• The Host with Username/Password setting does not 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.

• If you select SAS token authentication, you must also select a server launch credential (on the Options tab of the server definition). Configuring a workspace server to use SAS token authentication can be useful in a multi-host environment.

See “Mixed Providers” on page 117 .

• 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.

• The Prompt setting is similar to Host with Username/Password, but it forces SAS

Enterprise Guide and the SAS Add-In for Microsoft Office to prompt users.

Part 4 Encryption

Chapter 13

Encryption Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

Chapter 14

Encryption Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

197

182

Reklama

Chapter 12

Authentication Tasks

How to Facilitate Authentication

Identify or Create User Accounts

Note: Regardless of the location of your user accounts, you must also create

Coordinate the Workspace Server

Note: Similar coordination is not necessary for OLAP servers and stored process

How to Configure SAS Token Authentication

Note: For metadata-aware connections to the stored process server, the pooled

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

See Also

How to Configure Web Authentication

Overview of Configuring Web Authentication

Note: Before you configure web authentication, verify that this is an appropriate choice

Step-By-Step Instructions for Web Authentication

Logins for Users Who Participate in Web Authentication

Note: If your web environment uses Integrated Windows authentication, you must pay

Note: This is not a comprehensive discussion of logins; some users might have

See Also

How to Configure Direct LDAP Authentication

Before You Begin

Active Directory

Note: To optimize credential reuse, do not move inbound logins (logins that provide

Note: If you use external accounts for the SAS Administrator (sasadm) or the SAS

Other LDAP Providers

Note: To optimize credential reuse, do not move inbound logins (logins that provide

Advanced Configurations

Multiple LDAP Servers

Note: From the perspective of a SAS server, loss of contact with a particular LDAP

Multiple LDAP Groups

Inherited Values for Environment Variables

Compound Suffixes for Environment Variables

About AUTHPD and PRIMPD

About Setting Environment Variables

UNIX Specifics

z/OS Specifics

How to Configure Integrated Windows

Authentication

Overview

Note: These instructions are for configuring Integrated Windows authentication (IWA)

Note: This is the default on Windows and UNIX

Instructions

Note: In a single deployment, do not use Quest with other shared libraries.

Environments at

Note: Even if IWA is configured, any available cached or stored credentials are

See Also

User Logins

Registering SPNs

Automatic Registration

machine-name and SAS/netbios-machine-name (for example,

Manual Registration

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

Note: You must also make any necessary adjustments to client-side connection profiles

UNIX Specifics

Configuration Guide for SAS Foundation for UNIX Environments.

Manually Registering Object Spawner SPNs

Note: The following manual registration is required only on Windows systems. It does

Note: The preceding SPN statements differ from the one that is built if you use the local

Manually Registering SQL SPNs

Note: You need to configure delegation if the object spawner needs to delegate

Forcing Kerberos

Note: You cannot use Windows local accounts with this configuration, because those

Note: On Windows systems, if the workspace server accesses network resources

Note: On UNIX systems, the account that the SAS SPN is registered against must be

UNIX Specifics

Supported Protocols

IWA to an OLAP Server

Note: In the platform, most connections to the OLAP server are metadata-aware, not

IWA to a Clustered Metadata Server

Introduction

Example

Shared Hardware

Note: If you make this adjustment to the object spawner, the domain account must

IWA to Servers That Use DNS Aliases

About IWA from SAS Web Applications

How to Store Passwords for the Workspace

Server

Note: This is one of several solutions to a mixed provider situation (and it is not a

See Also

Note: If you do not store the passwords, users are prompted for such credentials