|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.1|
If you configure Web authentication, Web applications
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.