Jump to content
Welcome to our new Citrix community!

Setup a Deny Authorization Policy for members of a specific AD group

Shane Paul

Recommended Posts

I have a situation where I need to deny access to login in remotely for users who are in a specific Active Directory security group. Correct me if I'm wrong, but I think I need to create an Authorization Policy, set the Action to Deny, then create an appropriate expression to do this. Once the Authorization policy is created, I'd then create a AAA Group with the same name as the AD security group and bind the Authorization policy to it. 


My ask is this... I need help in figuring out the proper syntax for the Expression in the Authorization policy. I've tried "AAA.USER.IS_MEMBER_OF("Deny_External_Access") but keep getting errors when I click, on OK. 


Any help is greatly appreciated. 



Link to comment
Share on other sites

Thanks for the quick response Carl. It's helpful to know that I need a classic expression to accomplish this. Any pointers on the proper syntax for the classic expression? And were my thoughts on track with binding this policy, once created properly to the AAA group? Thanks!

Link to comment
Share on other sites

1) If you use an AUTHORIZATION policy bound to the AAA GROUP, then you were mostly right.

Create AAA Group with same name as Group in AD (Example:  RestrictedUsers)

Create Deny authorization policy with classic or advanced expression ns_true/true to affect all users of that group. If there is a condition, like only deny these users when they request a sepcific subnet, then you would use a conditional expression:

Ex 1a (classic):  autho_denyall_cl:  DENY:  ns_true

Ex 1b (advanced):  auto_denyall_adv:  DENY:  true 

Bind the authorization policy to the AAA group.


After authentication, members of this group will be denied authorization and unable to access whatever resource you specified via vpn vserver/gateway/aaa.

Use all classic or all advanced to avoid issues.


2) If you want to use the ADVANCED engine http.req.user.is_member_of("...") or the AAA.user.is_member_of expression, then the approach is different.

Create a session policy and bind it to the vpn vserver (for example), and then use this expression to trigger when the user is a member of a specific group for DENY (or not a member of a specific group to receive an allow authorization):


Assuming you have a global default deny for vpn, then you only need the allow permissions.  But either way is:

Ex 2a: session_pol_deny_restrictedusers:  Profile needs the default authorization set to DENY; expression could then be:  HTTP.REQ.USER.IS_MEMBER_OF("RestrictedUsers")

Ex2b:  session_pol_allowall_butrestrictedusers:  Profile would point to ALLOW authorization:  and expression would be !http.req.users.is_member_of("RestrictedUsers") -- but this is problematic as being very permissive depending on context.  So, the deny above is preferred (in 2a).


It allows you to bind policies at the vpn vserver level; but filter on group membership.  As opposed the first example, which determines authorization settings by group membership regardless of which vpn vserver you hit.  


However, both of these methods process post authentication. Authentication confirms users credentials are good and authe succeeds. Then Authorization is processed and denied. Depending on your gateway setup, this could look like a vpn connection establishes but no traffic flows.  For ICA Proxy, you would be denied access to storefront and get some sort of denied/503 i think  in the gateway.


3) If you want to stop the members of the group from getting past authentication at all, then there are a couple of ways to do this:

3.1:  Adjust the scope of authentication policy by Base DN or Search filter to exclude members of a certain group.  You'll have to look up the right ldap filter for that.


3.2:  Use the session profile again, and in the Security > Advanced settings tab, there is an authorization allowed groups field. You can list multiple groups there and if a user is not in the group specified they fail AUTHENTICATION (not authorization). But clearly more difficult with lots of allowed groups and only one denied groups.


3.3:  If using nfactor policies, you might be able to use the nfactor policy and do a false authentication flow, if a user is a member of a specific group... 

https://support.citrix.com/article/CTX220793 The first part of this single factor vs two factor example, starts with a group extraction policy. Then once you know which group your user belongs to you would have one flow that allowed them to authentication and the other flow for the RestrictedUsers group ending with some sort of authentication policy which is always "false" and never true. If you don't want to do a authorization/quarantine behavior.




  • Like 1
Link to comment
Share on other sites

  • 4 months later...

Shane, Carl was indicating that your radio button said "Classic Policy" but you described an Advanced policy.

Easiest is to select "Advanced Policy" instead and use your expression.

It is always best to use Advanced policies and expressions where you can because Classic is deprecated and is intended to be removed in the future.

(Older releases don't accept Advanced everywhere, so you might be forced to use Classic in such a case. Realize also that some features that use Classic are replaced with other features that use Advanced. That goes, for example, for some AAA and Gateway features. Also for Content Filtering.)

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...