I thought it was apparent that the problem is that the module returns noop while it in fact operates on the reply (when reject is added). I would expect a matching if to be acted upon and update the reply as per the unlang, thus doing what it is supposed to do and thus authorizing users matching this. Instead, a noop is returned which results in Access-Reject for these users. Am I wrong in expecting the update of a reply to be effected since the if conditional is in fact true? Thanks in advance, datablitz On Mon, Jul 25, 2016 at 1:08 PM Alan DeKok <aland@deployingradius.com> wrote:

On Jul 25, 2016, at 7:01 AM, Anastasios Gryponisiotis <plant7@gmail.com> wrote:

...

This appears to evaluated correctly, however the update reply module always returns noop:

Why is that a problem?

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Thanks for your quick reply. I did not think I should dump my entire configuration and debug log for this very specific question. That was in consideration for all who would try to help, as I think this is a very specific question I am posing. My problem is that the update is not affected unless i put a reject statement as well. What I am expecting is my update reply statement to update the reply and not return noop, since it would have operated upon the reply. Is this not a clear question? I do not want to frustrate anyone, but you are replying in a very specific way, which shows that you are more interested in being right than helping someone out. I respect your authority in all things FreeRADIUS but surely you cannot expect anyone to be on the same level as you in this mailing list, otherwise there would be no point in having a Users sub-forum.

Thanks Alan, So updating a reply is not considered an operation? I will try the linelog thing and see what I am missing. On Mon, Jul 25, 2016 at 4:32 PM Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:

Hi

You are just setting a reply value? That won't affect reject versus accept unless you have some other unlang etc depending on such a value.

Your update is not affecting the control of the packet so there will be no operation. If in doubt print out the packet using eg linelog straight after your call

alan

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. 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 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. User bsup belongs to group BB, thus reply:Group=BB User bsup also has a reply item set for VPN to SITE1, reply:Realm=VPN-SITE1 In users file: DEFAULT NAS-IP-Address == 1.1.1.1 NAS-Identifier := "VPN-SITE1" IP 1.1.1.1 is the VPN server of SITE1, thus reply:NAS-Identifier=VPN-SITE1 [DEBUG LOG STARTS] rad_recv: Access-Request packet from host 192.168.4.1 port 50070, id=34, length=50 User-Name = "bsup" User-Password = "SAvwxNsqGeaJw" NAS-IP-Address = 1.1.1.1 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bsup", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry DEFAULT at line 51 ++[files] returns ok [sql] expand: %{User-Name} -> bsup [sql] sql_set_user escaped user --> 'bsup' rlm_sql (sql): Reserving sql socket id: 4 [sql] expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'bsup' ORDER BY id [sql] User found in radcheck table [sql] expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'bsup' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'bsup' ORDER BY priority [sql] expand: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'BB' ORDER BY id [sql] User found in group BB [sql] expand: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'BB' ORDER BY id rlm_sql (sql): Released sql socket id: 4 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP # Executing group from file /etc/freeradius/sites-enabled/default +- entering group PAP {...} [pap] login attempt with password "SAvwxNsqGeaJw" [pap] Using clear text password "SAvwxNsqGeaJw" [pap] User authenticated successfully ++[pap] returns ok # Executing section post-auth from file /etc/freeradius/sites-enabled/default +- entering group post-auth {...} [sql] expand: %{User-Name} -> bsup [sql] sql_set_user escaped user --> 'bsup' [sql] expand: %{User-Password} -> SAvwxNsqGeaJw [sql] expand: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') -> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'bsup', 'SAvwxNsqGeaJw', 'Access-Accept', '2016-07-25 16:55:58') rlm_sql (sql) in sql_postauth: query is INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'bsup', 'SAvwxNsqGeaJw', 'Access-Accept', '2016-07-25 16:55:58') rlm_sql (sql): Reserving sql socket id: 3 rlm_sql (sql): Released sql socket id: 3 ++[sql] returns ok ++[exec] returns noop ++? if ("%{reply:NAS-Identifier}" =~ /VPN-/) expand: %{reply:NAS-Identifier} -> VPN-SITE1 ? Evaluating ("%{reply:NAS-Identifier}" =~ /VPN-/) -> TRUE ++? if ("%{reply:NAS-Identifier}" =~ /VPN-/) -> TRUE ++- entering if ("%{reply:NAS-Identifier}" =~ /VPN-/) {...} +++? if ("%{reply:NAS-Identifier}" == "%{reply:Realm}") expand: %{reply:NAS-Identifier} -> VPN-SITE1 expand: %{reply:Realm} -> VPN-SITE1 ? Evaluating ("%{reply:NAS-Identifier}" == "%{reply:Realm}") -> TRUE +++? if ("%{reply:NAS-Identifier}" == "%{reply:Realm}") -> TRUE +++- entering if ("%{reply:NAS-Identifier}" == "%{reply:Realm}") {...} ++++[reply] returns noop +++- if ("%{reply:NAS-Identifier}" == "%{reply:Realm}") returns noop ++- if ("%{reply:NAS-Identifier}" =~ /VPN-/) returns noop ++? if ("%{reply:Group}" == "GOD") expand: %{reply:Group} -> BB ? Evaluating ("%{reply:Group}" == "GOD") -> FALSE ++? if ("%{reply:Group}" == "GOD") -> FALSE ++? if ("%{reply:NAS-Identifier}" == "GOD" && "%{reply:Group}" != "GOD") expand: %{reply:NAS-Identifier} -> VPN-SITE1 ? Evaluating ("%{reply:NAS-Identifier}" == "GOD" ) -> FALSE ? Skipping ("%{reply:Group}" != "GOD") ++? if ("%{reply:NAS-Identifier}" == "GOD" && "%{reply:Group}" != "GOD") -> FALSE ++? if ("%{reply:Group}" == "BB") expand: %{reply:Group} -> BB ? Evaluating ("%{reply:Group}" == "BB") -> TRUE ++? if ("%{reply:Group}" == "BB") -> TRUE ++- entering if ("%{reply:Group}" == "BB") {...} +++? if ("%{reply:NAS-Identifier}" =~ /^CUST./ || "%{reply:NAS-Identifier}" == "BB") expand: %{reply:NAS-Identifier} -> VPN-SITE1 ? Evaluating ("%{reply:NAS-Identifier}" =~ /^CUST./) -> FALSE expand: %{reply:NAS-Identifier} -> VPN-SITE1 ? Evaluating ("%{reply:NAS-Identifier}" == "BB") -> FALSE +++? if ("%{reply:NAS-Identifier}" =~ /^CUST./ || "%{reply:NAS-Identifier}" == "BB") -> FALSE +++- entering else else {...} expand: Rejected (BB: %{NAS-IP-Address}) -> Rejected (BB: 1.1.1.1) ++++[reply] returns noop ++++[reject] returns reject +++- else else returns reject ++- if ("%{reply:Group}" == "BB") returns reject Using Post-Auth-Type Reject # Executing group from file /etc/freeradius/sites-enabled/default +- entering group REJECT {...} [sql] expand: %{User-Name} -> bsup [sql] sql_set_user escaped user --> 'bsup' [sql] expand: %{User-Password} -> SAvwxNsqGeaJw [sql] expand: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') -> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'bsup', 'SAvwxNsqGeaJw', 'Access-Reject', '2016-07-25 16:55:58') rlm_sql (sql) in sql_postauth: query is INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'bsup', 'SAvwxNsqGeaJw', 'Access-Reject', '2016-07-25 16:55:58') rlm_sql (sql): Reserving sql socket id: 2 rlm_sql (sql): Released sql socket id: 2 ++[sql] returns ok [attr_filter.access_reject] expand: %{User-Name} -> bsup attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 0 Sending Access-Reject of id 34 to 192.168.4.1 port 50070 Reply-Message = "Rejected (BB: 1.1.1.1)" Waking up in 4.9 seconds. Cleaning up request 0 ID 34 with timestamp +5 [DEBUG LOG ENDS] Hopefully this make sense now.

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>

On Jul 25, 2016, at 3:34 PM, Anastasios Gryponisiotis <plant7@gmail.com> wrote:

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.

I suspect you mean: if (A) { } else { reject } if (B) { } else { reject } Which is NOT what Matthew and I suggested, and will NOT work.

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.

What led you to believe that an "update" section will cause the server to stop processing a section? Please point to documentation which says that's what happens. The problem here is that you *think* you know how the server works. But the server doesn't work that way. As a result, you're confused as to why the server isn't doing what you expect. Well... it behaves the way it's documented to behave. Read the documentation, and fix your mental model of how the server works.

Am I wrong to assume that since the reply is acted upon it should not return noop?

That assumption is wrong. I've been trying to convince you of that for a while now. Why is to so hard to trust the experts?

This is what all my other if/else conditionals are already doing.

No, they're not. Read the debug output again. The "update" section are transparent to module return codes. i.e. if the module before the "update" section returned "foo", the update section will also return "foo". The only caveat is that a module returning "reject" will always cause the server to immediately stop processing the section. Which means that any subsequent "update" section won't get run.

Instead I get a reject from a "else" further down the conditionals.

Because as I've said before... you can't use the module return codes for control flow. Use the "if" sections for that. Go read the FreeRADIUS technical guide located at http://networkradius.com/freeradius-documentation/ It describes in great detail how the server processes "authorize", etc. And believe Matthew and me when we tell you that your control flow of "if" statements is wrong. You can keep arguing and not fixing the problem, or you can implement our suggestion (which was largely identical), and fix the problem. Alan DeKok.

On Jul 25, 2016, at 4:47 PM, Anastasios Gryponisiotis <plant7@gmail.com> wrote:

Please appreciate that I need to understand what needs to be done, not mindlessly read documentation

What an utterly offensive thing to say. The point of documentation is for you to READ IT. If you're not going to read the documentation we suggest, then you should unsubscribe from this list. You will never know what needs to be done until you know how the server works, and how to configure it. This all is documented.

My question all along is why an update reply statement returns noop although it is performing a change. I get this:

++++[reply] returns noop

I have read the documentation, which says that noop means "the module did nothing". Isn't updating the reply something?

I've answered this repeatedly. Since it's clear that you refuse to read the documentation, and that you refuse to read and/or understand my answers here, there's only one remaining course of action. Go away. Alan DeKok.

Matthew thank you very much for this response. This clarifies some misconceptions I had in regards to the noop return. I will use my own attributes to achieve this, along with some if/else statements and should get the result needed. On Tue, Jul 26, 2016 at 12:22 PM Matthew Newton <mcn4@leicester.ac.uk> wrote:

On Mon, Jul 25, 2016 at 08:47:21PM +0000, Anastasios Gryponisiotis wrote:

...

Please appreciate that I need to understand what needs to be done, not mindlessly read documentation and change logic without knowing why/what I'm

But reading documentation helps you understand how things work :(

...

For the record, Mathew did not suggest doing a if/elseif/else tree. He actually said that it would be too complicated to troubleshoot.

I didn't say *don't* do an if/elsif/else tree. Just that trying to get the whole logic of that in one tree with rejects in the right places can be too hard to do sometimes. Hence breaking it up into smaller ifs, and setting other attributes to control whether you reject or not at the end.

...

My question all along is why an update reply statement returns noop although it is performing a change. I get this:

++++[reply] returns noop

if() statements are not modules, so do not set module return codes by themselves. Which is why you see "noop". You might see a different result if the contents of the if returned something different, as the if() will pass the contained module return code back up.

In this case, "update" pretty much *always* returns code "noop", which is why the if() also returns noop.

If you want to explicitly reject, you need to call a module that sets the return code to "reject". Conveniently, the "reject" module does this for you.

...

I have read the documentation, which says that noop means "the module did nothing". Isn't updating the reply something?

There was no module. if() isn't a module, it's an unlang statement. update{} updates the attribute lists (request, control, or reply), and is also an unlang statement.

Modules set the return code, most unlang statements do not. At the end of each section (authorize, post-auth, etc) the module return code with the highest priority is used to determine which type of RADIUS packet (Accept, Reject) to send back - not the attributes that have been set (with update{} or otherwise). The attributes from the reply list are put *in* the packet, but don't set the *type* of the packet.

If you want to reject at some point, then call "reject".

As I said before, it looks like you've got some pretty complex logic, so breaking that down to simpler stages, and using meaningful attribute names, can make things much easier to follow in your config.

Then put a short section at the end which explicitly does a "reject" if required.

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