In the last year we’ve really seen an uptake in the number of Citrix Cloud customers using Citrix Workspace with Azure Active Directory authentication enabled, to enforce multi-factor authentication logon to their Citrix Workspace environment. Typically, if a customer is moving to Citrix Cloud but didn’t previously have any multi-factor authentication solution deployed – they are taking the opportunity that migrating to Citrix Cloud brings to implement more secure user authentication and authorization.
In order ensure SSO (single sign on) to published apps and desktops, when using Azure AD as an identity provider – Citrix administrators would have also deployed Federated Authentication Service for Citrix Cloud (Citrix FAS).
Citrix FAS uses SAML authentication for exchanging authentication and authorization data between an identity provider and a service provider – in this case between Azure Active Directory and Citrix Workspace. If you’re new to Citrix FAS and what it’s all about or how to deploy it – there’s plenty of excellent knowledge base articles already covering the topic in detail.
Put simply, if you’re using Citrix Workspace with Azure AD as an identity provider you must implement Citrix FAS – otherwise when end users launch a published application or desktop they’ll get the dreaded O/S logon window looking for domain credentials before the app/desktop will launch.
Consider the following scenario:
You’ve configured a brand-new Citrix Workspace environment with Azure AD authentication and configured Citrix FAS to ensure SSO to published resources. Perhaps you are migrating from an on-premise Citrix farm and you’ve republished all your apps / desktops in Citrix Workspace using the same Active Directory security groups as your on-premise environment. Initial testing of Workspace environment looks good with published apps launching with single sign on. However, some end users start to report that published apps that used to appear in the on prem StoreFront and are not appearing in Citrix Workspace. You investigate and scratch your head as you exactly replicated the security access groups from the on-premise environment.
So why is it not working?
Here’s the gotcha:
Adding a group as member of another group (nesting) is not supported for federated authentication when using Azure AD. If you do assign a nested group to a catalog, members of that group can’t access apps from the catalog.
So, what does this mean exactly?
Take a simple example:
You published an app to AD security group named: All_Users
The make-up of All_Users security group looks like:
- User_A
- User_B
- User_C
- Finance_Users (security group)
- HR_Users (security group)
In this instance, Finance_Users and HR_Users are nested security groups (within All_Users) and Citrix FAS cannot enumerate resources for the users in those groups. Users A, B and C can see the published resource without issue. To resolve you will need to publish the application directly to Finance_Users and HR_Users.
But what if you have dozens or even hundreds of apps. Will you have time to check each security group published to each app and then check to see if that security group has nested groups? And what if the nested security group also has additional nested security groups. Sounds like a black hole for time. PowerShell can ease your pain. Use the below scripts to check all published apps / desktops in your Citrix Cloud deployment and check for nested security groups.
Note: to use the below scripts you’ll need Citrix PowerShell SDK for Citrix Cloud installed as well as Active Directory module for PowerShell.
Step 1
Authenticate to your Citrix Cloud instance from PowerShell:
Step 2
Run the following PowerShell script (Get-NestedGroups.ps1) to create a function that will be called by the next script to search for nested security groups.
Note: this script will return no output when run.
$GroupList = @{}
Function Get-NestedGroups
{
Param
(
[string]$GroupName
)
$Groups = Get-ADGroup -identity $GroupName | Get-ADGroupMember | `
Where-Object ObjectClass -eq "group" | `
Select-Object name, samaccountname, distinguishedName
$Groups2 = Get-ADGroup -identity $GroupName
foreach ($Group in $Groups) {
if ($GroupList.Values -notcontains $group.name) {
$Group | Select-Object @{Name="Group";E={$Groups2.Name}}, @{Name="NestedGroup";E={$Group.Name}}
$GroupList.add($Group.name,$Group.name)
Get-NestedGroups -GroupName $Group.distinguishedName
}
}
}
Step 3
Run the following script (Citrix_GroupPermission.ps1) to check all your published apps / desktops and return a list of nested security groups for each app (if they exist). Note: the script will only return entries for those apps that do have nested security groups published to them.
$Apps = Get-BrokerApplication
Foreach ($i in $Apps)
{
Where-Object { $i.AssociatedUserNames } | `
ForEach-Object {$Name = $_.Name ;$_.AssociatedUserNames | `
Select-Object @{N="AssociatedUserNames";E={$_ } }, @{N="Name";E={$Name}} }
foreach ($App in $i.associatedUserNames -replace '.*\\',''){
$APPGroups = Get-ADObject -Filter {(Name -like $App ) -and (ObjectClass -like "group")} | `
Select-Object Name, @{N="CitrixAPP";E={$i.Name} }, distinguishedName
foreach ($APPGroup in $APPGroups) {
$GroupList = @{}
Get-NestedGroups -GroupName $APPGroup.distinguishedName |
Select-Object @{N="CitrixApp";E={$APPGroup.CitrixAPP}}, Group, NestedGroup
}
}
}
In my example – the script returns the following results:
CitrixApp – refers to the published app or desktop in Citrix Cloud
Group – refers to the parent group to which the app / desktop is published
NestedGroup – refers to a nested group that resides within the parent group
Here we can see that the security group All_******* has 4 nested security groups (i.e. Sales, Technical, Finance and HR).
And group XenApp_RDP has 2 nested security groups (i.e. Technical and Finance)
Step 4
From above example – if I want to resolve the issue for published app Remote Desktop, I need to run the following PowerShell commands to update the published app security groups:
Using the last command in above screenshot – I can now see that Technical and Finance user groups are now added to the root security groups to which the application is published. Users in those groups will now see the published app when logging on to Citrix Workspace with their Azure AD credentials.
Hopefully this post will be of benefit to anyone who finds themselves in the same position with Citrix Cloud & FAS.
Big thanks for Bruno Gomes for his work on and assistance with these PowerShell scripts.
Well Done Bruno 🙂