How to differentiate between vpn user and appliance user?

D C dc12078 at gmail.com
Sun Jul 26 00:48:52 CEST 2015


On Fri, Jul 24, 2015 at 10:03 AM, Alan DeKok <aland at deployingradius.com>
wrote:

> On Jul 24, 2015, at 8:52 AM, D C <dc12078 at gmail.com> wrote:
> >> I've configured post-auth  and the users file in such a way that I can
> log
> >> into devices with my ldap credentials ONLY if I am a member of one of 2
> >> groups.  My reply-item attributes are stored in ldap within the group,
> and
> >> all that is working great.  Valid users who are not members of these
> >> defined groups get rejected.  perfect.
>
>   That's good.
>
> >> Now the tricky part.  I have a third ldap group that i want to use in
> >> order to assign vpn access to people. so some users may be members of
> only
> >> the vpn group, and some maybe members of the superadmin group as well as
> >> the vpn group.  This causes two problems.
> >>
> >> 1) If I add allow the vpn group, then vpn users will be able to login to
> >> network equipment which is definitely not desired.
>
>   Then allow the VPN group only if they're using the VPN services.
>
>   How does the RADIUS server know they're using VPN services?  Run it in
> debugging mode, and see what the output is.
>
> >> 2) I don't currently have any way to determine within radius if a user
> is
> >> trying to login to the vpn, or if they are trying to ssh to my firewall.
>
>   Read the debug output.  If users login to the VPN and send packet X, and
> login to the firewall and send packet Y... the two packets are different.
> You can key off of those differences to set the different policies.
>
>   If the two packets are identical, then it's *impossible* to run
> different services.  Because FreeRADIUS can't tell that they're different
> services.
>
> >> I'm not really sure what I should do to work around this.  My only idea
> >> I've come up with (which I don't like), is to have my firewall set a
> >> different NAS-ip for the vpn users.  If that is different, then I
> imagine I
> >> can probably write some login in post-auth to handle it.  Is there a
> better
> >> way to do this.
>
>   That's the way to do it.


> >> The radius configuration on my firewall will let me set the nas-ip,
> >> auth-type, which source ip to communicate with, and which destination
> port
> >> the radius server is listening on.  I've not yet looked into how the
> >> virtual servers work in radius, so maybe I can setup a different port
> and
> >> config for my vpn users to auth against..
> >>
> >>
> >> Using FreeRadius 2.1.12.
>
>   You should really upgrade...
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html



​
So I got it working, kinda.

Thanks to radiusd -X,  I found that my fortigate appliance sends an
attribute in the request called "Connect-Info"  which distinguishes if it's
and vpn login or a admin login.

I can do something like this in post-auth which "works"..( ignore typos,
i'm going off the top of my head here.)
When the user is rejected,  the behaviour i see is that I get one Login OK
message, followed by two login failures.   This is probably because I'm
doing this in post-auth as I've read in other posts.  I know if I do not
allow the ldap group in my users file,  I get a single failure with no
repeat login attempts.

My question is where can I apply this logic besides post-auth, so that I
can handle it before I allow the login?


switch Connect-Info {
  case "vpn-ssl" {
    if ((LDAP-Group == "vpngroup1") || (LDAP-Group == "vpngroup2") ||
(LDAP-Group == "vpngroup3")) {
      ok
    }
    else {
     update reply {
       Reply-Message += "VPN access denied by LDAP group membership."
      }
      reject
    }
  }
  case "admin-login" {
    if ((LDAP-Group == "admingroup1") || (LDAP-Group == "admingroup2")) {
      ok
    }
    else {
     update reply {
       Reply-Message += "Fortinet Admin access denied by LDAP group
membership."
      }
      reject
    }
  }
  case {
    update reply {
     Reply-Message += "Unknown Connect-Info value.  Go away."
    }
    reject
  }
}


More information about the Freeradius-Users mailing list