Historically, one of the key functionalities provided by Citrix Cloud Connectors is to connect on-premises Active Directory (AD) infrastructure to the Citrix Cloud console without the need for additional AD trusts. This might be done so that the AD can be used as an Identity Provider (IdP) for adding VDAs to Machine Catalogs in DaaS, for creating machine identities when using Citrix Machine Creation Service (MCS), as part of a WEM solution, when using Kerberos to authenticate with a WebApp through SPA, or in numerous other scenarios.
Some of these use cases rely on other components in the Cloud Connector, such as the Broker Service for registering VDAs or MCS hypervisor plugins for provisioning VDAs to on-prem hypervisors. Even so, we are seeing many situations in which Citrix customers can make use of the advantages of the Connector Appliance in their environments, instead of leveraging the Cloud Connector.
Citrix is continuously adding capabilities to deliver an optimized experience for admins linking cloud and on-premises resources. This is why we are excited to showcase Active Directory connection support for the Citrix Connector Appliance! Let’s take a closer look at how we have connected to AD historically, and how you can now leverage Connector Appliances within your environments.
Active Directory as Identity Provider
As an example of how AD has been configured historically as an IdP leveraging Citrix Cloud Connectors, let’s look at the AD deployment shown in the diagram below. In this environment, the administrator has configured separate AD forests for their resources and users. This is a common structure used in many Citrix environments. We can see that the resource domain, “cvadr,” contains their VDAs. The two user forests, “cvadu” and “cvadu2,” each contain the users which need to authenticate to Citrix Workspace and launch apps and desktops. These might be separated to match organization business unit structures, for historic reasons (e.g. following a merger), to allow isolation of environments, or for numerous other reasons. In order for users to launch desktops in the resource domain, a one-way trust must have been established from the resource domain, “cvadr,” to each of the user domains.
In a traditional Citrix Cloud deployment, the customer would need to deploy two Citrix Cloud Connectors in the resource domain, as well as two in each of the user domains. The connectors in the resource domain handle enumerating the machines in Citrix Cloud, registering the VDAs, as well as any other functionality such as high availability with LHC and handling traffic when not using connector-less. However, the connectors in the user domains are deployed so AD can be used as the IdP. When a user logs in to Citrix Workspace, the request is routed to the Cloud Connector in the relevant domain.
In the above scenario, since the connectors in the user domains are only being used for identity assertions, they are a good candidate to be replaced by Connector Appliances. This brings with it the host of advantages associated with moving to a Linux appliance, including security, cost savings, reliability and manageability. However, the Connector Appliance also has the significant advantage of being able to be joined to multiple domains. As such, in the scenario we have been discussing so far, a single pair of Connector Appliances can be joined to both domains – routing identity requests to the correct domain as necessary. Alongside the advantages of using a Connector Appliance, the administrator is able to reduce the number of connectors they must manage. Instead of deploying a pair of Cloud Connectors in each user domain, they can use a single pair of Connector Appliances across all domains. This is illustrated in the diagram below.
While the scenario sketched out in the diagram above shows an idealized, very small deployment, this has been shown to be effective for real Citrix Cloud customers. In one case, a large insurance customer was able to reduce their connector footprint by 85%. Previously, they were managing 39 connectors across 11 AD user domains. With the multi-domain feature, the customer was able to use only 6 Connector Appliances to cover all user domains.
Another example is internal to Citrix. Within Citrix, a significant proportion of the engineering team use desktops delivered using our own DaaS technologies. This represents a sizable environment with over 1,000 active users and over 550 logons per day. Previously, DaaS for engineers used 17 Cloud Connectors to manage their demands. With this feature, just 2 Connector Appliances were able to handle user logon.
Connector Appliance AD Reliability and Resiliency
The AD features of Connector Appliance were announced as Generally Available in September 2022. Since then many customers have been benefiting from the feature. However, in that time, we at Citrix have been gathering feedback and continuing development of the feature, particularly in the area of reliability and resiliency. This has led to a suite of upcoming changes which will continue to enhance the feature for customers. Some of the changes are as follows:
- The Connector Appliance currently finds the closest Delivery Controller (DC) or Global Catalog (GC) when booting. If it is later not able to connect to this DC/GC the request currently fails. With this change, it will failover to the next closest.
- When joining a forest the Connector Appliance ignores all domains which are unavailable. With this change, if these domains later recover, the Connector Appliance will connect for these too. Similarly if a new domain is added to the same forest this will also be served.
- Updating to the latest AD connectivity libraries
With the Connector Appliance operating a custom Linux Operating System, a significant proportion of the logic for performing AD operations is custom code, developed in-house at Citrix. This offers huge opportunities for security and optimization. The changes described above represent an example of this. However, we are not planning to stop there. Further optimizations are coming including multi-threading requests to different domains to allow them to run in parallel, along with integrating diagnostic tooling into the Connector Appliance to simplify deployment and management of AD functionality.
Learn More
As we continue to bring parity to the Connector Appliance, we are delivering capabilities to optimize cost and save admins time. To learn more about the Connector Appliance, please visit our product documentation. And keep an eye out for even more exciting enhancements to come.
Disclaimer: The development, release and timing of any features or functionality described for our products remains at our sole discretion and are subject to change without notice or consultation. The information provided is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making purchasing decisions or incorporated into any contract.
