Jump to content
Welcome to our new Citrix community!

Different RADIUS servers by user group

Nick Brown

Recommended Posts

I've currently got a vserver with LDAP policy as the primary authentication and RADIUS policy as secondary. I want to have a group of users that use a different RADIUS server (we're migrating to a new system). I can add a 2nd RADIUS policy with a higher priority, but I need that 2nd policy to be targeted to my specific group only*.


I thought I could use a "user ismemberof AAA group" type expression when binding my 2nd RADIUS policy to the authentication server (I have LDAP as my primary auth, so this seems feasible), but I'm beginning to think that's possible for authorization, not authentication.


Is what I'm trying to achieve possible? Is so, how? 


Thanks in advance.



* [Edit] Or do I? If I add multiple RADIUS polices (all as secondary auth) do they all need to authenticate successfully, or just one of them?

Edited by NickBrown1968
Link to comment
Share on other sites

Hey Nick,


it works with nFactor but if you don‘t have an advanced adc license you could also try this:

• Create an Citrix Gateway AAA Group, example SecondFactor-Radius1 which is similar to your AD Group
• Create a radius auth server, go to more details and checkout the "Default Authentication Group", fill in SecondFactor-Radius1 again
• Do the same for your other radius group and other radius auth server
• Bind both radius policies to your single gateway with the same priority or 100 / 110 (doesn't matter because now it's filtered by the default authentication group)
• I've done this with LDAPs so I think it should also work with radius, see more informations from Carl: https://www.carlstalhood.com/citrix-gateway-ldap-authentication/#domainsaaagroup 


Let me know how it works


Best Regards


Link to comment
Share on other sites

Just to clarify this is for an Access Gateway virtual server. My concern is nFactor looks pretty convoluted (I only work with Netscalers every few years, so I get a bit rusty).


Maybe I'm making this more complicated than necessary - with basic authentication how are multiple authentication policies in each group (primary/secondary) evaluated? Does every policy in the group have to return success for the auth to be considered successful, or just one of them? I have tried to find the answer to this in the documentation, but it wasn't clear to me.


The reason I ask is because the approach that Julian proposed is one that is often cited for LDAP with multiple authentication domains. If I understand correctly this scenario works by attempting authentication against each LDAP/domain in turn, with the "Default Authentication Group" value of the successful authentication policy then used to link to an AAA group (which can be then be used in session policy expressions). What I infer from this is that only one of the authentication policies (in each group/type) needs to be successful in order for authentication to be considered successful. Is that so?


So can't I just bind both of my RADIUS policies and, for any particular user, one policy will successfully authenticate them, whilst the other will fail. Thanks again for your input.


Regards, Nick.



Link to comment
Share on other sites

2 hours ago, Nick Brown said:

Maybe I'm making this more complicated than necessary - with basic authentication how are multiple authentication policies in each group (primary/secondary) evaluated? Does every policy in the group have to return success for the auth to be considered successful, or just one of them? I have tried to find the answer to this in the documentation, but it wasn't clear to me.


Classic policies/basic authentication: 

If multiple policies are in the same bind point (aka primary) it is a cascade or an OR condition. Any one and only one authentication policy must succeed. First matching policy and then out. If first bound policy fails, then second is attempted and so on. If first policy works, no other policies are tried.


If policies in both primary and secondary bind point, then this is two-factor:  one policy in primary bind point AND one policy in secondary bind point must succeed.








Results: requires ((domainA or Domain B) AND Radius) to be successful

So yes, you could bind multiple radius policies instead in the secondary bank and have it try until one works (but see concerns below.)


The problem you have is that you can't trigger classic policy conditions based on group membership. And things like domain drop down lists (or a radius choice) would be much harder to manage in the classic engine vs. nfactor/advanced engine. Also, you can't easily do single factor for some and two-factor for others in the classic engine (which you can do in advanced.  Policy order is dictated by bind point and then priority within the bind point.


The only concern you have if you bind radius1 and radius2 and let the system figure out which one succeeds, is that any radius2 user will always be tried against radius1 first.  If there is a chance of overlapping accounts, could your radius2 users "lock"  accounts in the radius1 system?  This is why conditional authentication can be useful.


You can still bind session policies based on AAA group membership or by the authentication group assigned by the successful authentication policy.


The downside to the classic engine is that it will be deprecated post 13.0 and you will have to change the setup anyway. If you're going to do a new implementation, I would go ahead and do the nfactor config if your licensing supports it so you don't have to do this again.


Maybe this explanation will help....


Now about advanced/nfactor and triggering policies based on group membership.

This example shows how to create a group extraction (ldap) policy who's job is to ask for username only; submit to domain and retrieve group membership, so later authentication policies can apply based on group membership.  https://support.citrix.com/article/CTX220793  (Shows how to trigger a domain only for groupA and domainA/Radius for groupB users...this can be adapted to pivot between different radius policies instead of the usual multi-domain; you could even use one of the domain drop down list examples to make a "radius" drop down instead.)  But if you build this one as is, you may see how to adapt it for your own scenario. This is a good reference example.


Nfactor would make it easier to combine authentication scenarios behind one access point and trigger only the ldap/radius combos you want based on the original group assessment.


With nfactor, you define a login schema (which is the part of the login interface to display at each phase).

The policies on the vpn vserver are the "first factor" policies. If multiple policies are bound, they will act as a cascade and attempt in the order specified by priority (and expressions) and only one needs to be successful. If any policy points to a next factor (aka an advanced policy label), then this policy has a "secondary" condition to meet.  The policy label (next factor) gets its own interface (loginschema) to present and has either a single policy bound or multiple policies bound. If they have any "next factor" specified, then you move to your tertiary condition...


Any policy at the same bind point/level is in a cascade (OR condition) like multiple policies bound in the classic engine "primary" bank.

Any policy with a next factor specified, is now in an AND condition with the previous factor. So your first factor AND next factor must both pass to succeed.  (And any  subsequent next factors will be evaluated so you can daisy chain as deep as you want).  The next factor acts as a custom/conditional "secondary" bind point if you compare it to the classic engine.














Link to comment
Share on other sites

  • 1 year later...

Hi Nick


i know this is an old topic but did you have any luck processing the Radius authentication by membership of an AD Group?

i have an Netscaler with standard license but if this can be done with nFactor i would like to know how that is done, it could warrant an upgrade if this cant be done on Netscaler with standard license.





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