Re: Update Reply returns noop

25 Jul 2016

      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>