Pass-through authentication is a simple concept. User credentials are passed to a Web Interface site and then to the XenApp/XenDesktop servers, preventing users from having to explicitly authenticate at any point during the Citrix application launch process. While this authentication method seems straightforward, there are some moving pieces, and this article aims to break these down to provide a more detailed understanding of how this process truly works within Citrix.
Pass-Through Authentication – Web Interface Site
The first step to the pass-through process occurs at the Web Interface site. Users are able to navigate to the web interface site, and their credentials are passed through and they are presented with their Citrix delivered resources. Web Interface is built on Internet Information Services (IIS). For pass-through authentication to work, IIS Integrated Windows Authentication must be leveraged. Formerly called NTLM, this authentication method hashes the user credentials before they are sent over the network. When this type of authentication is enabled, the client browser proves it is authenticated through a cryptographic exchange with the Web Interface server, involving hashing. Because of this, the web browser is responsible for authenticating with the Web Interface Server (IIS). It is important to note, though, that credentials are actually never exchanged. Instead, the signed hash is provided to IIS, proving that said user had already been authenticated at the Windows desktop. The web interface user uses the user’s AD context (sometimes referred to as a token) to retrieve the user’s AD group membership and pass this list of groups directly to the XML service for authentication. At this point, the user has successfully passed through to the Web Interface site, and can now view his/her Citrix resources.
- The WI server must be in the same domain as the user, or in a domain that has a trust relationship with domain of the user.
- If the WI server and user are in different domains, and resources are published using Domain Local AD groups in the user domain, then the WI will not be able to enumerate these, even with a proper AD trust relationship (due to the very nature of Domain Local groups).
- The WI site should be added as a Trusted Site or Intranet Zone site in Internet Explorer. In addition, the security settings should be modified so that User Authentication\Logon is set to ‘Automatic Logon with Username and Password’.
- Pass-through authentication is not supported on Web Interface for NetScaler
Pass-Through Authentication – XenApp/XenDesktop Session
One of the biggest misconceptions with Pass-Through authentication in Citrix is that it only occurs when a user navigates to the Web Interface site and he/she is automatically passed through. As mentioned above, this IIS authentication method that is being used does not actually exchange the user password. In other words, Web Interface is never in control of the user credentials. This brings up the question: How are users passed through to the actual XenApp/XenDesktop ICA session?
While the web browser has a role in authenticating the user to the web site, the Citrix client (Citrix Receiver) plays an integral role in making sure the user is fully passed through to the application or desktop. Citrix Receiver installs a process called SSONSVR.exe, which is the single sign-on component of the client (no, not password manager SSO, but rather desktop credential pass-through authentication SSO.) This process is fully responsible for passing the user credentials to XenApp or XenDesktop. Without this piece, pass-through authentication will not function. In non-Enterprise versions of the Citrix Receiver, the SSON piece is not automatically installed, and must be done during a command line install of the client. For more information, refer to http://support.citrix.com/proddocs/topic/receiver-windows-34/receiver-windows-cfg-command-line.html.
The below links include information regarding enabling Pass-through authentication on Citrix, common Pass-through errors and troubleshooting steps, as well as Microsoft documentation outlining the different authentication methods in IIS: