Authentication Mechanisms

Integrated Windows Authentication

Integrated Windows Authentication (IWA)
Summary	A Microsoft technology generates and validates Windows identity tokens. This has the effect of causing participating SAS servers to accept users who are authenticated to their Windows desktop. The SAS implementation of IWA supports only desktop clients and servers on Windows.¹
Scope	Primarily used for connections to the metadata server and the workspace server. Also supported for direct connections to an OLAP server (for example, from a data provider).
Benefits	Bypasses the initial logon prompt. Accommodates logon mechanisms that are not password-based (such as smart cards or biometrics). No user credentials are transmitted. Users don't need the Log on as a batch job privilege.
Limits	Clients and servers must be in the same Windows domain or in domains that trust each other.² If you use IWA for a workspace server that accesses Windows network resources, the Kerberos protocol must be used and the object spawner account must have the trusted for delegation Windows privilege. The SAS implementation of IWA is not supported for Web applications (or analytics platform clients such as SAS Enterprise Miner). If you use IWA for the metadata server, there are no cached credentials from an initial logon. For this reason, if the workspace server is also on Windows, it is a good idea to configure IWA for that server also. 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 Integrated Windows Authentication Settings.
Use	Optional
1 If you configure Web authentication, Web applications might use IWA. This occurs if your Web environment offers IWA. This isn't part of the SAS implementation of IWA, which is for desktop applications only. 2 The SAS implementation of IWA doesn't support servers on hosts other than Windows. Configuring a server on UNIX to accept Active Directory accounts (by using PAM or configuring direct LDAP) doesn't mitigate this requirement.

The following figure is an abstraction of how this mechanism works.

[Integrated Windows Authentication]

The numbers in the figure correspond to these actions:

The client asks Windows for a token that represents the user who is currently logged on to the client computer. This step is initiated when a user launches a desktop client or makes a request for a workspace server.

Note: The token represents the client who is running the SAS application. If you use the Windows runas command to launch a SAS application, the token represents the host account that you chose to use.
Windows provides the token to the client.
The client sends the Windows token to the target server. Notice that only the token is sent; the user's password isn't available to the target server.
The target server sends the token back to Windows for verification.
Windows tells the target server that the token is valid.
The target server accepts the connection from the client. The user's ID is provided to the target server in domain-qualified format (for example, WIN\joe).

Note: If the target server is the metadata server, the SAS identity phase follows. See How SAS Identity is Determined.