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:

Getting incorrect username or password error when using FAS to single sign on with VDA with event ID 102 and event ID 25 on DC

Some applications have features that read the token-groups-global-and-universal (TGGAU) attribute on user account objects or on computer account objects in the Microsoft Active Directory directory service. Some Win32 functions make it easier to read the TGGAU attribute. Applications that read this attribute or that call an API (referred to as a function in the rest of this article) that reads this attribute do not succeed if the calling security context does not have access to the attribute.

By default, access to the TGGAU attribute is determined by the

Permission Compatibility decision (made when the domain was created during the DCPromo.exe process). The default permission compatibility for new Windows Server 2003 domains does not grant broad access to the TGGAU attribute. Access to read the TGGAU attribute can be granted as required to the new Windows Authorization Access (WAA) group in Windows Server 2003.

Related:

Remove orphan ldap sync server from Vip enterprise gateway console

I need a solution

HI 

In our environment we have lost one of the gateways that synced the with ldap directory and we implemented a new one in a different ip, but we are still seeing in Home / user store in the vip gateway console the lost server.

How we can remove this orphaned instance of the gateway?

0

Related:

Incident with local user.

I need a solution

Hi,

DLP in version 14.6 linked to the active directory, when entering as a domain user if it generates an incident and performs the assigned blocking action, however, when entering as a local user to the endpoint, it does not generate an incident and much less the response action.

Is there a problem with this version ?, or is it necessary to perform some extra configuration?

Greetings.

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:

Proxy AD integration

I need a solution

In IWA direct AD integration for kerberos deployment below is suggested.

  1. Create a DNS “A” record for the ProxySG that resolves to the DNS name of the appliance’s Active Directory computer account name. For example, if you have an appliance named ProxySG1. With an IP address 1.2.3.4, in the blue9 Active Directory domain at acme.com. You can create the following DNS record:

    ProxySG1.blue9.acme.com     Host (A)     1.2.3.4
     

  2. Ensure that client requests are directed to the DNS name for the ProxySG appliance’s Active Directory computer account:
    • Explicit deployments—Configure the client browser explicit proxy settings to point to this DNS name.

We have two proxy boxes in active-active setup (explicit mode) with DNS entry created to resolve to two VIPs prsent on both the box and load balancing  is happening with the help of DNS 

Name:    abc.x.y.net
Addresses: x.x.x.1

                     x.x.x.2
 

Both the VIPs are configured on two proxy boxes.

x.x.x.1 Master on first  box and priority 100 on second

x.x.x.2 Master on second box and priority 100 on first

Client browsers are already pointed to abc.x.y.net.

As i undesrtand the requirement to create a DNS record for kerberos is already done and not required.Please confirm.Also this setup will not come under Kerberos load balancing scenario or will it ?If yes than what should be the steps to achieve kerberos deployemnt with this setup

0

Related:

Workspace Environment Management (WEM): Active Directory search improvements in WEM 4.6

Introduction

The Active Directory (AD) system built into the WEM Administration Console and WEM Infrastructure Server has been refactored in WEM 4.6 to improve performance and stability.

Although AD searches performed by the WEM Console and WEM Infrastructure server in previous WEM versions have typically returned results quickly, many customer environments consist of multiple AD forests or AD domains. The Active Directory improvements introduced in WEM 4.6 are designed to improve performance and stability; particularly for multi-forest/domain environments.

Active Directory improvements in WEM 4.6

Global Catalog (GC) mechanism: AD searches are initiated against the AD forest’s Global Catalogue Server (GC) instead of searching against each of the forest’s Domain Controllers in turn.

Asynchronous search mechanism: AD searches are performed on all forests (GC servers or domains) at the same time, instead of searching one by one.

AD search timeout mechanism: If the AD User or Machine object lookup points to a forest or domain that is currently unavailable, a configurable timeout been introduced to prevent prolonged searching. The timeout value is set through the WEM Administration Console (Active Directory Objects => Advanced => Active Directory search timeout (msec)), as shown below:

User-added image

The default value is 1 second (1000 msec). The value set here affects AD searches for both the WEM Administration Console and the WEM Infrastructure Server. If an AD search time exceeds the value specified in this field, AD searching will stop.

This can be configured with a preferred value based on real environment conditions. In large environments or in cases where there are dead forest entries, having a higher value, could also cause issues such as an unresponsive/black screen when logging in, since the AD search will continue to run depending on the timeout value set. It is recommended to remove the dead forest’s trust relationship with current forest to avoid the time consuming queries. If this cannot be done, there will be an enhancement coming soon which will greatly decrease the query frequency and made blacklist for dead forests in codes automatically.

NOTE: Citrix recommends using a timeout value of at least 1000 msec to avoid a timeout before the AD search completes.


Troubleshooting Active Directory searches in WEM

If AD searches are failing:

  • Check that the Active Directory search timeout (msec) is appropriate for the environment. This means that there is no specific value to recommend. Consideration needs to be given if the environment includes multiple AD forests or AD domains.
  • Generate WEM Administration Console and WEM Infrastructure Server debug logs that capture the failed AD search occurrences. In the logs, Active Directory-related entries are marked as AD: in the header of the body, right after the function name:

User-added image

Related: