RADIUS authentication and backend group membership

You need to set up the groups on the backend on the RADIUS server. UTM will just send the request to the Radius server, and that server will figure out the request based on which service it's trying to use. To my knowledge, this is something you'd want handled on the radius server anyways so that you can change groups on the radius server and have it update instantly, versus an AD binding which would need to be refreshed manually or on an interval. 

If you're using Windows Server as the AD/RADIUS, you'd set up different network access policies on the server side and depending on which NAS Identification to pull a different user group(s) from AD. 

This link has been very helpful to me:

https://community.sophos.com/kb/pl-pl/115050

Good luck!

Services are not a problem: as that article says, the incoming Access-Request has a NAS-Port-Identifier saying what service the user is trying to access.

It is to do with firewall rules and reachability of the network.

For example: with LDAP I can create a UTM group (linked to an LDAP group) which has access to particular parts of the internal network. Depending on what LDAP group a user is in, they will be in a different UTM group and thus able to reach different parts of the network.

There's no equivalent approach with RADIUS that I can see.

Sorry, I'm a bit new at this, so maybe I misunderstood your question. This is the setup I have, maybe this isn't what you're trying to accomplish. 

I currently have my UTM9 device configured to do the following. 

One Radius client linked to the radius server (with one authentication server on the UTM). From there, I have two policies on the RADIUS server. One is for webadmin, one is for VPN access. On the radius server, each policy is linked to a network access policy, which in turn authenticates with a specific user group in windows AD. 

So, Group A of users can access via radius to the VPN, Group B access the webadmin (and still authenticate via Radius). Same radius server, same radius client, different network policy access group. 

Sorry if I misunderstood your question.

-

EDIT: I just re-read your original post... I see you're trying to restrict individual network access as opposed to services on the UTM itself. My bad. 

Sorry, I'm a bit new at this, so maybe I misunderstood your question. This is the setup I have, maybe this isn't what you're trying to accomplish. 

I currently have my UTM9 device configured to do the following. 

One Radius client linked to the radius server (with one authentication server on the UTM). From there, I have two policies on the RADIUS server. One is for webadmin, one is for VPN access. On the radius server, each policy is linked to a network access policy, which in turn authenticates with a specific user group in windows AD. 

So, Group A of users can access via radius to the VPN, Group B access the webadmin (and still authenticate via Radius). Same radius server, same radius client, different network policy access group. 

Sorry if I misunderstood your question.

-

EDIT: I just re-read your original post... I see you're trying to restrict individual network access as opposed to services on the UTM itself. My bad. 

So what I want is:

* Group A and Group B can both access the VPN

* When connected to the VPN, Group A can ping 10.10.0.0/16 and Group B can ping 10.20.0.0/16

This is straightforward to do with LDAP groups, but does not appear to be possible with RADIUS authentication.  And you can't combine RADIUS authentication with LDAP group membership as far as I can see.

Regards,

Brian.

I understand the issue now... my apologies...

Following this in case anyone else has this type of issue. I'm too new with UTM9 to know of any other viable workarounds. Sorry again for the confusion. 

Hi, Brian, and welcome to the UTM Community!

I can see that you're new to the UTM and I sense your frustration.  In fact, your last post is the right one to ask here as it clearly describes your needs instead of the solution you were fighting.

The requirement for two different accesses is best done with SSL VPN or IPsec Remote Access.  PPTP and L2TP/IPsec both require too much mucking about although it is possible to accomplish what you want with them.

My choice would be the SSL VPN as the clients are free and the Profiles are additive.  By that, I mean that a user, like an administrator, in both Group A and Group B can get access to both Profiles and thus to both subnets.  Just choose 'Automatic firewall rules' and you're home free!  This does preclude RADIUS, but you can use AD or LDAP.

The only places I use RADIUS are for L2TP/IPsec and PPTP in small offices that don't have sophisticated needs.  Even then, I urge them towards the SSL VPN solution.

The other place I use RADIUS is in Wireless Protection for WPA2 Enterprise.

Cheers - Bob

> The requirement for two different accesses is best done with SSL VPN or IPsec Remote Access.  PPTP and L2TP/IPsec both require too much mucking about although it is possible to accomplish what you want with them.

Actually, I didn't ask anything about different VPN technologies.  I have SSL VPN working perfectly well thanks (e.g. using Tunnelblick as the client for OSX).

What I was asking about was group authorization in RADIUS, but it seems I was still not clear. I'll try one last time.

* Users in group A should be able to connect to SSL VPN and be granted access to network 10.10.0.0/16

* Users in group B should be able to connect to SSL VPN and be granted access to network 10.20.0.0/16

* This works fine if I use *LDAP* as the authentication backend, since I can create UTM groups which are linked to LDAP groups, and set different "Local Networks" for different groups.

* However I cannot make it work this way using *RADIUS* as the authentication backend.

As far as I can tell, UTM treats all users in RADIUS identically. It seems to be a limitation of RADIUS authentication in UTM.  You can create a backend group called "RADIUS users" but it contains all users who authenticate via RADIUS. 

Therefore I can configure UTM so that *all* RADIUS users to have access to both 10.10.0.0/16 and 10.20.0.0/16, but not some users to have access to one network and some users to the other.

As far as I can tell, you cannot return an authorization attribute in the Access-Accept reply which says which group(s) the user is in - whereas in LDAP you can apply a test, e.g. that the memberOf attribute has a specific value. And I also don't think UTM lets you use RADIUS for authentication together with an LDAP query for group membership.  If you want to use LDAP for group membership then you have to use an LDAP "simple bind" to validate their password as well, so you're limited to what authentication methods your LDAP server supports.

Please correct me if I'm wrong!

Thanks,

Brian.

Authentication and group membership are two completely separate mechanisms.  There is no ability to attach anything with Remote Authentication.

The other items associated to a user for the UTM are only available to the UTM if the user was synced so that there's a user object on the UTM.  That doesn't include group membership.

With RADIUS, there is only the question of what the RADIUS server says which RAS methods the user can access and that's either on or off for SSL VPN, PPTP and L2TP/IPsec.  The best you can do with RADIUS is give different users different access methods and limit each method to particular subnets with firewall rules.

The UTM doesn't know that RADIUS is using LDAP/AD information to make its decision of allowed or not, I doubt that one could use a Backend Group with a RADIUS-authed user, but I've never heard of anyone trying it.  I expect that the users could be synced to the UTM and then those users objects placed individually in a local (not Backend) Users Group.

Your initial idea isn't how WebAdmin works.  If this is a home-use situation, you might be able to make changes at the command line, but you would need to re-do them after every reboot.  WebAdmin is a GUI that manipulates databases of objects and settings.  A single change there can cause the Configuration Daemon to rewrite hundreds of lines of the code used to run the UTM.

Cheers - Bob