Initially, with the introduction of StoreFront it relied solely on its authentication service for user authentication purposes. This, as you might be aware is different from Web Interface, which will directly contact one of the configured Delivery Controllers where the Broker/XML service will take over. Since Web Interface is still widely deployed and used in (large) production environments (and StoreFront now also supports XML based user authentication) I would like to talk, in a bit more detail about both authentication methods available today.
FMA fact: Web Interface will be ‘End of Life’ in June 2018, however, Citrix advices to deploy StoreFront for new as well as existing deployments.
Authentication in general
Within a XenApp/XenDesktop Site you basically have two (main) points of authentication, one of which is StoreFront, the other one being the NetScaler Gateway when authenticating externally, for example, though it could be used for internal authentication purposes as well. The StoreFront server will communicate with the Citrix Receiver, your Delivery Controllers and the NetScaler Gateway (call-back and STA) when users are authenticated and resources are launched externally.
Next to the above, StoreFront can also be configured to communicate with App Controller as part of a XenMobile deployment, and/or VDI-in-a-Box is also (still) optional. Like the Delivery Controller, StoreFront plays an important role in the resource enumeration and launch processes and it functions as the main Store (there can be multiple) from where users (can) subscribe to their desktops, applications and other resources.
StoreFront (internal) authentication/enumeration
Although I’ve covered this in some of my other blogposts as well, I’d still like to briefly touch on the StoreFront user authentication/enumeration phases, internally this time.
Make sure to check out the image below as well.
With StoreFront, users are authenticated by the authentication service (it communicates with Active Directory) which is an integral part of StoreFront. Note that this is default StoreFront behavior. As of StoreFront version 3.5 it (the authentication service) now also includes the Self Service Password Reset feature (SSPR). Users can authenticate to StoreFront using different methods like usernames and passwords, Domain pass-through, NetScaler pass-through, using smart cards or by enabling unauthenticated user access. And of course we also have technologies like Kerberos constrained delegation for XenApp 6.5, and newer features like the Federated Authentication Service, or FAS, which are both out of scope for now.
As soon as a user logs in by filling in his or her username and password (on the StoreFront web page using the Receiver for website configuration, or using a locally installed Citrix Receiver) the StoreFront authentication service will pick up the user credentials and contact a domain controller where the actual user authentication will take place.
Once authenticated (1), StoreFront will forward the user credentials, as part of an XML query to one of the configured Delivery Controllers (2), assuming you configured at least two of course. In between, StoreFront will check its local datastore for any existing user subscriptions and stores them in memory.
The Delivery Controller receiving the credentials will again contact a Domain Controller, this time to * validate the user’s credentials (3) before responding to the StoreFront server. During the next step (4) the Delivery Controller will check with the Central Site database to see which resources have been assigned to the user before sending them over to the StoreFront server (5).
Finally, StoreFront will generate a webpage displaying all the resource icons (published applications and desktops) to the user (6). Here I assume that authentication is taking place internally and directly to StoreFront.
Make sure to check out this post as well, it contains more details on the above and surrounding process.
FMA fact: * Note how I mention user authentication and user validation. There is a difference. Authentication is to make sure that somebody is who he or she claims to be. Verification is done to find out which resources a user is allowed to launch, primarily based on Active Directory group memberships.
Web Interface XML based authentication
If we look at Web Interface, user authentication works a bit differently, it has no internal authentication service. When a user logs in by filling in his or her username and password, Web Interface will immediately forward these credentials, as part of a so-called XML query to a Delivery Controller, which will then contact a domain controller to authenticate the user before responding back to the Web Interface server. Also referred to as XML based user authentication. As before, Web Interface can authenticate users to, and enumerate and aggregate resources from, multiple XenApp Farms and XenDesktop Sites, not App Controller as part of XenMobile though.
XML based authentication for StoreFront
As of StoreFront version 3.0, Citrix re-introduced XML-based user authentication. By simply running a few PowerShell scripts (have a look here) user authentication falls back to the XenDesktop / XenApp XML service, like with Web Interface as highlighted earlier. Particularly useful when StoreFront is not in the same domain as XenDesktop / XenApp and when it is not possible to set up an Active Directory trust, or multiple. Again, this method will be/is disabled by default: at least now you have options.
FMA fact: As of StoreFront Version 3.5 and upwards PowerShell is no longer needed to enable XML based user authentication, it can now be enabled and disabled directly from StoreFront management console (GUI). Here’s the accompanying E-Docs page showing you how it’s done.
One is none…
The StoreFront server plays a vital role when it comes to user authentication, resource enumeration and launch. If there is no StoreFront server available your users will be unable to launch any resources (as an exception, although not recommended, a direct ICA connection would work and doesn’t need StoreFront). That is why you will always deploy at least two StoreFront servers per Site. By implementing a load-balancing solution, like a NetScaler or Windows NLB, for example your users won’t notice a thing when one or multiple StoreFront servers become unavailable.
To be able to provide your users with desktops and applications, StoreFront must be configured with at least one Delivery Controller (FQDN or IP address). Since ‘one is none’ we will always make sure to configure at least two Delivery Controllers for HA purposes. In the case of a Delivery Controller failure, StoreFront will automatically fail over to the next Delivery Controller in line; resulting in an active/passive configuration.
Within large (r) organizations, where the logon load is higher than average, an active/active approach might be a better fit. This can be accomplished by implementing a load-balancing device like the Citrix NetScaler, or you can choose to let the StoreFront server load balance the connections to the various Delivery Controllers instead.
Up to StoreFront 3.5 you will have to manually edit the web.config file for this, locate the following line: <farm name=”XenApp” xmlPort=”80″ transport=”HTTP” sslRelayPort=”443″ loadBalance=”on” farmType=”XenApp”>
Change ‘loadBalance’ to either “on” or “off”.
As of StoreFront 3.5 the above can be configured by simply placing a checkmark directly from the GUI, you’ll find it under ‘Manage Delivery Controllers’. As far as I know, the built-in LB mechanism used for this is based on RRDNS technology, or at least the result is similar.
Just a short, but hopefully helpful post none the less, which I had still lingering around.
Thanks for reading.
One response to “Inside Citrix: Web Interface & StoreFront — XML-based user authentication”
[…] Read the entire article here, Web Interface & StoreFront — XML-based user authentication […]