(Note: See end of post for a correction).
A colleague reached out to me yesterday with two Citrix cloud issues. We use Azure AD and he was having trouble with groups.
1: He granted access to a Delivery Group to an AD group. Even after the AD group synced to Azure AD users were not seeing the new apps when they do a refresh. If he were to add the users directly to the Delivery Group they see the changes immediately.
2: The group he is adding to the Delivery Group has some nested groups. Adding users to any of these nested groups doesn’t work either. Not surprising, since adding to the group directly doesn’t seem to have an effect; but he wanted to know if nested groups would work or not.
I fired up a browser, launched the SAML Tracer extension (link for Firefox; similar versions exist for other browsers too), and logged in to Citrix Cloud.
If you look through its output there’s a POST step in yellow where Azure AD sends the results of the authentication process to https://accounts.cloud.com. (You authentication with Azure AD, it tells Citrix Cloud if you authenticated successfully or not and sends a bunch of claims if you did, and the rest is up to Citrix Cloud. This yellow POST is where that happens).
In the Parameters tab of this POST entry is the id_token.
You can read about id_tokens at this link for instance. They are Important Stuff when it comes to Azure AD/ OAuth authentication so that’s why I went ahead and captured them. To quote from the page I linked to:
ID tokens are issued by the authorization server and contain claims that carry information about the user. They can be sent alongside or instead of an access token. Information in ID Tokens allows the client to verify that a user is who they claim to be. ID tokens are intended to be understood by third-party applications. ID tokens should not be used for authorization purposes. Access tokens are used for authorization.
id_tokens are basically how Citrix Cloud knows more about you the user who are signing in.
I copied the token (everything after id_token:) – it looks like gibberish, but is actually a JWT (JSON Web Token) which can be decoded – and pasted into a JWT decoder site such as https://jwt.ms (an alternative is https://jwt.io/). This shows me all the claims, and as you can see it sends the groups claims too.
But here’s the nub of the matter. Citrix Cloud is only sent these claims every time you login. So if you were to add yourself to a new group and simply refresh you Citrix Cloud page, Citrix won’t be aware of these new groups. If you were to add yourself to a Delivery Group directly then Citrix Cloud can see you now have access because all it looks at is your username… but that’s not the case when it comes to groups. I thus asked me colleague to log out and login, and sure enough now he could see the new apps available to the Delivery Group his AD group had access to.
So that answers the first question.
For the second question I repeated the id_token decoding before and after adding him to a nested group. As expected Azure AD does send the name of the parent group in the claims… but Citrix Cloud seems to ignore it. Which makes no sense! 🤷♂️ So I did what I should have done in the first place… I Googled it. 🙂 And found this article which has the following warning in the Azure AD section:
Adding a group as a member of another group (nesting) is not supported for federated authentication 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 that’s that. Nested groups are not supported, even though Azure AD seems to send the claims over.
Update (26 Jan 2023): Turns out I was mistaken and this mistake resulted in a lot of wasted hours troubleshooting today. 😞 Turns out Citrix Cloud doesn’t use Azure AD groups in claims. Rather it talks to AD directly. Follow-up blog post here.
Also, looks like nested groups are now supported.
