Hello After a week of trying to figure the HOWTO guide out (http://wiki.freeradius.org/guide/SQL%20Huntgroup%20HOWTO) and online searching I still cant make sense of the SQL and Huntgroup matching. Also tried the freeradius channel on IRC but to no luck. Basically my problem is the same as many others, and the people asked the same question didn't manage to get it working in the end. Im running Freeradius 2.1 with Daloradius frontend and the SQL_XLAT seemingly works and to the checks, and get correct IP and matching but in the end its not disallowing In the sites-enabled/default I use as described in the HOWTO: update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" { } if (Huntgroup-Name == ''){ reject } I believe that the issue it the later of the above statement that supposed to match and reject that's the problem but as many others I can't figure out how to get this working. DEBUG INFO: Ready to process requests. rad_recv: Access-Request packet from host 46.23X.XX.170 port 1645, id=105, length=66 User-Name = "bl" User-Password = "asdfasdf" NAS-Port = 1 NAS-Port-Id = "tty1" NAS-Port-Type = Virtual NAS-IP-Address = 46.23X.XX.170 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok sql_xlat expand: %{User-Name} -> bl sql_set_user escaped user --> 'bl' expand: SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}' -> SELECT groupname FROM radhuntgroup WHERE nasipaddress='46.23X.XX.170' rlm_sql (sql): Reserving sql socket id: 3 sql_xlat finished rlm_sql (sql): Released sql socket id: 3 expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> 3rdline ++[request] returns ok ++? if (Huntgroup-Name == '') ? Evaluating (Huntgroup-Name == '') -> FALSE ++? if (Huntgroup-Name == '') -> FALSE ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bl", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [sql] expand: %{User-Name} -> bl [sql] sql_set_user escaped user --> 'bl' rlm_sql (sql): Reserving sql socket id: 2 [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 = 'bl' 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 = 'bl' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'bl' 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 = '2ndline' ORDER BY id rlm_sql (sql): Released sql socket id: 2 ++[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 "asdfasdf" [pap] Using clear text password "asdfasdf" [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} -> bl [sql] sql_set_user escaped user --> 'bl' [sql] expand: %{User-Password} -> asdfasdf [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 ( 'bl', 'asdfasdf', 'Access-Accept', '2015-12-18 15:42:18') rlm_sql (sql) in sql_postauth: query is INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'bl', 'asdfasdf', 'Access-Accept', '2015-12-18 15:42:18') rlm_sql (sql): Reserving sql socket id: 1 rlm_sql (sql): Released sql socket id: 1 ++[sql] returns ok ++[exec] returns noop Sending Access-Accept of id 105 to 46.23X.XX.170 port 1645 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 105 with timestamp +23 Ready to process requests. Thanks for any help!
On Fri, Dec 18, 2015 at 03:06:57PM +0000, Joel Bergmark wrote:
In the sites-enabled/default I use as described in the HOWTO:
update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" { } if (Huntgroup-Name == ''){ reject }
So, reject if Huntgroup-Name is empty, right?
I believe that the issue it the later of the above statement that supposed to match and reject that's the problem but as many others I can't figure out how to get this working.
NAS-IP-Address = 46.23X.XX.170
...
expand: SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}' -> SELECT groupname FROM radhuntgroup WHERE nasipaddress='46.23X.XX.170'
...
expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> 3rdline
Huntgroup-Name is "3rdline"
++[request] returns ok ++? if (Huntgroup-Name == '') ? Evaluating (Huntgroup-Name == '') -> FALSE ++? if (Huntgroup-Name == '') -> FALSE
Doesn't reject because Huntgroup-Name isn't empty.
Sending Access-Accept of id 105 to 46.23X.XX.170 port 1645
Can't see a problem here? Matthew -- Matthew Newton, Ph.D. <mcn4@le.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>
Thanks for the input, I see that the issue is that I'm not a coder and didn't realise the function fully. The howto implies that this will check and reject, but I see my misinterpretation. But I don’t see how to deny login: if the user is not a member of the Houtgroup-Name then reject? I think the answer to this question should go up on the wiki, I emailed with several people that previously asked about this, but never got it working and gave up on freeradius. Thanks for the assistance. Kind regards, Joel -----Ursprungligt meddelande----- Från: Freeradius-Users [mailto:freeradius-users-bounces+joel.bergmark=t3.se@lists.freeradius.org] För Matthew Newton Skickat: den 18 december 2015 16:27 Till: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Ämne: Re: Make sense of SQL Huntgroup HOWTO? On Fri, Dec 18, 2015 at 03:06:57PM +0000, Joel Bergmark wrote:
In the sites-enabled/default I use as described in the HOWTO:
update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" { } if (Huntgroup-Name == ''){ reject }
So, reject if Huntgroup-Name is empty, right?
I believe that the issue it the later of the above statement that supposed to match and reject that's the problem but as many others I can't figure out how to get this working.
NAS-IP-Address = 46.23X.XX.170
...
expand: SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}' -> SELECT groupname FROM radhuntgroup WHERE nasipaddress='46.23X.XX.170'
...
expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> 3rdline
Huntgroup-Name is "3rdline"
++[request] returns ok ++? if (Huntgroup-Name == '') ? Evaluating (Huntgroup-Name == '') -> FALSE ++? if (Huntgroup-Name == '') -> FALSE
Doesn't reject because Huntgroup-Name isn't empty.
Sending Access-Accept of id 105 to 46.23X.XX.170 port 1645
Can't see a problem here? Matthew -- Matthew Newton, Ph.D. <mcn4@le.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
On Dec 18, 2015, at 10:51 AM, Joel Bergmark <joel.bergmark@t3.se> wrote:
Thanks for the input, I see that the issue is that I'm not a coder and didn't realise the function fully.
If you're not a programmer, you will have a *very* bad time creating custom rules in FreeRADIUS. Custom rules *are* programming. You will need to understand if / then / else statements, comparisons, strings, integers, etc.
But I don’t see how to deny login: if the user is not a member of the Houtgroup-Name then reject?
See "man unlang'. It's a simple check for *not* equal if (Huntgroup-Name != "foo") { # do stuff }
I think the answer to this question should go up on the wiki,
Then please edit the wiki. There's a REASON it's publicly accessible. One reason why the wiki isn't better is the reams of people who have problems.. find solutions... and never put them on the Wiki.
I emailed with several people that previously asked about this, but never got it working and gave up on freeradius.
If they couldn't get it to work, there's no point in asking them questions. Questions belong on this mailing list. The documentation is pretty much correct, and clear. Following it *will work*. When people can't get it to work, it's usually because they're not following the documentation, or they're trying to do something different... without really understanding what they're doing. Alan DeKok.
On Fri, Dec 18, 2015 at 03:51:28PM +0000, Joel Bergmark wrote:
Thanks for the input, I see that the issue is that I'm not a coder and didn't realise the function fully. The howto implies that this will check and reject, but I see my misinterpretation.
But what you've got *does* check and reject. It checks to see if the Huntgroup-Name set is blank, and rejects if so.
But I don’t see how to deny login: if the user is not a member of the Houtgroup-Name then reject?
I think the answer to this question should go up on the wiki, I emailed with several people that previously asked about this, but never got it working and gave up on freeradius.
I'm afraid I'm having trouble trying to understand exactly when you want to reject. When the user is in a particular huntgroup? Or if they are not in a huntgroup? Or something else? Matthew -- Matthew Newton, Ph.D. <mcn4@le.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>
Sorry for not being clear enough nor a programmer :) What I want to do is to control users belonging to group "2ndline" to only access specific nas defined as 2ndline in the huntgroups. If a member of 2ndline tries to login to a NAS defined to 3dline or any other group freeradius should deny access. That is what I believed that this function aimed to do, and what I cant fix is to get the variables right. but I guess that this should be dynamically checked. Assuming a user in 2ndline group trying to login to a NAS defined in huntgroup to be 3rdline update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" { } if (Huntgroup-Name != users groupname 2ndline (I imagine this to be a sql query) reject } Sorry if this is something not supposed to be dealt with on this mailing list, but the alternative is to set up double radius servers, and that seems backwards. I will document the solution to this on the wiki, if I get it working. Thanks for your patience. Regards, Joel -----Ursprungligt meddelande----- Från: Freeradius-Users [mailto:freeradius-users-bounces+joel.bergmark=t3.se@lists.freeradius.org] För Matthew Newton Skickat: den 18 december 2015 17:10 Till: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Ämne: Re: SV: Make sense of SQL Huntgroup HOWTO? On Fri, Dec 18, 2015 at 03:51:28PM +0000, Joel Bergmark wrote:
Thanks for the input, I see that the issue is that I'm not a coder and didn't realise the function fully. The howto implies that this will check and reject, but I see my misinterpretation.
But what you've got *does* check and reject. It checks to see if the Huntgroup-Name set is blank, and rejects if so.
But I don’t see how to deny login: if the user is not a member of the Houtgroup-Name then reject?
I think the answer to this question should go up on the wiki, I emailed with several people that previously asked about this, but never got it working and gave up on freeradius.
I'm afraid I'm having trouble trying to understand exactly when you want to reject. When the user is in a particular huntgroup? Or if they are not in a huntgroup? Or something else? Matthew -- Matthew Newton, Ph.D. <mcn4@le.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
On Dec 18, 2015, at 11:30 AM, Joel Bergmark <joel.bergmark@t3.se> wrote:
What I want to do is to control users belonging to group "2ndline" to only access specific nas defined as 2ndline in the huntgroups. If a member of 2ndline tries to login to a NAS defined to 3dline or any other group freeradius should deny access.
Then write that down. It's pretty much that simple. if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject } This assumes that the NAS groups are in Huntrgroup, and the user groups are in SQL.
Assuming a user in 2ndline group trying to login to a NAS defined in huntgroup to be 3rdline update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" { }
Formatting matters. update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } Extra braces are a problem.
if (Huntgroup-Name != users groupname 2ndline (I imagine this to be a sql query) reject }
Nope. Just use my example from above. It's simpler. That is, it assumes that the user groups are in SQL, too.
Sorry if this is something not supposed to be dealt with on this mailing list,
It is exactly what's supposed to be discussed here.
but the alternative is to set up double radius servers, and that seems backwards. I will document the solution to this on the wiki, if I get it working.
That would be nice. Alan DeKok.
Thank you for the help! Indeed this looks more simplistic and nice! :) Everything is in the SQL, necessary since using daloradius as frontend. Just a follow up on: if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject } How to determine the 'SQL-Group' in a simple way? Tried it as is to see how it behaved, and got: +- entering group authorize {...} sql_xlat expand: %{User-Name} -> bl sql_set_user escaped user --> 'bl' expand: SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}' -> SELECT groupname FROM radhuntgroup WHERE nasipaddress='46.23X.XX.170' rlm_sql (sql): Reserving sql socket id: 3 sql_xlat finished rlm_sql (sql): Released sql socket id: 3 expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> 3rdline ++[request] returns notfound ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) ?? Evaluating (Huntgroup-Name == "2ndline") -> FALSE ?? Skipping (SQL-Group != "2ndline") ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) -> FALSE ++[chap] returns noop Best regards, Joel -----Ursprungligt meddelande----- Från: Freeradius-Users [mailto:freeradius-users-bounces+joel.bergmark=t3.se@lists.freeradius.org] För Alan DeKok Skickat: den 18 december 2015 17:38 Till: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Ämne: Re: Make sense of SQL Huntgroup HOWTO? On Dec 18, 2015, at 11:30 AM, Joel Bergmark <joel.bergmark@t3.se> wrote:
What I want to do is to control users belonging to group "2ndline" to only access specific nas defined as 2ndline in the huntgroups. If a member of 2ndline tries to login to a NAS defined to 3dline or any other group freeradius should deny access.
Then write that down. It's pretty much that simple. if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject } This assumes that the NAS groups are in Huntrgroup, and the user groups are in SQL.
Assuming a user in 2ndline group trying to login to a NAS defined in huntgroup to be 3rdline update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" { }
Formatting matters. update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } Extra braces are a problem.
if (Huntgroup-Name != users groupname 2ndline (I imagine this to be a sql query) reject }
Nope. Just use my example from above. It's simpler. That is, it assumes that the user groups are in SQL, too.
Sorry if this is something not supposed to be dealt with on this mailing list,
It is exactly what's supposed to be discussed here.
but the alternative is to set up double radius servers, and that seems backwards. I will document the solution to this on the wiki, if I get it working.
That would be nice. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 18, 2015, at 12:31 PM, Joel Bergmark <joel.bergmark@t3.se> wrote:
Thank you for the help! Indeed this looks more simplistic and nice! :)
Everything is in the SQL, necessary since using daloradius as fronted.
OK.
Just a follow up on: if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject } How to determine the 'SQL-Group' in a simple way? Tried it as is to see how it behaved, and got:
What's "how to determine"? As I said, you put the user / group into SQL. The SQL module has documentation for how this is done.
+- entering group authorize {...} sql_xlat expand: %{User-Name} -> bl sql_set_user escaped user --> 'bl' expand: SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}' -> SELECT groupname FROM radhuntgroup WHERE nasipaddress='46.23X.XX.170' rlm_sql (sql): Reserving sql socket id: 3 sql_xlat finished rlm_sql (sql): Released sql socket id: 3 expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> 3rdline
That's pretty clear.
++[request] returns not found ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) ?? Evaluating (Huntgroup-Name == "2ndline") -> FALSE
Because it's '3rdline'
?? Skipping (SQL-Group != "2ndline") ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) -> FALSE ++[chap] returns noop
And it's not checking SQL-Group. Because the Huntgroup-Name doesn't match. Reading the debug output helps. Alan DeKok.
I'm not sure I have been clear enough. If conditions below is achieved ie, it's determined that user is 2ndline and nas is 3rdline then it's supposed to be rejected? If so then its not working since the radius allows access. If not, then I probably haven’t made myself understood, if user is recognized as 2ndline attempting to login to something belonging to 3rdline it should be rejected. Perhaps something more like this would work as described? update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } if ((Huntgroup-Name == "2ndline" || SQL-Group != "2ndline")) { reject } Regards, Joel -----Ursprungligt meddelande----- Från: Freeradius-Users [mailto:freeradius-users-bounces+joel.bergmark=t3.se@lists.freeradius.org] För Alan DeKok Skickat: den 18 december 2015 18:37 Till: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Ämne: Re: Make sense of SQL Huntgroup HOWTO? On Dec 18, 2015, at 12:31 PM, Joel Bergmark <joel.bergmark@t3.se> wrote:
Thank you for the help! Indeed this looks more simplistic and nice! :)
Everything is in the SQL, necessary since using daloradius as fronted.
OK.
Just a follow up on: if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject } How to determine the 'SQL-Group' in a simple way? Tried it as is to see how it behaved, and got:
What's "how to determine"? As I said, you put the user / group into SQL. The SQL module has documentation for how this is done.
+- entering group authorize {...} sql_xlat expand: %{User-Name} -> bl sql_set_user escaped user --> 'bl' expand: SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}' -> SELECT groupname FROM radhuntgroup WHERE nasipaddress='46.23X.XX.170' rlm_sql (sql): Reserving sql socket id: 3 sql_xlat finished rlm_sql (sql): Released sql socket id: 3 expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> 3rdline
That's pretty clear.
++[request] returns not found ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) ?? Evaluating (Huntgroup-Name == "2ndline") -> FALSE
Because it's '3rdline'
?? Skipping (SQL-Group != "2ndline") ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) -> ++FALSE [chap] returns noop
And it's not checking SQL-Group. Because the Huntgroup-Name doesn't match. Reading the debug output helps. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 18, 2015, at 3:38 PM, Joel Bergmark <joel.bergmark@t3.se> wrote:
I'm not sure I have been clear enough.
If conditions below is achieved ie, it's determined that user is 2ndline and nas is 3rdline then it's supposed to be rejected? If so then its not working since the radius allows access.
The server does not have these rules by default. If the rules you created don't do what you want, it's because the rules are wrong.
If not, then I probably haven’t made myself understood, if user is recognized as 2ndline attempting to login to something belonging to 3rdline it should be rejected.
Sure.
Perhaps something more like this would work as described?
update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } if ((Huntgroup-Name == "2ndline" || SQL-Group != "2ndline")) { reject }
No. That does NOT do what you want. Why not use the rules I put in my previous message? Are you changing them... just because? Do you understand what they did? Do you understand the difference between what I posted, and what you posted here? Alan DeKok.
I copy pasted the rules as you wrote them but they didn't work it allows a user defined as 2ndline to log on to equipment that’s 3rdline. I'm not enjoying to not be as clear as I would normally be, I work with networks, not so much freeradius or coding. This is what I ran: update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject } Debuginfo: rad_recv: Access-Request packet from host 46.23X.XX.170 port 1645, id=118, length=66 User-Name = "bl" User-Password = "asdfasdf" NAS-Port = 1 NAS-Port-Id = "tty1" NAS-Port-Type = Virtual NAS-IP-Address = 46.23X.XX.170 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} sql_xlat expand: %{User-Name} -> bl sql_set_user escaped user --> 'bl' expand: SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}' -> SELECT groupname FROM radhuntgroup WHERE nasipaddress='46.23X.XX.170' rlm_sql (sql): Reserving sql socket id: 3 sql_xlat finished rlm_sql (sql): Released sql socket id: 3 expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> Noc ++[request] returns notfound ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) ?? Evaluating (Huntgroup-Name == "2ndline") -> FALSE ?? Skipping (SQL-Group != "2ndline") ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) -> FALSE ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bl", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [sql] expand: %{User-Name} -> bl [sql] sql_set_user escaped user --> 'bl' rlm_sql (sql): Reserving sql socket id: 2 [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 = 'bl' 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 = 'bl' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'bl' 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 = '2ndline' ORDER BY id rlm_sql (sql): Released sql socket id: 2 ++[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 "asdfasdf" [pap] Using clear text password "asdfasdf" [pap] User authenticated successfully ++[pap] returns ok I expected to get reject on this login, but thats not happening, so I clearly don't understand all elements in this. I just want this to work, http://wiki.freeradius.org/guide/SQL%20Huntgroup%20HOWTO "Suppose you want to only allow the group site_a_admins to be used when logging into a NAS' at site_a . Assuming example_user was already a member of site_a_admins, you would follow the steps below." Or even better to allow 3rdline users to login to everything and 2ndline users to login to some equipment. Regards, Joel -----Ursprungligt meddelande----- Från: Freeradius-Users [mailto:freeradius-users-bounces+joel.bergmark=t3.se@lists.freeradius.org] För Alan DeKok Skickat: den 18 december 2015 21:43 Till: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Ämne: Re: Make sense of SQL Huntgroup HOWTO? On Dec 18, 2015, at 3:38 PM, Joel Bergmark <joel.bergmark@t3.se> wrote:
I'm not sure I have been clear enough.
If conditions below is achieved ie, it's determined that user is 2ndline and nas is 3rdline then it's supposed to be rejected? If so then its not working since the radius allows access.
The server does not have these rules by default. If the rules you created don't do what you want, it's because the rules are wrong.
If not, then I probably haven’t made myself understood, if user is recognized as 2ndline attempting to login to something belonging to 3rdline it should be rejected.
Sure.
Perhaps something more like this would work as described?
update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } if ((Huntgroup-Name == "2ndline" || SQL-Group != "2ndline")) { reject }
No. That does NOT do what you want. Why not use the rules I put in my previous message? Are you changing them... just because? Do you understand what they did? Do you understand the difference between what I posted, and what you posted here? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 2015-12-18 15:55, Joel Bergmark wrote:
I copy pasted the rules as you wrote them but they didn't work it allows a user defined as 2ndline to log on to equipment that’s 3rdline. I'm not enjoying to not be as clear as I would normally be, I work with networks, not so much freeradius or coding.
This is what I ran:
update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject }
Debuginfo:
rad_recv: Access-Request packet from host 46.23X.XX.170 port 1645, id=118, length=66 User-Name = "bl" User-Password = "asdfasdf" NAS-Port = 1 NAS-Port-Id = "tty1" NAS-Port-Type = Virtual NAS-IP-Address = 46.23X.XX.170 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} sql_xlat expand: %{User-Name} -> bl sql_set_user escaped user --> 'bl' expand: SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}' -> SELECT groupname FROM radhuntgroup WHERE nasipaddress='46.23X.XX.170' rlm_sql (sql): Reserving sql socket id: 3 sql_xlat finished rlm_sql (sql): Released sql socket id: 3 expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> Noc ++[request] returns notfound ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) ?? Evaluating (Huntgroup-Name == "2ndline") -> FALSE
Huntgroup-Name != 2ndline so the whole condition is false. The debug information shows you this. From the 20 seconds I looked at this I suspect the SQL is returning nothing.
?? Skipping (SQL-Group != "2ndline") ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) -> FALSE ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bl", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [sql] expand: %{User-Name} -> bl [sql] sql_set_user escaped user --> 'bl' rlm_sql (sql): Reserving sql socket id: 2 [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 = 'bl' 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 = 'bl' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'bl' 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 = '2ndline' ORDER BY id rlm_sql (sql): Released sql socket id: 2 ++[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 "asdfasdf" [pap] Using clear text password "asdfasdf" [pap] User authenticated successfully ++[pap] returns ok
I expected to get reject on this login, but thats not happening, so I clearly don't understand all elements in this.
I just want this to work, http://wiki.freeradius.org/guide/SQL%20Huntgroup%20HOWTO "Suppose you want to only allow the group site_a_admins to be used when logging into a NAS' at site_a . Assuming example_user was already a member of site_a_admins, you would follow the steps below."
Or even better to allow 3rdline users to login to everything and 2ndline users to login to some equipment.
Regards, Joel
-----Ursprungligt meddelande----- Från: Freeradius-Users [mailto:freeradius-users-bounces+joel.bergmark=t3.se@lists.freeradius.org] För Alan DeKok Skickat: den 18 december 2015 21:43 Till: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Ämne: Re: Make sense of SQL Huntgroup HOWTO?
On Dec 18, 2015, at 3:38 PM, Joel Bergmark <joel.bergmark@t3.se> wrote:
I'm not sure I have been clear enough.
If conditions below is achieved ie, it's determined that user is 2ndline and nas is 3rdline then it's supposed to be rejected? If so then its not working since the radius allows access. The server does not have these rules by default. If the rules you created don't do what you want, it's because the rules are wrong.
If not, then I probably haven’t made myself understood, if user is recognized as 2ndline attempting to login to something belonging to 3rdline it should be rejected. Sure.
Perhaps something more like this would work as described?
update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } if ((Huntgroup-Name == "2ndline" || SQL-Group != "2ndline")) { reject } No. That does NOT do what you want.
Why not use the rules I put in my previous message? Are you changing them... just because? Do you understand what they did? Do you understand the difference between what I posted, and what you posted here?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Fri, Dec 18, 2015 at 08:55:20PM +0000, Joel Bergmark wrote:
This is what I ran:
update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject }
rad_recv: Access-Request packet from host 46.23X.XX.170 port 1645, id=118, length=66 User-Name = "bl" ...
expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> Noc ++[request] returns notfound ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) ?? Evaluating (Huntgroup-Name == "2ndline") -> FALSE
Huntgroup-Name here is "Noc", which is why it didn't match.
?? Skipping (SQL-Group != "2ndline")
...so it short-circuited and didn't even bother checking SQL-Group - there's no point.
++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) -> FALSE
So didn't reject.
I expected to get reject on this login, but thats not happening, so I clearly don't understand all elements in this.
Or even better to allow 3rdline users to login to everything and 2ndline users to login to some equipment.
So your users are in two groups, namely "2ndline" or "3rdline"? In which case you are only interested in the "2ndline" case if "3rdline" can access everything. So you can start with if (SQL-Group == "2ndline") { ... } which will skip the case the SQL-Group is 3rdline (or anything else) in the ... If you've got other groups you might want to make that if (SQL-Group != "3rdline") { instead, to match all users that are *not* in 3rdline. Then once you've established users in 2ndline add extra stuff to reject on certain equipment, e.g. if (Huntgroup-Name != "2ndline") { reject } or if (Huntgroup-Name == "3rdline") { reject } Put together this could be if (SQL-Group == "2ndline") { if (Huntgroup-Name != "2ndline") { reject } } which you can combine to come up with what was before (or similar): if ((SQL-Group == "2ndline") && (Huntgroup-Name != "2ndline")) { reject } But read the debug output - just find the bit where the if() is tested, which will tell you what it's testing and therefore what is or isn't matching. Once you've done that you could for example join it all together into a policy that ends up something like # only allow 2ndline to 2ndline kit if (SQL-Group == "2ndline") { if (Huntgroup-Name != "2ndline") { reject } } # allow 3rdline to only access 3rdline and 2ndline kit elsif (SQL-Group == "3rdline") { if (Huntgroup-Name != "2ndline" && Huntgroup-Name != "3rdline") { reject } } # else user can by default access everything except "restricted" else { if (Huntgroup-Name == "restricted") { reject } } Does that help? Matthew -- Matthew Newton, Ph.D. <mcn4@le.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>
Thank you very very very much Matthew, this made my day! Also thanks to you others trying to help a network guy with this stuff. Your solution at the end helped me greatly and it looks like its working as necessary :-) I will document it properly and clear my config files and update the wiki and give credit to you Matthew! Im very grateful! :-) Kind regards and have a nice weekend /Joel -----Ursprungligt meddelande----- Från: Freeradius-Users [mailto:freeradius-users-bounces+joel.bergmark=t3.se@lists.freeradius.org] För Matthew Newton Skickat: den 18 december 2015 22:28 Till: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Ämne: Re: SV: Make sense of SQL Huntgroup HOWTO? On Fri, Dec 18, 2015 at 08:55:20PM +0000, Joel Bergmark wrote:
This is what I ran:
update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject }
rad_recv: Access-Request packet from host 46.23X.XX.170 port 1645, id=118, length=66 User-Name = "bl" ...
expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'} -> Noc ++[request] returns notfound ++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) ?? Evaluating (Huntgroup-Name == "2ndline") -> FALSE
Huntgroup-Name here is "Noc", which is why it didn't match.
?? Skipping (SQL-Group != "2ndline")
...so it short-circuited and didn't even bother checking SQL-Group - there's no point.
++? if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) -> ++FALSE
So didn't reject.
I expected to get reject on this login, but thats not happening, so I clearly don't understand all elements in this.
Or even better to allow 3rdline users to login to everything and 2ndline users to login to some equipment.
So your users are in two groups, namely "2ndline" or "3rdline"? In which case you are only interested in the "2ndline" case if "3rdline" can access everything. So you can start with if (SQL-Group == "2ndline") { ... } which will skip the case the SQL-Group is 3rdline (or anything else) in the ... If you've got other groups you might want to make that if (SQL-Group != "3rdline") { instead, to match all users that are *not* in 3rdline. Then once you've established users in 2ndline add extra stuff to reject on certain equipment, e.g. if (Huntgroup-Name != "2ndline") { reject } or if (Huntgroup-Name == "3rdline") { reject } Put together this could be if (SQL-Group == "2ndline") { if (Huntgroup-Name != "2ndline") { reject } } which you can combine to come up with what was before (or similar): if ((SQL-Group == "2ndline") && (Huntgroup-Name != "2ndline")) { reject } But read the debug output - just find the bit where the if() is tested, which will tell you what it's testing and therefore what is or isn't matching. Once you've done that you could for example join it all together into a policy that ends up something like # only allow 2ndline to 2ndline kit if (SQL-Group == "2ndline") { if (Huntgroup-Name != "2ndline") { reject } } # allow 3rdline to only access 3rdline and 2ndline kit elsif (SQL-Group == "3rdline") { if (Huntgroup-Name != "2ndline" && Huntgroup-Name != "3rdline") { reject } } # else user can by default access everything except "restricted" else { if (Huntgroup-Name == "restricted") { reject } } Does that help? Matthew -- Matthew Newton, Ph.D. <mcn4@le.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
On Fri, Dec 18, 2015 at 09:52:20PM +0000, Joel Bergmark wrote:
Thank you very very very much Matthew, this made my day! Also thanks to you others trying to help a network guy with this stuff.
You're welcome. Alan is completely right - it's only simple logic. The key is to work out exactly what you want to do, then think the logic for that, then program it. Which is why we find it hard when people post questions with very unclear requirements as we're all stuck at the first step.
Your solution at the end helped me greatly and it looks like its working as necessary :-)
Hopefully you've got the basics that you can extend. Building up from small components can help. It's harder for me; I've been programming for over 25 years so this stuff just makes sense. I can see it's not so easy when you're starting from scratch. But without a policy configuration language FreeRADIUS would be much less powerful. Have a read of the unlang documentation, but really "if/elsif/else" are all you need for the vast majority of things. Though switch/case/default can be very useful in a few cases. http://freeradius.org/radiusd/man/unlang.html http://networkradius.com/doc/current/unlang/keywords.html Matthew -- Matthew Newton, Ph.D. <mcn4@le.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 Dec 18, 2015, at 6:25 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Alan is completely right - it's only simple logic. The key is to work out exactly what you want to do, then think the logic for that, then program it. Which is why we find it hard when people post questions with very unclear requirements as we're all stuck at the first step.
The hard part is explaining that we *need* clear requirements. And that the requirements shouldn't change from message to message. And that the tests should match the requirements, instead of testing something else entirely. Alan DeKok.
On Dec 18, 2015, at 3:55 PM, Joel Bergmark <joel.bergmark@t3.se> wrote:
I copy pasted the rules as you wrote them but they didn't work it allows a user defined as 2ndline to log on to equipment that’s 3rdline.
Because one rule does one check... which does one thing. If you want something *else*, you have to add another rule. My goal was to get you to understand it a piece at a time. And to hope that once you understood it, you could extend it.
I'm not enjoying to not be as clear as I would normally be, I work with networks, not so much freeradius or coding.
Again, if you don't understand coding, you will have a *very* bad time. Creating these rules *is* coding. if / then / else checks, etc.
This is what I ran:
update request { Huntgroup-Name := "%{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress='%{NAS-IP-Address}'}" } if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject }
Honestly, this shouldn't be difficult. You can read off that rule pretty much as straightforward english. It does one thing, and only one thing. If you want something else... write an additional rule. You seem to think that you can solve the problem by trying random things. You can't. That's not how programming works. You have to *understand* what you're doing. And write down what the requirements are. In detail. Write down which situations the users should get access, and which situations they should be denied. Then, implement that in "unlang". Alan DeKok.
On Fri, Dec 18, 2015 at 05:31:17PM +0000, Joel Bergmark wrote:
Thank you for the help! Indeed this looks more simplistic and nice! :)
Everything is in the SQL, necessary since using daloradius as frontend.
Just a follow up on: if ((Huntgroup-Name == "2ndline") && (SQL-Group != "2ndline")) { reject }
Small comment; if your situation is really simple where the user group must always be the same as the hunt group, then you could possibly even just use if (Huntgroup-Name != SQL-Group) { reject } Also, if you want to find out what SQL-Group expands to, just put something like if (SQL-Group == "") { noop } in the config, then look at the debug output. Matthew -- Matthew Newton, Ph.D. <mcn4@le.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>
participants (4)
-
Alan DeKok -
Joel Bergmark -
Matthew Newton -
Michael Hartwick