Re: How to differentiate between vpn user and appliance user?
On Fri, Jul 24, 2015 at 8:02 AM, D C <dc12078@gmail.com> wrote:
I recently configured a radius server with openldap backend to handle central auth for all my network equipment. The ldap module is using "radiusGroupName" as my groupmembership_attribute.
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.
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.
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.
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.
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.
Sorry for re posting, I just realized I never set a subject...
On Jul 24, 2015, at 8:52 AM, D C <dc12078@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.
On Fri, Jul 24, 2015 at 10:03 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 24, 2015, at 8:52 AM, D C <dc12078@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 } }
On Jul 25, 2015, at 6:48 PM, D C <dc12078@gmail.com> wrote:
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.
That's why we recommend reading the debug output. :)
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?
You can put it into the "authorize" section. Generally, you want to reject "bad" users as early as possible. This means using the "authorize" section.
switch Connect-Info { ...
All that looks fine. Just move it to the "authorize" section. Alan DeKok.
Ah ok, I tried authenticate with no luck. Now I'm using authorize, but still having the same issue. It looks like the ldap module is authorizing the request, so even now I am still too late in the pipeline. Here is my config with comments removed, and the output of radiusd -X from just "one" login attempt. I am expecting it to fail because my vpn user is not authorized for an admin login. However, I am getting 3x login attempts which i believe is because ldap bind authorized it. http://pastebin.com/raw.php?i=UPt435VX http://pastebin.com/raw.php?i=2atLPQxv any thoughts? Thanks, Dan On Sun, Jul 26, 2015 at 7:35 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 25, 2015, at 6:48 PM, D C <dc12078@gmail.com> wrote:
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.
That's why we recommend reading the debug output. :)
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?
You can put it into the "authorize" section.
Generally, you want to reject "bad" users as early as possible. This means using the "authorize" section.
switch Connect-Info { ...
All that looks fine. Just move it to the "authorize" section.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Ah ok, I tried authenticate with no luck. Now I'm using authorize, but still having the same issue. It looks like the ldap module is authorizing the request, so even now I am still too late in the pipeline.
you're making this more complex..... just check if the Connect-Info is there and what value is it...and if its there then send the request to a new virtual server based on the value it is. this completely seperates the policy requirements for authentication. one virtual-server deals with admin logins (very easy), the other deals with user logins (very easy). instead, you are trying to put all requirements into a single virtual-server which will need all sorts of extra LDAP checks and changes (not so easy). alan
I don't think that what I'm trying to do is complex at all. I shouldn't need any additional ldap changes, all the information needed is already present. I may consider the vhosts at some point if this gets any further complications. If anything just to "help" safe guard from configuration mistakes. Thanks, Dan On Mon, Jul 27, 2015 at 4:08 AM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Ah ok, I tried authenticate with no luck. Now I'm using authorize, but still having the same issue. It looks like the ldap module is authorizing the request, so even now I am still too late in the pipeline.
you're making this more complex..... just check if the Connect-Info is there and what value is it...and if its there then send the request to a new virtual server based on the value it is. this completely seperates the policy requirements for authentication. one virtual-server deals with admin logins (very easy), the other deals with user logins (very easy). instead, you are trying to put all requirements into a single virtual-server which will need all sorts of extra LDAP checks and changes (not so easy).
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 26, 2015, at 3:01 PM, D C <dc12078@gmail.com> wrote:
Ah ok, I tried authenticate with no luck. Now I'm using authorize, but still having the same issue. It looks like the ldap module is authorizing the request, so even now I am still too late in the pipeline.
Most of the "ldap" lines are it doing the LDAP-Group checks.
Here is my config with comments removed, and the output of radiusd -X from just "one" login attempt. I am expecting it to fail because my vpn user is not authorized for an admin login. However, I am getting 3x login attempts which i believe is because ldap bind authorized it.
You've changed the unlang rules you posted before. Why? As an example, what do you expect this to do? switch Connect-Info { case "vpn-ssl" { if ((LDAP-Group == "superAdmins-VPN") || (LDAP-Group == "readAdmins-VPN") || (LDAP-Group == "users-VPN")) { update reply { Reply-Message += "VPN access granted by LDAP group membership." } ok } else { update reply { Reply-Message += "VPN access denied by LDAP group membership." } ok } } So... if the LDAP group *doesn't* match, you have it do "ok", instead of "reject". Why? Alan DeKok.
I was trying to keep the vpn logic separate from everything else. So first I handle my firewall which sends the Connect-Info attribute. If Connect-Info is vpn-ssl, then it's a vpn login, and I want only members of my vpn groups to be allowed. Next I do the same logic for my admin logins. The case (!Connect-Info) section handles the rest of my network devices, where I want all my admins to have access based on their profile. I was testing profiles with a superadmins-VPN user but didn't get that working, which is why i didn't attempt to add a profile to the others yet. For profiles I haven't got that working so far unless I specify it in the users file. I haven't don't any research on it yet, so I didn't bother asking about it here yet. As for the authorize issue I'm having, I'm leaning towards the problem being on the firewall right now. I swapped out my sites-enabled/default for the original one before I made any changes, and then just uncommented the lamuser auth-type reject clause from the users file. If I try to login as lameuser, I still get 3x failed logins. I will take this up with the firewall team and see if they have some kind of retry logic going on. Thank you Alan, you have been most helpful throughout this. On Mon, Jul 27, 2015 at 7:07 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 26, 2015, at 3:01 PM, D C <dc12078@gmail.com> wrote:
Ah ok, I tried authenticate with no luck. Now I'm using authorize, but still having the same issue. It looks like the ldap module is authorizing the request, so even now I am still too late in the pipeline.
Most of the "ldap" lines are it doing the LDAP-Group checks.
Here is my config with comments removed, and the output of radiusd -X from just "one" login attempt. I am expecting it to fail because my vpn user is not authorized for an admin login. However, I am getting 3x login attempts which i believe is because ldap bind authorized it.
You've changed the unlang rules you posted before. Why?
As an example, what do you expect this to do?
switch Connect-Info { case "vpn-ssl" { if ((LDAP-Group == "superAdmins-VPN") || (LDAP-Group == "readAdmins-VPN") || (LDAP-Group == "users-VPN")) { update reply { Reply-Message += "VPN access granted by LDAP group membership." } ok } else { update reply { Reply-Message += "VPN access denied by LDAP group membership." } ok } }
So... if the LDAP group *doesn't* match, you have it do "ok", instead of "reject". Why?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 27, 2015, at 9:12 AM, D C <dc12078@gmail.com> wrote:
I was trying to keep the vpn logic separate from everything else.
That idea isn't implemented in the policy you wrote.
So first I handle my firewall which sends the Connect-Info attribute. If Connect-Info is vpn-ssl, then it's a vpn login, and I want only members of my vpn groups to be allowed. Next I do the same logic for my admin logins.
That's nice, but you're missing my point. The logic you posted does: a) allow "good" users to be accepted it does NOT do: b) reject "bad" users That's why "bad" users are being accepted. They're seen as bad, and then you have it do "ok", instead of "reject".
As for the authorize issue I'm having, I'm leaning towards the problem being on the firewall right now. I swapped out my sites-enabled/default for the original one before I made any changes, and then just uncommented the lamuser auth-type reject clause from the users file. If I try to login as lameuser, I still get 3x failed logins.
See what the debug output says. The logic should be simple: if (user is trying to do X and LDAP group is not "users who are allowed to do X") { reject } That will allow "good" users to do X, and prevent "bad" users from doing X.
I will take this up with the firewall team and see if they have some kind of retry logic going on.
Thank you Alan, you have been most helpful throughout this.
It's what I do. Alan DeKok.
Ahh ok, i see it now. I've not tested the vpn yet, just the admin login. I've been trying to figure out my 3x login attempts issue before moving forward. Your absolutely right, I've fixed that now. Thanks, Dan On Mon, Jul 27, 2015 at 9:43 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 27, 2015, at 9:12 AM, D C <dc12078@gmail.com> wrote:
I was trying to keep the vpn logic separate from everything else.
That idea isn't implemented in the policy you wrote.
So first I handle my firewall which sends the Connect-Info attribute. If Connect-Info is vpn-ssl, then it's a vpn login, and I want only members of my vpn groups to be allowed. Next I do the same logic for my admin logins.
That's nice, but you're missing my point. The logic you posted does:
a) allow "good" users to be accepted
it does NOT do:
b) reject "bad" users
That's why "bad" users are being accepted. They're seen as bad, and then you have it do "ok", instead of "reject".
As for the authorize issue I'm having, I'm leaning towards the problem being on the firewall right now. I swapped out my sites-enabled/default for the original one before I made any changes, and then just uncommented the lamuser auth-type reject clause from the users file. If I try to login as lameuser, I still get 3x failed logins.
See what the debug output says.
The logic should be simple:
if (user is trying to do X and LDAP group is not "users who are allowed to do X") { reject }
That will allow "good" users to do X, and prevent "bad" users from doing X.
I will take this up with the firewall team and see if they have some kind of retry logic going on.
Thank you Alan, you have been most helpful throughout this.
It's what I do.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Ahh ok, i see it now. I've not tested the vpn yet, just the admin login. I've been trying to figure out my 3x login attempts issue before moving forward.
run in debug mode.....see where and how the ldap module is being called. for quite a few appliances a dumb 'authorize' request is made before a real login.... you might want to tweak your server to handle such a thing (we do for our CISCO ASA VPNs) alan
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
D C