On Wed, Jun 19, 2019 at 5:27 PM Alan DeKok <aland@deployingradius.com> wrote:

On Jun 19, 2019, at 11:16 AM, Gianni Costanzi <gianni.costanzi@gmail.com> wrote:

...

I was using the following syntax on Freeradius 2.x to determine if a user could connect to a particular IP address, even if the authentication succeeds, based on some parameters passed to a script:

XXX747 Auth-Type = System, Realm == imp Service-Type := Login-User, cisco-avpair = "shell:priv-lvl=2", Exec-Program-Wait = "/opt/script/radius/bin/check_operator_access.sh %{NAS-IP-Address} %{User-Name} %{Realm}"

Exec-Program-Wait goes in the first line. It's a check attribute, and isn't a reply attribute.

Alan DeKok.

I tried to move the Exec-Program-Wait to the first line but it is still not executed.. I can see that the authentication is proxied to realm Imp, it receives an Access accept but then the entry or XXX747 is not matched and the DEFAULT entry with an access Reject is matched. The program is still not executed: XXX747 Auth-Type = System, Realm == imp, Exec-Program-Wait = "/opt/script/radius/bin/check_operator_access.sh %{NAS-IP-Address} %{User-Name} %{Realm}" Service-Type := Login-User, cisco-avpair = "shell:priv-lvl=2" Is the above entry correct, with Exec-Program-Wait on the first line? Some logs: (3) suffix: Proxying request from user XXX747 to realm imp (3) suffix: Preparing to proxy authentication request to realm "imp" (3) [suffix] = updated (3) files: EXPAND /opt/script/radius/bin/check_operator_access.sh %{NAS-IP-Address} %{User-Name} %{Realm} (3) files: --> /opt/script/radius/bin/check_operator_access.sh 10.227.143.200 XXX747@imp imp (3) files: users: Matched entry DEFAULT at line 17805 (3) [files] = ok (3) sql: EXPAND %{%{Stripped-User-Name}:-%{%{User-Name}:-none}} (3) sql: --> XXX747 (3) sql: SQL-User-Name set to 'XXX747' rlm_sql (sql): Reserved connection (3) (3) sql: EXPAND SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = '%{SQL-User-Name}' ORDER BY id (3) sql: --> SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = 'XXX747' ORDER BY id (3) sql: Executing select query: SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = 'XXX747' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 5 (3) sql: EXPAND SELECT GroupName FROM radusergroup WHERE UserName='%{SQL-User-Name}' ORDER BY priority (3) sql: --> SELECT GroupName FROM radusergroup WHERE UserName='XXX747' ORDER BY priority (3) sql: Executing select query: SELECT GroupName FROM radusergroup WHERE UserName='XXX747' ORDER BY priority rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 1 (3) sql: User not found in any groups rlm_sql (sql): Released connection (3) Need 3 more connections to reach 10 spares rlm_sql (sql): Opening additional connection (7), 1 of 25 pending slots used rlm_sql_postgresql: Connecting using parameters: dbname='radius_db' host='127.0.0.1' port=5432 user='radius' password='cPKlc-Pb_H09' application_name='FreeRADIUS 3.0.13 - radiusd (sql)' Connected to database 'radius_db' on '127.0.0.1' server version 90224, protocol version 3, backend PID 968 (3) [sql] = notfound (3) [expiration] = noop (3) [logintime] = noop (3) [pap] = noop (3) } # authorize = updated (3) Starting proxy to home server 10.240.24.151 port 1812 (3) Proxying request to home server 10.240.24.151 port 1812 timeout 20.000000 (3) Sent Access-Request Id 126 from 0.0.0.0:34919 to 10.240.24.151:1812 length 101 (3) User-Name := "XXX747" (3) User-Password = "1234567890" (3) NAS-Port = 132 (3) NAS-Port-Id = "tty132" (3) NAS-Port-Type = Virtual (3) NAS-IP-Address = 10.227.143.200 (3) Event-Timestamp = "Jun 19 2019 17:51:56 CEST" (3) Message-Authenticator := 0x00 (3) Proxy-State = 0x313438 Waking up in 0.3 seconds. (3) Clearing existing &reply: attributes (3) Received Access-Accept Id 126 from 10.240.24.151:1812 to 10.240.0.5:34919 length 49 (3) Reply-Message = "Pass" (3) Message-Authenticator = 0x4e57018f18713865960677d6ccf7002b (3) Proxy-State = 0x313438 (3) # Executing section post-proxy from file /etc/raddb/sites-enabled/default (3) post-proxy { (3) attr_filter.post-proxy: EXPAND %{Realm} (3) attr_filter.post-proxy: --> imp (3) attr_filter.post-proxy: Matched entry imp at line 110 (3) [attr_filter.post-proxy] = updated (3) } # post-proxy = updated (3) Found Auth-Type = Reject (3) Auth-Type = Reject, rejecting user (3) Failed to authenticate the user (3) Login incorrect: [XXX747@imp] (from client r-AA port 132) (3) Using Post-Auth-Type Reject

On Wed, Jun 19, 2019 at 6:40 PM Alan DeKok <aland@deployingradius.com> wrote:

On Jun 19, 2019, at 12:03 PM, Gianni Costanzi <gianni.costanzi@gmail.com> wrote:

...

I tried to move the Exec-Program-Wait to the first line but it is still not executed.. I can see that the authentication is proxied to realm Imp, it receives an Access accept but then the entry or XXX747 is not matched and the DEFAULT entry with an access Reject is matched. The program is still not executed:

You can also use raddb/mods-available/exec, which may be a little clearer.

...

XXX747 Auth-Type = System, Realm == imp, Exec-Program-Wait = "/opt/script/radius/bin/check_operator_access.sh %{NAS-IP-Address} %{User-Name} %{Realm}" Service-Type := Login-User, cisco-avpair = "shell:priv-lvl=2"

Is the above entry correct, with Exec-Program-Wait on the first line?

Use ":=" instead of "=" for Exec-Program-Wait.

...

Some logs: ... (3) Received Access-Accept Id 126 from 10.240.24.151:1812 to 10.240.0.5:34919 length 49 (3) Reply-Message = "Pass" (3) Message-Authenticator = 0x4e57018f18713865960677d6ccf7002b (3) Proxy-State = 0x313438 (3) # Executing section post-proxy from file /etc/raddb/sites-enabled/default

That's good.

...

(3) post-proxy { (3) attr_filter.post-proxy: EXPAND %{Realm} (3) attr_filter.post-proxy: --> imp (3) attr_filter.post-proxy: Matched entry imp at line 110 (3) [attr_filter.post-proxy] = updated (3) } # post-proxy = updated (3) Found Auth-Type = Reject

Uh... why are you dong that?

...

(3) Auth-Type = Reject, rejecting user (3) Failed to authenticate the user (3) Login incorrect: [XXX747@imp] (from client r-AA port 132) (3) Using Post-Auth-Type Reject

Exec-Program-Wait isn't run for rejected packets.

Why are you forcing "Auth-Type = Reject"?

Alan DeKok.

Auth-Type reject is forced by the default entry, which is examined because the user entry was not matched with Exec-Program-Wait = "xxxx" (basically I need to reject the user if it receives an access accept but it is not matched by a specific entry in the users file). Now I tried with a simpler user, which is not authenticated on another realm and has a simple cleartext password. This time the entry for testgianni user is matched, but the program is not invoked: testgianni Cleartext-Password := "test123", Exec-Program-Wait := "/opt/script/radius/bin/check_operator_access.sh %{NAS-IP-Address} %{User-Name} %{Realm}" Service-Type := Login-User, cisco-avpair = "shell:priv-lvl=2" DEFAULT Realm == imp, Auth-Type := reject (1) suffix: No '@' in User-Name = "testgianni", looking up realm NULL (1) suffix: No such realm "NULL" (1) [suffix] = noop (1) files: EXPAND /opt/script/radius/bin/check_operator_access.sh %{NAS-IP-Address} %{User-Name} %{Realm} (1) files: --> /opt/script/radius/bin/check_operator_access.sh 10.122.159.2 testgianni (1) files: users: Matched entry testgianni at line 512 (1) [files] = ok [...] (1) Found Auth-Type = PAP (1) # Executing group from file /etc/raddb/sites-enabled/default (1) Auth-Type PAP { (1) pap: Login attempt with password (1) pap: Comparing with "known good" Cleartext-Password (1) pap: User authenticated successfully (1) [pap] = ok (1) } # Auth-Type PAP = ok (1) # Executing section post-auth from file /etc/raddb/sites-enabled/default (1) post-auth { (1) update { (1) No attributes updated (1) } # update = noop (1) [exec] = noop (1) policy remove_reply_message_if_eap { (1) if (&reply:EAP-Message && &reply:Reply-Message) { (1) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (1) else { (1) [noop] = noop (1) } # else = noop (1) } # policy remove_reply_message_if_eap = noop (1) if ( &request:Realm && (request:Realm == "imp" || request:Realm == "sw" || request:Realm == "sas" )) { (1) if ( &request:Realm && (request:Realm == "imp" || request:Realm == "sw" || request:Realm == "sas" )) -> FALSE (1) } # post-auth = noop (1) Login OK: [testgianni] (from client r-PE port 132) (1) Sent Access-Accept Id 223 from 10.120.0.5:1812 to 10.122.159.2:1645 length 0 (1) Service-Type = Login-User (1) Cisco-AVPair = "shell:priv-lvl=2" (1) Finished request

Il giorno mer 19 giu 2019 alle 19:09 Alan DeKok <aland@deployingradius.com> ha scritto:

On Jun 19, 2019, at 12:55 PM, Gianni Costanzi <gianni.costanzi@gmail.com> wrote:

...

Auth-Type reject is forced by the default entry, which is examined because the user entry was not matched with Exec-Program-Wait = "xxxx"

No, that's not true. Exec-Program-Wait doesn't affect how a "users" file entry is matched.

So the problem isn't with Exec-Program-Wait. It's with matching entries in the "users" file.

Describing the problem *correctly* will let us help you. Giving wrong information is a waste of everyones time.

...

(basically I need to reject the user if it receives an access accept but it is not matched by a specific entry in the users file).

That's the default behaviour. You don't need to add rules to do that.

...

Now I tried with a simpler user, which is not authenticated on another realm and has a simple cleartext password. This time the entry for testgianni user is matched, but the program is not invoked:

testgianni Cleartext-Password := "test123", Exec-Program-Wait := "/opt/script/radius/bin/check_operator_access.sh %{NAS-IP-Address} %{User-Name} %{Realm}" Service-Type := Login-User, cisco-avpair = "shell:priv-lvl=2"

DEFAULT Realm == imp, Auth-Type := reject

(1) suffix: No '@' in User-Name = "testgianni", looking up realm NULL (1) suffix: No such realm "NULL" (1) [suffix] = noop (1) files: EXPAND /opt/script/radius/bin/check_operator_access.sh %{NAS-IP-Address} %{User-Name} %{Realm} (1) files: --> /opt/script/radius/bin/check_operator_access.sh 10.122.159.2 testgianni (1) files: users: Matched entry testgianni at line 512 (1) [files] = ok [...] (1) Found Auth-Type = PAP (1) # Executing group from file /etc/raddb/sites-enabled/default (1) Auth-Type PAP { (1) pap: Login attempt with password (1) pap: Comparing with "known good" Cleartext-Password (1) pap: User authenticated successfully (1) [pap] = ok (1) } # Auth-Type PAP = ok (1) # Executing section post-auth from file /etc/raddb/sites-enabled/default (1) post-auth { (1) update { (1) No attributes updated (1) } # update = noop (1) [exec] = noop

The "exec" module implements the Exec-Program-Wait functionality. If it's returning "noop", that's because the module doesn't see Exec-Program-Wait.

At this point, just use the "exec" module. See the "echo" module for examples of running a custom program.

Alan DeKok.

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

Hi Alan, the user is accepted by realm Imp proxy, then I force an analysis of users file even if the realm authentication succeeds, because there can be a user that is authenticated by the realm but must not be accepted by radius (you must be accepted by realm imp and be defined in the users file in order to have an access accept). So if realm authentication returns access Accept and I don’t put a default access reject for users with realm imp, every user authenticated by realm imp would be accepted by radius even without being defined in users file. When I put the exec-program-wait with := as you suggested the user entry is matched but the program is not executed at all, otherwise I would get an entry in /var/log/messages. I gave a look at the echo example but I don’t understand how I should use it in the way I was using exec-program-wait in release 2.0 (where it worked even if not placed on the first line as a check condition and was invoked correctly). I need to invoke that program only for some specific users and after having received an access accept by realm imp. Then I can return access accept to the device that authenticated the user. Hope I have clarified a bit our configuration. Gianni -- --< Sent from GMail mobile >-- -------------------------------------------------------------------------------------------------------------- Find me on LinkedIn: http://it.linkedin.com/in/giannicostanzi My blog: http://networkingpills.wordpress.com My best photos on 500px: http://500px.com/GianniCostanzi PGP Key Fingerprint: 2404 1798 E01F F6BF 0FA3 AA07 B6D5 040F 2EDD 456A --------------------------------------------------------------------------------------------------------------

Il giorno mer 19 giu 2019 alle 21:34 Alan DeKok <aland@deployingradius.com> ha scritto:

On Jun 19, 2019, at 2:18 PM, Gianni Costanzi <gianni.costanzi@gmail.com> wrote:

...

Hi Alan, the user is accepted by realm Imp proxy, then I force an analysis of users file even if the realm authentication succeeds, because there can be a user that is authenticated by the realm but must not be accepted by radius (you must be accepted by realm imp and be defined in the users file in order to have an access accept).

Why not just check the "users" file *before* proxying?

authorize { ... files if (notfound) { reject } ... }

It's *always* better to reject as soon as possible, instead of accepting the user, and then going "whoops, they were supposed to be rejected!"

If the "users" file isn't well-suited for this, you can use any number of other modules to load users from databases or text files.

...

So if realm authentication returns access Accept and I don’t put a default access reject for users with realm imp, every user authenticated by realm imp would be accepted by radius even without being defined in users file.

See above.

Again, describing the problem *correctly* will let us help you. Giving wrong or incomplete information is a waste of everyones time.

Right now, you're giving out information in bits and pieces. Stop it.

...

When I put the exec-program-wait with := as you suggested the user entry is matched but the program is not executed at all, otherwise I would get an entry in /var/log/messages.

You'd also get a message in the debug output. Which we recommend reading.

...

I gave a look at the echo example but I don’t understand how I should use it in the way I was using exec-program-wait in release 2.0

You don't. You can create a module. You can control when modules are called through if / then / else conditions.

You're stuck on implementing a *particular* solution. Which means you're ignoring alternative solutions.

...

(where it worked even if not placed on the first line as a check condition and was invoked correctly).

You've said that already. We understand.

...

I need to invoke that program only for some specific users and after having received an access accept by realm imp. Then I can return access accept to the device that authenticated the user.

See above:

a) reject users BEFORE proxying b) then run the program for ALL users on Access-Accept

...

Hope I have clarified a bit our configuration.

I sincerely hope that this is the last clarification.

Alan DeKok.

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

Let’s keep it simple: I can’t invoke the program for every user that is found in users file, but only for some users, and the syntax I was using with Exec-Program-Wait was perfectly well suited for our purpose. So it’s perfectly fine to reject the user before proxying it as you suggested, but then I still need to invoke the external program only for some selected users. To avoid you being so acid (I don’t really understand why, I was quite polite I think), you’ve told me how to call Exec-Program-Wait, with := and on the first line as a check item. I’ve told you that it is not invoked even when I do that. Can you explain me why? Where should I check if there is an error? Is there some different requirement compared to previous versions of freeradius server? I think you can answer me even without further details on this point. We’re in an open source community where everyone should help the others if the others are polite and correct. I think I’ve been both, so I don’t really understand why you answered in such a bad way. Best regards Gianni Costanzi -- --< Sent from GMail mobile >-- -------------------------------------------------------------------------------------------------------------- Find me on LinkedIn: http://it.linkedin.com/in/giannicostanzi My blog: http://networkingpills.wordpress.com My best photos on 500px: http://500px.com/GianniCostanzi PGP Key Fingerprint: 2404 1798 E01F F6BF 0FA3 AA07 B6D5 040F 2EDD 456A --------------------------------------------------------------------------------------------------------------

Il giorno mer 19 giu 2019 alle 22:13 Alan DeKok <aland@deployingradius.com> ha scritto:

On Jun 19, 2019, at 4:00 PM, Gianni Costanzi <gianni.costanzi@gmail.com> wrote:

...

Let’s keep it simple: I can’t invoke the program for every user that is found in users file, but only for some users, and the syntax I was using with Exec-Program-Wait was perfectly well suited for our purpose.

You've said that lots. Why repeat yourself?

...

So it’s perfectly fine to reject the user before proxying it as you suggested, but then I still need to invoke the external program only for some selected users.

You've already said that. I already gave you suggestions for how else to do it.

Your response was essentially "not going to do that. Not going to try to understand how to do it".

...

To avoid you being so acid

You are entirely too sensitive. I gave you technical answers to technical questions. I pointed out how you were essentially lying to us about the problem you're trying to solve. I suggested that better behaviour on your part would be productive.

Instead of learning, you reply by whining about how mean I am. That is completely unprofessional and childish. Stop it.

...

(I don’t really understand why, I was quite polite I think),

Superficially polite, but also refusing to follow advice. Which is rude.

...

you’ve told me how to call Exec-Program-Wait, with := and on the first line as a check item. I’ve told you that it is not invoked even when I do that. Can you explain me why?

<shrug> You're probably using an old version, or something else is happening.

...

Where should I check if there is an error?

It's Open Source. You have to source. Track it down, and supply a patch to fix the bug.

...

Is there some different requirement compared to previous versions of freeradius server? I think you can answer me even without further details on this point.

I've already answered that. Read my messages.

...

We’re in an open source community where everyone should help the others if the others are polite and correct.

AND FOLLOW INSTRUCTIONS. AND READ THE DOCUMENTATION.

When you say "nah, I'm not going to do that", it's rude. Which isn't polite.

...

I think I’ve been both, so I don’t really understand why you answered in such a bad way.

I can't explain your failure to understand. I've explained myself repeatedly. My "bad way" of answering is honest frustration at *you*, who is making it as difficult as possible for me to help you.

This is Open Source. You're not paying for support. Don't complain about the answers you get for free.

If it's a bug, you have access to the source. Track it down and fix it. If you're not willing to do that, then the "community" aspect you talked about is bullshit. For you, there is no community. Only others helping you for free, while you refuse to do anything yourself.

I've seen this attitude a lot over the past 20+ years in the open source community. The people complaining the loudest about others are the ones who (a) refuse to follow instructions, and (b) refuse to contribute.

I'll make it simple: follow instructions, read the docs, and you will be able to fix the problem. Keep complaining about how mean we are for helping you, and you will be banned from the list.

Alan DeKok.

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

Some answers: - I will go through the docs and the help about exec module and other things you’ve suggested, I’m not one that don’t follows your advices, I’ve said that without any reason - I’ve asked about hints about why exec-program-wait does not work and the only answer is probably is a bug related to an old version, I just hoped you gave me some hints about further points to check. I don’t know if you’ve ever worked in a Gdpr/pci-Dss/etc compliant company, ve are using the latest version available on our red hat enterprise servers, we can not instal the latest development release - I’m not childish, maybe you are, looking at your answers - you keep asking me while I repeat myself, I did it simply because the workaround you’ve suggested me simply to not implement the authentication flow I’ve explained - have you ever have a look at the other open source communities? About how experts help and answer to problems? Have a nice day/night Gianni

<http://www.freeradius.org/list/users.html>

-- --< Sent from GMail mobile >-- -------------------------------------------------------------------------------------------------------------- Find me on LinkedIn: http://it.linkedin.com/in/giannicostanzi My blog: http://networkingpills.wordpress.com My best photos on 500px: http://500px.com/GianniCostanzi PGP Key Fingerprint: 2404 1798 E01F F6BF 0FA3 AA07 B6D5 040F 2EDD 456A --------------------------------------------------------------------------------------------------------------

On Jun 19, 2019, at 4:56 PM, Gianni Costanzi <gianni.costanzi@gmail.com> wrote:

... I'm just trying to understand if there is something I can do to understand why it does not work on my configuration, before spending hours in understanding how exec or other modules work and if they can help me fulfill my requirements.

For everyone else reading, this is the key problem. Alan: Use the "exec" module, it will do what you want Gianni: I don't want to spend hours reading documentation on exec or *other* modules. I'm not sure *if* they will do what I want It really can't be stated any better than that. After being given a solution, his response is "no, I don't believe you". That's not an acceptable answer. Alan DeKok.

On Jun 19, 2019, at 4:24 PM, Gianni Costanzi <gianni.costanzi@gmail.com> wrote:

- I’ve asked about hints about why exec-program-wait does not work and the only answer is probably is a bug related to an old version, I just hoped you gave me some hints about further points to check. I don’t know if you’ve ever worked in a Gdpr/pci-Dss/etc compliant company, ve are using the latest version available on our red hat enterprise servers, we can not instal the latest development release

If you're paying RedHat for support, then ask them for help.

- I’m not childish, maybe you are, looking at your answers

And you're gone. Alan DeKok.