Azure Active Directory and Citrix XenApp and XenDesktop

Introduction

Citrix XenApp and XenDesktop have traditionally used Windows Server Active Directory domains to manage end user access and administrator roles. With the move to the cloud, the use of an Active Directory domain continues to remain a requirement.

When using Azure as a Resource Location, Azure Active Directory also has a role to play:

  1. Azure Active Directory must always be configured as the holder of an application service account for the Citrix service. This account is used by Citrix Cloud or Studio to perform machine lifecycle events within the Azure Tenant.

  2. Azure Active Directory can be used as a more general repository of accounts for administrators and users. Depending on the configuration and type of service, using Azure Active Directory for this role may be optional.

The remainder of this document is focused on the various Azure Active Directory configurations that customers are likely to have, how each of those configurations can be used as repositories of accounts, and the recommended way to associate a Windows Server Active Directory domain controller to manage your Citrix XenApp and XenDesktop environment.

Note: Customers using Windows 10 CBB under a Hybrid Use Benefit license are required to associate an Azure Active Directory instance with their deployment. For other service scenarios, use of Azure Active Directory as a repository is optional and will depend on the customer’s choice of architecture.

Identity management – “hybrid” or “born in the cloud”

Companies that were “born in the cloud” most likely began with an Azure Active Directory linked to some service. This is often the Azure Active Directory associated with an Office 365 Tenant.

Companies that were born in a datacenter typically adopt a hybrid model with some assets in Azure and others remaining in the datacenter. These customers often add Azure Active Directory to an existing Windows Server Active Directory to support authentication with some external service.

The key difference between the two origins is whether there was an existing Windows Server Active Directory that needs to be synchronized with Azure Active Directory (aka ‘Synced with Active Directory’), or if the user accounts are only in Azure Active Directory (aka ‘In cloud’).

Citrix machines (XenApp and XenDesktop workers and supporting infrastructure machines) have a requirement to be joined to an Active Directory domain. This is required for domain computer accounts, new machine provisioning (creation of machine accounts), user association, and pass-through / Kerberos authentication to resources. It is because of these requirements that Azure Active Directory cannot be used alone.

When Azure Active Directory is used with the Windows 10 CBB under a Hybrid Use Benefit license computer accounts and user accounts must be in the same Azure Active Directory. Documentation related to this requirement and its configuration would be available soon.

Implementing Active Directory with Azure Active Directory

As mentioned earlier there are two Azure Active Directory origins for customers; they are born in the cloud or they are hybrid. And there are two Azure Active Directory to Azure Tenant associations; the Azure Active Directory is native to the Azure Tenant or it is not. These combinations impact the Active Directory options that a customer must consider.

  • Customers that only have ‘In cloud’ users can take advantage of Azure Active Directory Domain Services.

  • Hybrid customers with a VPN (such as ExpressRoute) should deploy replica Domain Controllers in Azure.

It was previously described that many customers will have multiple Azure Active Directories. The key take away that affects any implementation is that the Azure Active Directory used for the application service account, can be different from the Azure Active Directory where user accounts reside.

The important design point is that the Domain Services are linked to the Azure Active Directory where user accounts reside. This is important all the time, but critical using Windows 10 CBB under a Hybrid Use Benefit license.

The following sections describe the primary scenarios through the use of diagrams to give an understanding of the topology and the relationship of the accounts and Active Directory components.

In cloud user accounts

In this scenario, the user accounts are ‘In cloud’. Therefore, Azure Active Directory Domain Services can be used to provide the necessary Domain Controller services required.

Useful links:

Some possible models with Azure Active Directory are:

In Cloud with one Azure Active Directory

The customer has one Azure Active Directory domain, which is also the same Azure Active Directory associated with the customer Azure Tenant.

User-added image

Figure 1- In Cloud customer with a single Azure AD

In Cloud with more than one Azure Active Directory

The customer could also have two (or more) Azure Active Directories. In the example below, the customer’s user accounts are being synchronized with an Azure Active Directory associated with an Office365 subscription. And the Azure Tenant account has its default Azure Active Directory which is separate.

Azure Role Based Access Control is used to grant access to user accounts from the Office365 Azure AD to the Azure Tenant, however the application service account used by Citrix must be an account native to the Azure Tenant.

User-added image

Figure 2- in cloud customer with a separate user Azure AD

Synced with Active Directory user accounts

In this scenario, the user accounts are ‘Synced with Active Directory’. Therefore Domain Controller IaaS VMs need to be deployed into the Azure subscription. These can be a replica domain controller if this is a hybrid deployment.

Useful links:

As with the ‘In cloud’ options above, similar topologies exist for customers that have a hybrid networking scenario. In the hybrid scenarios, there is some resource or application that must be accessed from a remote datacenter through a VPN, and Windows pass-through / Kerberos authentication is used by that resource or application.

Hybrid with one Azure Active Directory

User-added image

Figure 3- Hybrid network with a single Azure AD

Hybrid with more than one Azure Active Directory

User-added image

Figure 4- Hybrid network with a separate user Azure AD

Tips for success:

The application service account must be created in the Azure Active Directory instance associated with the Azure Tenant where Citrix resources will be deployed.

When creating the application service account from the Citrix Cloud portal or Studio using the “Create New” option, the Azure user account used to create the application service account must be a member of the Azure Tenant Azure Active Directory.

User-added image

Guest identities such as a Microsoft ID or invited from another Azure Active Directory cannot be used. Enable the “user type” column to discover this in the Azure Active Directory portal.

See Citrix documentation; Microsoft Azure Resource Manager for additional details.

When using the “Use existing” option in the Citrix Cloud portal or Studio delegated users can manually create the application service account through the Azure Portal.Refer to Manually Granting Citrix Cloud Access to Your Azure Subscription for more information.

Additional learning:

Related:

Federated Authentication Service (FAS) | Unable To Launch App “Invalid User Name Or Wrong Password”

Federated Authentication Service (FAS) | Unable to launch apps “Invalid user name or wrong password”

System logs:

Event ID 8

The domain controller rejected the client certificate of user U1@abc.com, used for smart card logon. The following error was returned from the certificate validation process: A certificate chain processed correctly, but one of the CA certificate is not trusted by the policy provider.

Related:

  • No Related Posts

Error “Invalid Login” on launch of FAS enabled Linux VDA Desktop.

You need to have the Kerberos Authentication certificate on all the domain controllers. To enroll for a new certificate follow the below steps.

1.On the domain controller, open mmc.

2.Click File, Click Add/Remove Snap-in.

3.Select Certificates, click Add, then select Computer account.

4.Expand Certificates (Local Computer), right-click Personal, click All Tasks, and then click Request New Certificate.

5.Press Next.

6.Select Kerberos Authentication and press Enroll.

Note: If you do not see the Kerberos Authentication on the Auto Enrollment in the Domain Controller certificate mmc, you need to go to Certificate Authority server and add the domain controller in the security of the Domain Controller Authentication Template and give AutoEnroll permissions.

Also, make sure you have configured krb5.conf on the VDA with the correct RootCA & Subordinate CA certificate information.

Refer ‘Incorrect root CA certificate configuration’ section in the below link:

https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/configuration/federated-authentication-service.html/

Related:

  • No Related Posts

Incorrect Username and password error when using FAS to single sign on with VDA with event ID 19

When launching an ICA session to the VDA with FAS, it fails with an error “The username or password is incorrect”. However, the certificate has already reached the VDA as per event ID 106. The certificate can be validated using : https://support.citrix.com/article/CTX219849 .

The System event logs on the VDA will show below event generated by Security-Kerberos :

Event ID 19 :

The KDC certificate for the domain controller does not contain the KDC Extended Key Usage (EKU): 1.3.6.1.5.2.3.5: Error Code 0xc0000320. The domain administrator will need to obtain a certificate with the KDC EKU for the domain controller to resolve this error. When using Windows Server Certificate Services create a certificated based on the Kerberos Authentication Template.

Related:

  • No Related Posts

Successfully Deploying XenDesktop in a Complex Active Directory Environment

The following environments assume that XenDesktop 5.x is installed on all DDCs and VDAs. This article is based on the registry based Controller Discovery – this is the recommended method for multiple forest registration.

The NetBIOS and Fully Quality Domain Name (FQDN) can be different. For example, the NetBIOS name could be BOB but the FQDN could be parent1.local or the NetBIOS name and FQDN can be the same:

Example: NetBIOS name is parent and the FQDN would be parent.local.

Note: Dots in NetBIOS names are not recommend.

Appropriate user access permissions are given for successful machine creation. In a cross-forest setup, use Delegation Control Wizard to keep permissions to minimum use. Permission must be given for the DDC Administrator to create machines in a different forest in a specific Organizational Unit (OU). The following minimum permission can be given for successful machine creation:

  1. Open Active Directory Users and Computers Microsoft Management Console (MMC).

  2. Right-click your OU and select Delegate Control.

  3. On the first screen, click Next.

  4. In the Users & Groups screen, click Add and pick a user or group you want to delegate rights to and click Next.

    The best practice is to assign a group rather than a single user, as it is easier to manage and audit.

  5. In the Tasks to Delegate screen, select Create a custom task to delegate and click Next.

  6. In the Active Directory Object Type screen, select Only the following objects in folder and select Computer objects.

    User-added image

  7. Select Create selected objects in this folder and click Next.
  8. In the Permissions screen, select General and then select Read and Write.

  9. Click Next.

    User-added image

  10. Click Finish to complete the delegation control.

Different types of Active Directory Setups

Simple Single Domain Deployment

The following diagram illustrates a XenDesktop deployment in a single Active Directory domain, where the DDCs, VDAs, and the users are all in the same domain.

User-added image

In this Single domain setup, all relevant components and objects are based on one single domain. Registration of VDAs with the DDC should be successful and no additional configuration, that is, the registry key changes is required.

Following is a list to check if VDA is unable to register with the DDC:

  1. Check Event Viewer for errors on both the DDC and the VDA.

  2. Ensure that the firewall is open for port 80 between the VDA and the DDC.

  3. Check that the FQDN of the DDC is correct in the registry setting of the VDA machine. On the VDA, check the following Reg Key:

    Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

    HKEY_LOCAL_MACHINESOFTWARECitrixVirtualDesktopAgent and confirm the parameter ListOfDDCs had the correct FQDN.

    If using 64-bit Virtual Machine, the VDA Reg Key is HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixVirtualDesktopAgentListOfDDCs

  4. Ensure that the DNS settings are correct on VDA and DDC, and both the computers can resolve each other by DNS name and reverse lookups. Use the XDPing tool, downloadable from the Knowledge Center article CTX123278 – XDPing Tool to further troubleshoot.

  5. Check that the Time is in sync between the VDA and DDC are correct.

    For further troubleshooting, see Troubleshooting Virtual Desktop AgentRegistration with Controllers in XenDesktop.

Single Forest with Multiple Domains or Single Forest with Multiple Domains with shortcut trusts

The following two diagrams illustrate a XenDesktop deployment in a single forest with multiple domains and a Single Forest with multiple domains with shortcut trusts – where the DDC, VDA, and Users are all based in different domains.

The following is the illustration for Multiple Domains:

User-added image

The following is an illustration for Multiple Domains with short cut trusts:

User-added image

Multiple Domains: DDC, Users, and VDA are based in various domains, by default, a bidirectional transitive trust relationship exists between all domains in a forest.

Multiple Domains with short cut trusts: DDC, Users, and VDA are based in various domains but at two-way shortcut, trust has been manually created between the DDC domain and the VDA domain. Typically, shortcut trusts are used in a complex forest where it can take time to traverse between all domains for authentication. By adding a shortcut trusts, it shortens the trust path to improve the speed of user authentication.

For successful registration of the VDA with the DDC, the following should be configured correctly. DNS Forward/Reverse Lookup Zones are in place and configured on the relevant DNS servers. For further troubleshooting of VDAs not registering, see Following is a list to check if VDA is unable to register with the DDC: mentioned in the Simple Single Deployment section.

Multiple Forests with 2 way or 1 way trusts (external trusts or forest trusts)

The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment. This is where the DDC is in a different Active Directory forest and the end users and desktops can be either in the same forest or in a separate Active Directory forest.

Note: For Forest trusts, both Forests must be in Win2003 Forest Functional Level.

User-added image

The preceding illustration shows two separate Active Directory forest with a two-way forest trust. DDC and Users are in the same forest (parent.local) but the VDAs are located in different forest (parent2.local).

For successful VDA registration with the DDC, the following must be configured correctly:

DNS, for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional Forwarders, Forward /Reverse lookup zones and Stub zones are all acceptable for name lookup/resolution. As an example, in the preceding illustration, on the DNS server for Parent.local, a Secondary Forward Lookup Zone and a Reverse Lookup zone for Parent2.local has been added and similarly the opposite has been done on the Parent2.local. This means that the DDC should now be able to resolve the VDA by name and IP and the VDA resolves the DDC by name and IP address.

See Managing a Forward Lookup Zone for information on managing Lookup Zones.

On the Desktop Delivery Controller, enable the following registry value on the DDC. This enables support for VDAs, which are located in separate forests: HKEY_LOCAL_MACHINESoftwareCitrixDesktopServerSupportMultipleForest (REG_DWORD)

User-added image

To enable VDAs located in separate forests; this value must be present and set to 1.

After changing the SupportMultipleForest value, you must restart the Citrix Broker Service for the changes to have an effect.

On the Virtual Desktop Agent, enable the following registry value on the VDA to enable support for DDCs located in a separate forest.

  • For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)

  • For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)

To enable support for DDCs located in a separate forest; this value must be present and set to 1.

Note: The next step is only required if External Trusts are only being used.

  1. If the Active Directory FQDN does not match the DNS FQDN or if the domain where the DDC resides has a different NetBIOS name to that of the Active Directory FQDN, you must add the following registry key on the Virtual Desktop Agent machine.
    • For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentListOfSIDs
    • For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentListOfSIDs
    • User-added image

The ListOfSIDs registry key contains the DOMAIN SID of the DDC. By using this key, DNS lookups are using the true DNS name of the DDC.

To obtain the correct domain SID of the DDC, the domain SID can be found in the results of the PowerShell cmdlet Get-BrokerController from an elevated PowerShell prompt on the delivery controller.

Note: You must restart the Citrix Desktop Service for the changes to have an effect.

Multiple Forests with One-Way Selective trusts

The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment using One-way Selective Trusts. The DDC is in a different Active Directory forest and the end users and existing VDAs (created either manually or through an alternative method) are in a separate Active Directory forest. In a one-way selective trust, automatic creation of Virtual Machines through DDC will fail, because of authentication issues.

For this example, the NetBIOS and FQDN are different in each Forest and domain.

Note: For One-Way Selective trusts, both Forests must be in Win2003 Forest Functional Level or above.

User-added image

Selective authentication is used in environments where users are explicitly granted/ allowed to authenticate to servers and resources on the trusting domain. This method gives domain administrators control on what rights users can be given to access services on the trusting domain. See Enable Selective Authentication over a Forest Trust for more information on Selective trusts.

Configure the following for successful registration of the VDA with the DDC:

  1. DNS for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional forwarders, Forward/Reverse lookup zones, and Stub zones are all acceptable for name lookup/resolution.

  2. Create the Selective trust on the relevant Domain Controllers.

  3. Follow steps provided in the Multiple Forests with trusts (External trusts – NTLM or Forest trusts Kerberos) section.

  4. The VDAs must be granted authentication access to the DDC. This is done through Active Directory Computer and Users snap-in.

    Note: VDAs can be added to a group to make management easier (granting rights). This is recommended.

    a) In Active Directory Computers and Users, browse to the location of the DDCs.

    b) Right-click DDC and click Properties.

    c) Click the Security tab.

    d) Click Add and click Locations to change the domain to where the VDAs reside.

    e) Click on Advanced, and click on Object Types. Choose ‘Computers’

    f) Select all the relevant VDA or Group (recommended) and click OK.

    g) Select the VDA’s or Group and give the rights – Read and Allowed to authenticate, as displayed in the following screen shot:

      1. User-added image

  5. On the DDC, select an Existing Catalog and create a relevant Assignment. When done, the Virtual Machines should show in a Ready State, as displayed in the following screen shot:

    User-added image

For further troubleshooting of VDA not registering, see Following is a list to check if VDA is unable to register with the DDC section.

Related:

Deploy ShareConnect Host Installer

Note: To follow the steps below, you must have a Windows 2012 domain controller. There may be slight differences in the 2008/2003 environments of the domain controller.

1. Log in to the domain controller and open the Active Directory Users and Computers window.

2. On the Active Directory console tree, right-click on your domain to create a newOrganizational Unit (for example, ShareConnect) and add computers you want to install ShareConnect to this organizational unit.

User-added image

3. Open Group Policy Management window to create a new Group Policy Object (for example, Windows SSO) for the Organizational Unit that you’ve created above.

User-added image

4. Right-click on the Group Policy object created and select Edit to modify its properties.

User-added image

5. In the Group Policy Management Editor window, go to Computer configuration >Policies > WindowsSettings > Scripts in the console tree.

User-added image

6. Click on the Properties link under Startup script to open the Startup Properties windows.

Note: You can also right-click on Startup script to open the Startup Properties window.

7. Click on the Add button to open the Add Script window. In the Script Name field enter the script path created here.

Leave the Script Parameters field empty.

User-added image

8. Right-click on the organizational unit created and select Group Policy Update.

This will update the group policy settings of the computers in the domain. If this fails, open the command prompt on your client computer and run ‘gpudate /force’.

User-added image

9. When the user reboots their computer and logs in using their domain credentials, ShareConnect will be installed.

Related:

  • No Related Posts

LDAP channel binding changes coming (from Microsoft)

I need a solution

Microsoft intends to release a security update on Windows Update to enable LDAP channel binding and LDAP signing hardening changes and anticipate this update will be available in mid-January 2020.”

If we use a System configuration task to bind to AD, is it doing the LDAP bind over SSL? 

Can anyone clarify if these new security measures on domain controllers (enforced with new win update) will break our binding during imaging process (via system config)?  What about technician access to the console?

https://support.microsoft.com/en-ca/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

I asked support for clarification, will report back if I get it.

0

Related:

Missing HOST SPN can cause workstation trust relationship error

Before resetting the computer account (which may work to sort out the issue), test if the machine has both HOSTNetbios and HOSTFQDN SPN’s. A missing SPN can cause this error.

Explanation:

Host name: MACHINE1.bigcompany.local

SPN’s should include: HOSTMACHINE1 and HOSTMACHINE1.bigcompany.local

On a Domain Controller or any server with ldap access, list the SPN for MACHINE1:

setspn -L MACHINE1

If any HOSTSPN is missing, use setspn (or GET-ADCOMPUTER in Powershell) to reset the SPN:

For example, from an elevated command prompt on an Active Directory server:

setspn -R MACHINE1

Related: