Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Jim_FH
New Contributor III

Forticlient RADIUS server authentication - user groups

Kind of a strange question:

I have two RADIUS servers, and two different user groups defined - one per RADIUS server.

 

I'm wondering if there's a way to prioritize authenticating against one RADIUS server over the other.

 

So, we have a user connect via Forticlient, and authenticate against RADIUS Server1, which puts him/her in Group1. If Server1 is down, then it would authenticate against the Server2 and put the user in a differnt group.

 

I thought I could achieve the desired result via the policies - put the user group from Server1 in a policy above a policy that refers to the user group from Server2, but it seems like authentication is happening round-robin across the RADIUS servers, so it's impossible to predict which server will authenticate.

 

Any ideas how to prefer one over the other?

11 REPLIES 11
emnoc
Esteemed Contributor III

What's listed in the  user_group is the order IIRC,  but outside of placing the two nodes behind VIP , and priority weight-lb or "sloppy"  . I do not see how you can prioritize if your looking for SERVER1 and then SERVER2 & only if  #1 is not available.

 

Qs:

 

Why do you want two different groups tho? Are you looking for a failover or load-share/balance on the two RADIUS-SERVERS?

 

 

FWIW: check out this  new post on my blog with using RADIUS-aaS and the example of a failover approach with FGT. I  did this in the pass and even with a a group of "group-of-servers"

 

http://socpuppet.blogspot.com/2017/03/using-jump-cloud-radius-for-fortimail.html

 

 

We 've use a INSIDE VIP  &  mapped to  2 or more  RADIUS servers(nodes). Under your config real server, you will have to set  weight if you wanted to nail  all connections to a server x.x.x.x over y.y.y.y.

 

 

e.g 

 

 

 

VIP

 

set ldb-method weighted

 

 

realserver

 

NODE_A

set weight 1000

 

NODE_B

set weight 0

 

Ken

 

 

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Jim_FH
New Contributor III

Hi Ken:

 

Interesting about the VIPs.  

 

I guess I don't need two groups, here's what I'm trying to get:

 

RADIUS server1 is a MS MFA server that relays RADIUS requests to a MS NPS server.  This works great, I can authenticate and define different Fortigate user groups based on AD groups using the Fortinet specific RADIUS attribute.  So if it's up and working, I want users to authenticate to RADIUS server1.

 

However, if it's down, I want users to fail to the 2nd RADIUS server, which is just a MS NPS server with NO MFA.  

 

Essentially, I would like the Forticlient users to authenticate via MFA if possible, but if the server is having issues to "fail open" by then authenticating against a non-MFA RADIUS box.

 

thanks,

Jim

 

 

 

 

 

emnoc
Esteemed Contributor III

Can you  place the 2x RADIUS behind a SLB and  weight all radius request and act to server1. If server#1 goes down ( fails health checks ) , authenticate via  server#2.?

 

ideal you should try to get MFA for both servers.

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Jim_FH
New Contributor III

Good idea, I guess i could use a load balancer, but I would hate to add yet another device to the authentication process.

 

I do already have 2xMFA servers that relay authentication to 2xNPS servers.  My thinking is if there is something wrong with the MFA service across both servers, that the authentication would fail to other RADIUS servers (non-MFA), so that it would "fail open."

 

That makes me wonder how authentication is handled when connecting by Forticlient.  Do you authenticate to ONE of the multiple RADIUS servers, or all of them?  I think I'll need to get some packet captures going, and dig through some logs to find out.  

emnoc
Esteemed Contributor III

In my setup we are behind a A10 AX , so we have a priority assigned to the server and service.  We only fail to our 2nd RADIUS instance if the  primary goes down. So it's using a ADC as a "failover"  vrs a load-share. F5 and serverIron all have something similar and in forties the  weight should accomplish that.

 

In this case, we have all controls, logging, audit trails, at the primary and only see the  secondary if it ever becomes priority.

 

If you don't mind what are you using for MFA? We are using  EntrustIdGuard in my  day job but for f5 baggage-clients. I've also used  googauthen but again with non forticlient items.

 

In that jump cloud  blog, I ran a few sites in that same fashion and did a few POC using the 2x radius  instance with a high degree of success.  It worked flawlessly.

 

 

Ken

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Jim_FH
New Contributor III

Hi Ken:

 

We are using Microsoft's Multi-Factor Authentication server running on Windows 2012 r2.

That provides the MFA feature (along with the 'authenticator' app phones).

Those servers relay the authentication requests to a Microsoft NPS server (Win2k12r2), which is where we have different Network Connection policies for different AD groups.  The NPS server then sends back the group membership via a Fortinet-specific RADIUS attribute to the MFA server, which relays it back to the Fortigate.

 

Seems like a lot of moving pieces, but it works well.  

Paul_Fo
New Contributor

Good Morning,

 I see where there is reference to a Fortinet vendor specific attribute being set on the NPS server.  Is there a document for this configuration.  I have been trying for days to get the fortigate > MFA > NPS to work with forticlient but have been unsuccessful.

I get the primary authentication to the mobile device but then it fails with wrong credentials.

 

Jim_FH
New Contributor III

I think this is what I used to get mine working.  I may be able to pull some screenshots from my environment later today.

 

https://travelingpacket.c...-group-authentication/

Paul_Fo
New Contributor

Thanks Jim,  This looks great.  Much appreciated.

Labels
Top Kudoed Authors