This is a question that comes up occasionally: can I use XenApp without relying on Active Directory? Sometimes the question is more direct: can I use LDAP instead of AD for user authentication? The answer is a qualified yes, but it’s an interesting question to be asking.
We’re talking about running apps on Windows, so what makes people want to not use AD for authentication? It can be a specialized authentication requirement: custom smart cards, for instance. It can be a choice of a different directory system: Novell, Sun, OpenLDAP. It can be a trust issue: AD domain membership is pretty cosy, intra- and even inter-forest trusts are, well, quite trusting.
Whatever the reason, there is a fundamental question to be answered first that dictates how the conversation goes from there. Do the apps that will run on XenApp need to authenticate silently to other Windows-based network resources (file shares, Exchange, maybe SharePoint or SQL Server etc), or does it not really matter what the session identity is at the Windows level?
There is another angle, which is do the apps need a Windows profile to persist user settings, but that is really a special case of using file shares.
Case 1 – App Uses Silent Windows Authentication
If an app needs to authenticate silently to other resources, then it is clear we need a real AD environment, and XenApp sessions need to run as real AD users. That doesn’t mean we can’t support funky authentication requirements though – identity federation technology like ADFS is remarkably powerful at separating choice of user authentication from choice of session identity: a form of identity virtualization, if you will. In the case of ADFS, we are using AD identities for the XenApp sessions, but these can be secondary accounts shadowing the real user accounts held elsewhere. It is a bit like directory syncing, but crucially doesn’t ever touch passwords. It doesn’t even have to be one-to-one.
But the approach I want to talk about today is for the other situations, where the app doesn’t care what identity Windows is using underneath it. There are plenty of apps like this; web apps accessed via a published browser on XenApp are a common example.
Case 2 – App Doesn’t Care About Windows Identity
You can build on the standard anonymous app publishing that’s been in XenApp long before it was XenApp. This provides a basic, but irrelevant, Windows identity to each session, implemented using a pool of local accounts that are kept clean (effectively a fresh clone for every session). Of course, by definition no authentication is required to launch an anonymous app, unless you take extra steps to deny access until authentication is performed elsewhere. One good place to do that is Web Interface.
However, there are a couple of drawbacks. One, you can’t reconnect to a session; if it gets disconnected by a network glitch, it’s gone. Two, the admin can’t easily tell which session is which – they have only the client name and IP address to hand.
As you have guessed, we have a solution to this. A while back, we implemented an extension called tagged anonymous users. This was done to support a scenario with some rather unusual requirements explained here. The premise is that authentication will happen at Web Interface, through custom logic, and Web Interface will assert the user identity to XenApp. XenApp tags the local anonymous account name for the session with this asserted identity, making it safe to allow reconnects and making the user identity visible to the admin.
So Let’s See It!
Here’s how to try it out yourself, in four easy steps – I used LDAP authentication in my prototype:
- Modify Web Interface to authenticate user credentials against an LDAP directory.
- Enable the tagged anonymous user capability in XenApp.
- Further modify Web Interface to launch anonymous apps so they run under tagged anonymous accounts.
- Optionally configure XenApp to only launch applications via Web Interface.
Modify c:\Inetpub\wwwroot\Citrix\XenApp\app_code\PagesJava\com\citrix\wi\pages\auth\Explicit.java, as shown in the attachment (original, modified, and diff files provided). I used WI 5.1, but essentially the same changes should apply to any 5.x version.
The change is to use the credentials entered by the user to directly authenticate to an LDAP directory, instead of making a XenApp XML service request to validate the credentials. The mechanism for authentication could be chosen based on the entered or selected domain name, to allow a mixture of normal AD authentication and external LDAP authentication.
In my prototype, I configured WI to hide the domain entry field as it served no purpose.
Enabled the tagged anonymous user capability on a XenApp 4.5/5.0 server running HRP1 or later. This capability is currently only available on Windows Server 2003.
- Create TaggedAnonUsers as a DWORD with the value 1, under HKLM\System\CurrentControlSet\Citrix
- Increase MaxAnonymousUsers DWORD value, in the same location; a value of 500 is suggested
XenApp normally maintains a fixed pool of numbered local accounts for running anonymous applications, but when using tagged accounts it acts as a cache instead, allowing each server to accept any valid tag even if the number of tags in use might be very large. The server will automatically create a new local account of the right name when it encounters a new tag, first deleting one that has not been used recently if necessary. For all anonymous accounts, the profile directory is created during logon and deleted when the session terminates.
Modify c:\Inetpub\wwwroot\Citrix\XenApp\app_code\PagesJava\com\citrix\wi\pageutils\SessionUtils.java, as shown in the attachment.
At this point the original user credentials are discarded, except for the username which is used to derive a tag for the anonymous user account on XenApp. The tag must not be longer than 15 characters, so in some cases it may be necessary to use something other than the LDAP username.
To invoke the tagged anonymous user capability in XenApp, we manufacture a set of credentials where the domain value is the fixed string TAG!DOM – the username and password are ignored. The tag to be included in the anonymous account name on XenApp has to be passed to XenApp in a particular way, which is accomplished by setting the ICA client name value assumed by WI. A WI configuration change is also required, which is to uncheck the client name override setting:
The final, optional, step is to configure XenApp to reject ICA connections that are not started via Web Interface (or a client that uses Web Interface, such as Program Neighborhood Agent or Dazzle). This prevents users able to directly connect to the XenApp servers from launching the anonymous applications, without first passing whatever authentication step is required by Web Interface. (Administrators are still able to logon interactively.)
The End Result
With the above customizations and configuration, anonymous applications run under identifiable local accounts, and the local hostname of the client endpoint device is also visible, as can be seen in Task Manager:
and similarly in the Citrix management console session lists (this one provides a farm-wide view):
So there you have it; lightweight identity virtualization in four easy steps.