Citrix

April 11, 2018

Environment:
Complex multi-forest Citrix environment with access, XML brokers, and VDAs members of different forests with two-way trusts between each in place.

Products:

XenApp 7.15 LTSR CU1
One-way Forest Trust (hosted resource infrastructure domain trusts users of remote forest)
StoreFront 3.0.x

Issue:
Per CTX209647 there exists a known condition with StoreFront in complex AD environments that leverage cross-domain nested groups as part of their Citrix resource provisioning, wherein applications which are provisioned to local domain local groups into which remote domainforest groups are nested, may fail to enumerate in StoreFront if logged into StoreFront via pass-through. This behaviour is observed both via domain passthrough in Internet Explorer as well as via Native Receiver client. Logging into StoreFront using explict authentication does not exhibit this behaviour. The main goal in the scope of this post is to restore the enumeration of all applictions via pass-through when employing Native Receiver specifically.

Root Cause & Resolution:
Citrix’s explanation of this behaviour has been:

When domain pass-through is used, IIS (on SF) contacts domain controller for user authentication. With the obtained token, it extracts the user SIDs , which are the group membership information of the authenticated user. Then SF includes these SIDs in the enumeration request and send the request out to XenApp. Then XenApp filters out user’s applications by comparing the SIDs granted access aganist each resource. Now the problems is the SIDs granted access to resources are ones from XenApp domain, while the SIDs in the enumeration request are the ones from Storefront domain. And the SF domain controller will not include the group SIDs of another forest during authentication (i.e. though the user being authenticated truly belongs to them). And that is when it fails.

Citrix’s present workaround for this issue (for which we have provided our findings in early April 2018) is to take the local domain local group out of the equation and publish the Citrix resources directly to the group(s) of the remote domainforest. This may be a simple consideration for smaller environment or under certain operational circumstances, however this may not be optimal for all scenarios.

As an example, take for consideration a remote hosted LOB app suite provided by a solutions provider to an enterprise organization (the customer), who manages the platform on behalf of the customer and is connected to the customer’s WAN via an MPLS link. The hosting AD and Citrix infrastructure for the remote platform are managed by the provider, whose infrastructure is joined to a separate forest from the customer to avoid extending the customer’s AD into the provider’s facility. The customer requirement specifies a domain pass-through experience for the tens of thousands of end users that will access this Citrix hosted app suite to avoid Native Receiver logon prompts (adequate client-side config for Receiver SSO not covered here). With a one-way trust in place, leveraging the customer’s domain groups for provisoning applications would result in the provider requiring credentials in the customer’s domain in order to look up necessary groups for application access. At scale this may be regarded as onerous and potentially introduce further security concerns.

An alternative to this approach is to employ HTTP Basic authentication vs Integrated Windows authentication method within the StoreFront environment hosting access to the remote hosted XML brokers, as well as the Receiver clients via an AuthManager registry key. Configuring Receiver to prefer HTTP Basic authentication appears to overcome the issue specifically for Native Receiver SSO passthrough scenarios. This unlikely resolves the issue if a browser-based passthrough experience is required, at which point Citrix’s official recommendation would likely stand.

NOV 2018 – UPDATE: When HTTPBASIC is enabled as the primary authentication method on Receiver, password changes on the workstation may not transfer through to Receiver and StoreFront which auto-refreshes user apps every 60 minutes by default. This can lead to lockouts until the user quitsrestarts Receiver or logs outin to the workstation. This behaviour was observed in StoreFront 3.0.x but not in 3.12.2000. Testing of password changes and HTTPBASIC is advised in your environment.

As a reminder is important to ensure communication to StoreFront always traverses over HTTPS, especially when employing HTTP Basic.

Required StoreFront Configuration (as seen in 3.0.x)

Required Registry Modifications for Receiver (restart Receiver once implemented):

On 64-bit Windows

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixAuthManagerProtocolshttpbasic
Name: Enabled
Type: REG_SZ
Data: True

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixAuthManager
Name: ProtocolOrder 
Type: REG_MULTI_SZ Value: httpbasic integratedwindows [Put these on separate lines]

ProtocolOrder Via REG ADD Command:
REG ADD "HKLMSoftwareWow6432NodeCitrixAuthmanager" /f /v ProtocolOrder /t REG_MULTI_SZ /d "httpbasic�integratedwindows"

On 32-bit Windows

HKEY_LOCAL_MACHINESOFTWARECitrixAuthManagerProtocolshttpbasic
Name: Enabled
Type: REG_SZ
Data: True

HKEY_LOCAL_MACHINESOFTWARECitrixAuthManager 
Name: ProtocolOrder
Type: REG_MULTI_SZ
Data: httpbasic integratedwindows [Put these on separate lines]

ProtocolOrder Via REG ADD Command:
REG ADD "HKLMSoftwareCitrixAuthmanager" /f /v ProtocolOrder /t REG_MULTI_SZ /d "httpbasic�integratedwindows"

The ProtocolOrder specifices integratedwindows in order to accomodate for other Stores which might not be configured to use HTTP Basic, to maximize Receiver interoperability in various scenarios.

Note the “�” this is necessary to put the values on separate lines when using REG ADD.

Credit for this resolution goes to our esteemed Citrix Consulting Services colleague John Bredehoeft.

Subscribe