Logically the number of sites is part of each Citrix Design. This topic is also addressed in the Citrix Virtual Desktop Handbook. There are three reasons specified in the handbook which validate the use of multiple sites: network, risk tolerance and security. The guideline however is to keep the number of XenDesktop sites (should we now call those Virtual Apps and Desktop sites?) should be kept to a minimum to reduce architectural complexity and administrative effort. I totally agree on this topic, but next to design environment other factors are there causing that multiple Citrix sites are in the picture which are not designed with multi-sites in mind. Reasons could be the acquisitions/mergers of companies or out-sourcing a business application to an Application Service Provider (ASP). In this article I will focus on this kind of multisite scenarios and what the options are to combine those from an end-user perspective.
Logically the two possible scenario I just mentioned in the introduction are completely different and probably will have a complete other solution. So the possibilities in this article cannot be applied to all scenarios where multi-sites exists.
When multi-sites are part of the same domain it is pretty easy to combine those within one StoreFront environment (and Gateway logically). When the sites are located within multiple domains it becomes a different story logically.
Creating Trusts between the domains
First option is from a Citrix infrastructure standpoint the easiest one, however from an active directory part it probably one of the most complex ones as also the trust should be set-up to both sides. In this scenario we can combine the sites easily into one StoreFront by specifying both Sites with their Delivery Controllers in the configuration. As it is a two-way trust user can use resources from both Citrix sites and also multi-site aggregation/user mapping can be used. This scenario is viable with a merge or acquisition between companies, which will fully cooperate with each other. But logically it will have the most impact on both infrastructures.
Authorization via the Delivery Controllers
If a trust between the domains is not possible but you would like to use the same StoreFront servers for each domain there is option called XML Authentication. With XML Authentication the authentication process is not executed on the StoreFront servers, but is delegated to the configured Delivery Controllers. From StoreFront 3.5 this option is available in the GUI and configurable per store. Unfortunate if multiple controllers are added those are picked in a round robin manner. Because of this you can not mix different domain Delivery Controllers on one store (as there is no way StoreFront know which Delivery Controller is capable to handle which specific domain requests). So for each set of Delivery Controllers for XML authentication you need to set-up a specific store. Also the list of Delivery Controllers applies to all authentication methods within this store. Summarized with this option you can use one Storefront server groups with a store for each separated domain. So you have a kind of single entrance, but not fully as the URL is different for each separated domain by default. Don’t forget that is also not possible to combine the Citrix sites for one user from another domain. Users will have two different accounts if they need to have access to both environments.
Using SAML authentication
In the case users need to have access to multiple sites and a requirement is to use the same username (and corresponding password/MFA principles) SAML authentication is the way to go. Where you will need to configure SAML is dependent from the needs and requirements. If only users from one environment need to have access to another site, only the “another” site needs to be configured with SAML. In case of a merge for example both parties need to have access than both sites need to be set-up with SAML.
Let’s start with the part that only one party need to have access to another site. In this case another site needs to have Citrix FAS in place and need to configure SAML on NetScaler Gateway or StoreFront. For more information about Citrix FAS I refer to my article about Citrix FAS tips and tricks <<LINK>>. In this case the users will still have two portals where they need to enter their credentials on both portals. If there is a need that user do not need to enter the credentials twice you need to set-up SAML on both sides.
If both parties need to have access to each other Citrix sites are or there is a requirement that use do not need to enter their password twice you need to set-up SAML and Citrix FAS on both sites both referring to the same IdP (which can be ADFS, Azure AD or something else). If both refer to the same IdP you still will have two portals but if the user is already logged on based on the available token the second portal will logon automatically.
But still your users will need to use two URLs. If you want to use one portal there are options using a third-party product or using the website shortcut options within StoreFront, but more on that in an upcoming article.
In the case users don’t have to use applications of each other and you just want to have a single entrance point Citrix Cloud can be a solution. Within the Citrix Cloud several Citrix sites can be added to the Cloud configuration by placing a Citrix Cloud Connector for each Citrix Site. When those sites are in multiple domains this is not an issue as this is fully supported. The user can logon with the AD account in which the site resides. As the support on authentication methods is a bit limited at this moment, there is not yet a solution to combine the sites within one user account (by leveraging the cloud components).
In this article I discussed the possibilities to combine Citrix Sites resisting in different domains. For a full integration the best (and actually only) solution is set-up Microsoft Active Directory trusts between the domains. If this is not the case alternatives are XML Authentication (which requires different stores), using Citrix Cloud (which required different user accounts for each domain) or using SAML authentication with Citrix FAS (but different portals are still in use). For the last topic there are some possibilities, which I will go into more details in an upcoming article.