Even if the VDA registration with the Delivery Controller is already secured, in an environment where security is not an option, there are some configuration steps you can put in place in order to enhance the VDA registration process security.
Why should you care about VDA registration?
VDA registration is the link between the Delivery Controller (or Cloud Connector the Citrix Cloud customers) and the VDA. There is two communication channel established:
- VDA to Delivery Controller
- Delivery Controller to VDA
In order to secure the communication, Kerberos is used to authenticate both VDA and the Controller. That’s the reason why the use of the load balancer or alias is not supported since the SPN will not be present.
As, by default all the traffic between the VDA and the Controller use the port 80, the first step to do in order to secure the VDA registration process is to put in place SSL on XenDesktop XML service. To accomplish this, I’d recommend to use the script provided by Stephane Thirion (another French guy ;)):
During the registration process the following happens (Thanks Martin Zugec https://twitter.com/martinzugec):
- Get name of controller (using any of the supported methods)
- Translate that name (string) into UUID (SID)
- Use that SID for all communication purposes.
If you want to ensure the VDA is talking to the “legitimate” DDCs and not a rogue one, you can enforce the configuration:
- Create a Citrix Policy to disable Auto-Update (since 7.6) : Virtual Delivery Agent Settings > Enable auto update of Controllers => Disabled
- Add each Controllers FQDN in the following registry value
- HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
- Add each Controllers SID in the following registry value (Optional but add an extra step of security)
- HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
Adding the first registry value allow to specify the FQDN of the DDCs in order to avoid the VDA to register with an added DDC. The second one goes a bit further, you specify the SIDs of the allowed DDCs.
Why you shouldn’t register VDAs on an added DDC?
As mentioned in this article https://blog.alsid.eu/dcshadow-explained-4510f52fc19d, it’s now “easy” to add new objects in Active Directory.
As DDCs are handling critical operations, you should really avoid to connect user on a server where your SIEM is not installed!