I will probably create my own dictionary with custom made attributes for these, thank you. There are multiple ifs to give me more control, and each of the contains a "else" to reject all that does not match. The first "if" is the only one that doesn't have a catch-all "else" yet, as I am still testing the cascade. With all these responses however, we still have not adressed the fact that the update reply in my first "if" returns noop and therefore does not stop processing right then and there. Am I wrong to assume that since the reply is acted upon it should not return noop? This is what all my other if/else conditionals are already doing. Instead I get a reject from a "else" further down the conditionals. Thanks, AG On Mon, Jul 25, 2016 at 5:39 PM Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Mon, Jul 25, 2016 at 03:04:21PM +0000, Anastasios Gryponisiotis wrote:
What I am trying to achieve, and have so far been sucesfull, is to have groups of users and NAS groups (using regex). I then use unlang to create conditionals in order to accept/reject/update reply items accordingly.
I use this to specify different access levels using Cisco-AV-Pair values and to allow users of some groups to access some NASes and not others. This is all running in post_auth and works fine.
Anything that is not matching withing the if conditionals is trickled down to a "catch-all" else that rejects the request.
That's a much more useful explanation.
Now I want some of these users to also be able to access VPNs to specific sites. So I am trying to use a Reply item of "Realm" to match the NAS-Identifier of the VPN endpoints. Unfortunately, even though the
Realm and NAS-Identifier are normally in the request, so this is a bit of an odd use-case, but OK.
You can create your own attributes for this sort of thing if you want.
I'd put them in the control list rather than the reply so that they never get sent back to the client.
conditional matched this, it returns noop, therefore evaluation is continuing to match another conditional, until it is rejected by the "catch-all" else statement at the end.
Well, if you want to reject there, then adding "reject" is a perfectly acceptable way to do it.
Otherwise I would probably look at options involving another attribute or two that set whether the user should be rejected or not, then reject based on that.
So you could create new attributes, Reject-Switch and Reject-VPN, then do something like
update control { Reject-Switch := 1 Reject-VPN := 1 }
if (...) { # set of if to see if user is OK on switch
update control { Reject-Switch := 0 } }
if (...) { # set of if to see if user is OK on vpn
update control { Reject-VPN := 0 } }
if (&control:Reject-VPN || &control:Reject-Switch) { reject }
That should pull the logic apart and make it easier to control what is happening along the way.
When you end up with a
if (a) { .. } elsif (b) { .. } elsif (c) { .. } else { reject }
it makes it very hard sometimes to not hit the reject at the end as you get further down the list of ifs and something is OK if it's a and c but not b, for example.
Matthew
-- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk>
Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html