Jump to content
Welcome to our new Citrix community!

Is it possible to have one Citrix ADC vServer select the published app URL based on group membership? e.g. multiple storefront stores by virtue of AD group?

Recommended Posts

Kowledgeable Geezas ...

With Citrix ADC - the Gateway uses a virtual server which has a binding to the session policy and session profile, In the session profile you enter the URL to the storefront store which is used to enumerate the published apps and desktops - (e.g. from session profile, published applications - Web Interface Address).

But What we need is to determine if the user is in a specific AD group first and then choose from 2 different storefront URLs.

For example

    user A who is in AD group "GroupA" using a browser logs into remote access site - "mycompany.co.uk" - after autheinticating user is redirected to  https://mystorefrontserver/citrix/myStoreA

    user B who is in AD group "GroupB" using a browser logs into remote access site - "mycompany.co.uk" - after autheinticating user is redirected to  https://mystorefrontserver/citrix/myStoreB

Is this possible?


I can see that a session policy security tab has advanced settings to set "Groups Allowed To Login" - but i think it just there to restrict access to resources after authentication

Can this be used to accomplish what i need? Can I do it with an Authorization policy somehow ?

Any suggestions will be appreciated

Many thanks


Link to comment
Share on other sites

You would create AAA groups whose names exactly match those of "GroupA" and "GroupB" (the names are case-sensitive).

You would then bind separate session policies to each AAA group - the policy for GroupA would have mysiteWebGroupA in its session profile, and the policy for GroupB would have mysiteWebGroupB.

  • Like 1
Link to comment
Share on other sites

Session policies by group (as Sam explained is the ideal way to do this).


And yes you can then have multiple stores behind a single gateway and the gateway directs users based on group.

If you are using advanced policies, you can also just build the group filter into the expression and have the policy bound on the vpn vserver (instead of binding the session policies to the AAA groups). Both methods work. You would then use the policy expressions based on either http.user.is_member_of("<AD group name>") or I think the newer editions favor aaa.user.is_member_of("<AD group name>")  but I don't have a gui in front of me to confirm.


You are correct that the session plicy "Groups Allowed to Login" option actually affects the user authentication and would not be what you want to do for this scenario.  

You can restrict logins by change the authentication policy bind dn, the authentication policy search filter, or using the session policy "allowed to login". Any one not in this list would be denied authentication.   So, not the setting you are looking for.


Link to comment
Share on other sites

Thanks for the replies !

I have tried using AAA groups - it appears to do nothing. I have checked the LDAP policy setup which uses "MemberOf" configuration to enumerate groups

A user who is not in the group "A"  is still getting the first policy applied

Is anything else needed to enable AAA groups ?  I remember in previous netscalers you had to confiure the VServer with some smart mode before this worked but ADCs dont have this option

Link to comment
Share on other sites

Sam's comment about priority is the most likely issue.


Are you using classic or advanced?  I'm assuming advanced to use the is_member_of expression.  But classic expressions (if binding policies to groups, have more complicated priority dependencies)

Add the AD groups to the aaa groups list for the "groups" to be seen, even if using the is_member_of expression and not the policies on groups.

Be sure your LDAP authentication policy is retrieving the memberOf property as well.

Finally, are you getting authentication failures or denied authorizations?  Authe failure


You might want to share your policy bindings for additional help troubleshooting.

You can also view the aaa.debug log during authentication as it will show the authentication call and the group extraction to see if your group name matches what AD returns.


cat /tmp/aaad.debug

# leave running while you perform an authentication and see what events are returned to troubleshoot as well.







Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...