Authentication Tasks

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. [cautionend]

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

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.
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.
For the workspace server, participation in IWA also requires certain settings in that server's metadata definition.

To configure IWA:

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.
If the workspace server is on Windows, 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, define settings as follows:
  1. Select the Host radio button. IWA is a form of host authentication.
  2. Select the Negotiate security package.
  3. 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.
  4. 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.
  Here is an example of IWA settings:
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.
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:

Integrated Windows Authentication Settings
Server Setting	Associated Requirements
Negotiate security package	The client must select the Negotiate security package. To verify client-side settings, click Advanced in the connection profile. 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 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. 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 ensure that only Kerberos is used, see How to Force Use of Kerberos. If you need to use a custom SPN: 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. Update all client-side connection profiles and the logical workspace server definition (if applicable) to include sas/customValue in the SPN field.
NTLM security package	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. [cautionend]

Top of Page