At a Worldwide Consulting Solutions we are currently in the process of creating a “XenApp in the Cloud” reference architecture for System Integrators and CSPs. While discussing all kinds of multi-tenancy considerations and configurations for Citrix products, we stumbled upon a topic which is very central to almost every XenApp infrastructure, but is not in the reach of Citrix. This topic is so central, that it actually made us stop for a moment after we discovered the complexities it keeps when using it within Cloud based infrastructures.
The topic I’m talking about (as you may have guessed after reading the heading) is user authentication and more specifically Microsoft Active Directory. So authenticating users on a cloud based XenApp server is not too hard. We could create server local user accounts or create a separate “Cloud Active Directory” and issue user accounts to the users. We could even go down the road of Active Directory Federation Services to have a very elegant solution to this simple problem.
The complexity in all its facets appears in the moment you start thinking about user access to application backend resources, such as SQL, file servers, or some kind of middle ware that remains within the data center of a customer for whatever reason. So assumed an application and its backend rely on Active Directory for user authentication and authorization, we need to make sure that the application is started within the right context on our Cloud based XenApp server. Otherwise the users will be prompted for credentials whenever accessing a backend and we cannot propose the usage of password manager as a final solution for this seriously.
So the reason of this blog is to ask you “How would you authenticate your users in a Cloud environment?”. To make it more easy and to give you some inspiration, I have attached three different scenarios we can think of.

Scenario 1:
We extend the customers Active Directory across the WAN (some kind of IPSec tunnel) and make the XenApp Servers, which reside within the customer facing part of the SI Cloud, members of the customer AD.

Scenario 2:
We create a separate domain for every customer as a sub-domain of the SI Active Directory Forest and configure the XenApp servers as members of the customer specific domain. To allow the users logging on using their own credentials, we establish a one-way trust between our sub-domain and the customer AD Forest (i.e. CustA.MySI.local trusts CustA.local).

Scenario 3:
We create a separate XenApp sub-domain underneath our SI AD Forest. All customer XenApp servers a members of this domain, but we could use OUs, GPOs and Workergroups to make sure not mixing the users of different customers on a single XenApp server. To allow the users logging on using their own credentials, we establish a one-way trust between our sub-domain and the customer AD Forest (XenApp.MySI.local trusts CustA.local and also trusts CustB.local).

The Question(s):
While all three of the solutions have pros and cons, we need to decide on one or come up with a completely new one. So which would you prefer? Which do you see most often? Have we missed something important?

Any input is appreciated. You can either respond to this blog by commenting directly on this site or write me a direct mail thomas(dot)berger(at)eu(dot)citrix(dot)com