Mac Auth and post-auth logging to SQL
Hello, I'm running FreeRADIUS 2.1.7 on CentOS 5, and trying to configure MAC Auth Bypass. I got everything functioning correctly using the Mac-Auth Wiki page as a guide, including placement of the actual CSID authentication code in the post-auth section. However, I just enabled SQL in the post-auth section, and everything is getting logged to SQL with reply Access-Accept, even if it matched the "reject" statement. It seems to me that it's pretty logical that post-auth would be entered with Auth-Type == Access-Accept, the SQL log would happen, and *then* the "reject" statement would get executed. What I don't understand is why I shouldn't move the actual authentication (authorized_macs.authorize) to the auth { } section, or else how I go about logging rejected requests. Any advice or guidance would be greatly appreciated. Thanks, Jason Antman -- Jason Antman System Administrator Rutgers University OIT Central Systems & Services / NetOps Office: 732-445-6363 Cell: 732-983-7256 jantman@oit.rutgers.edu
Jason Antman wrote:
I'm running FreeRADIUS 2.1.7 on CentOS 5, and trying to configure MAC Auth Bypass. I got everything functioning correctly using the Mac-Auth Wiki page as a guide, including placement of the actual CSID authentication code in the post-auth section. However, I just enabled SQL in the post-auth section, and everything is getting logged to SQL with reply Access-Accept, even if it matched the "reject" statement.
I don't see how that is possible. Are you sure you know what it's doing? Have you run the server in debugging mode?
It seems to me that it's pretty logical that post-auth would be entered with Auth-Type == Access-Accept, the SQL log would happen, and *then* the "reject" statement would get executed
That makes no sense. "If it's accept, it runs reject" ?
. What I don't understand is why I shouldn't move the actual authentication (authorized_macs.authorize) to the auth { } section, or else how I go about logging rejected requests.
I have no idea what that means. Alan DeKok.
I'm referencing the Mac-Auth wiki page at: http://wiki.freeradius.org/Mac-Auth Alan DeKok wrote:
Jason Antman wrote:
I'm running FreeRADIUS 2.1.7 on CentOS 5, and trying to configure MAC Auth Bypass. I got everything functioning correctly using the Mac-Auth Wiki page as a guide, including placement of the actual CSID authentication code in the post-auth section. However, I just enabled SQL in the post-auth section, and everything is getting logged to SQL with reply Access-Accept, even if it matched the "reject" statement.
I don't see how that is possible. Are you sure you know what it's doing? Have you run the server in debugging mode?
Yes, I have, and am. As per the wiki page... I have in authenticate {}: ### snip ### Auth-Type CSID { if(Chap-Password){ update control { Cleartext-Password := "%{User-Name}" } chap } else{ ok } } ### end snip### which ALWAYS returns OK. Period. And in post-auth{}: ### snip ### if(control:Auth-Type == 'CSID'){ # Authorization happens here authorized_macs.authorize if(!ok){ reject } } ### end snip ### If I put a "sql" line before this, it always logs with Access-Accept, since that's what authenticate{} ALWAYS returns, and the sql module is being called before . If I put a "sql" line after this, it never gets executed for "reject" statements...
It seems to me that it's pretty logical that post-auth would be entered with Auth-Type == Access-Accept, the SQL log would happen, and *then* the "reject" statement would get executed
That makes no sense. "If it's accept, it runs reject" ?
See above.
. What I don't understand is why I shouldn't move the actual authentication (authorized_macs.authorize) to the auth { } section, or else how I go about logging rejected requests.
I have no idea what that means.
Why is the authorize statement in the post-auth { } section? That seems to be the cause of these problems...
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Jason Antman wrote:
And in post-auth{}: ### snip ### if(control:Auth-Type == 'CSID'){ # Authorization happens here authorized_macs.authorize if(!ok){ reject
Uh... why? If the user is authenticated, you shouldn't be rejecting him.
If I put a "sql" line before this, it always logs with Access-Accept, since that's what authenticate{} ALWAYS returns, and the sql module is being called before . If I put a "sql" line after this, it never gets executed for "reject" statements...
Because you're doing it wrong. The whole point of accepting the user is that you *don't* reject them. Change your rules to reject the user *before* they're accepted. The logging will then behave as you expect. It doesn't behave as you expect now, because you're rejecting them after you've accepted them. That makes no sense.
Why is the authorize statement in the post-auth { } section? That seems to be the cause of these problems...
So move it. Alan DeKok.
Ok. I was just assuming that the FreeRadius Wiki was an authoritative source, and if it's written there, there must be something I just wasn't understanding that required it to be that way. When I get something working correctly, shall I register for an account and update your wiki page accordingly (once MySQL is working again)? -Jason Alan DeKok wrote:
Jason Antman wrote:
And in post-auth{}: ### snip ### if(control:Auth-Type == 'CSID'){ # Authorization happens here authorized_macs.authorize if(!ok){ reject
Uh... why? If the user is authenticated, you shouldn't be rejecting him.
If I put a "sql" line before this, it always logs with Access-Accept, since that's what authenticate{} ALWAYS returns, and the sql module is being called before . If I put a "sql" line after this, it never gets executed for "reject" statements...
Because you're doing it wrong. The whole point of accepting the user is that you *don't* reject them.
Change your rules to reject the user *before* they're accepted. The logging will then behave as you expect. It doesn't behave as you expect now, because you're rejecting them after you've accepted them. That makes no sense.
Why is the authorize statement in the post-auth { } section? That seems to be the cause of these problems...
So move it.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan DeKok wrote:
Because you're doing it wrong. The whole point of accepting the user is that you *don't* reject them.
Change your rules to reject the user *before* they're accepted. The logging will then behave as you expect. It doesn't behave as you expect now, because you're rejecting them after you've accepted them. That makes no sense.
Alan, thanks for the pointer, it works fine now. I just found out that the FreeRadius wiki is *not* publicly editable. Could whoever maintains it please update the Mac-Auth article at http://wiki.freeradius.org/Mac-Auth to remove the parts that Alan said "make no sense"? It's very liable to confuse people (like me) when the Official wiki has examples that are "wrong". Thanks, Jason Antman
On 03/29/2011 07:13 PM, Jason Antman wrote:
I just found out that the FreeRadius wiki is *not* publicly editable.
Too much spam :o(
Could whoever maintains it please update the Mac-Auth article at http://wiki.freeradius.org/Mac-Auth to remove the parts that Alan said "make no sense"?
The example on the wiki is quite complex, and not easy to follow at first. I've updated it with a couple of simpler examples to start with - a "just macauth" one, and a "macauth plus 802.1x" one. Could you have a look and see if they make more sense?
This makes MUCH more sense, thanks! Now the next (relatively new-to-radius) person won't end up as confused as I was. I have MAC auth working with a SQL data source and custom XLAT to check for some special field values in SQL, based on a somewhat custom schema (more from the one-row-per-MAC standpoint than using radcheck and radreply), as well as xlat to include a Username in the reply message. When I'm finished with it and have it working, I'll be more than willing to pass along my code. Thanks to you and Alan for clearing things up. -Jason Phil Mayers wrote:
On 03/29/2011 07:13 PM, Jason Antman wrote:
I just found out that the FreeRadius wiki is *not* publicly editable.
Too much spam :o(
Could whoever maintains it please update the Mac-Auth article at http://wiki.freeradius.org/Mac-Auth to remove the parts that Alan said "make no sense"?
The example on the wiki is quite complex, and not easy to follow at first.
I've updated it with a couple of simpler examples to start with - a "just macauth" one, and a "macauth plus 802.1x" one.
Could you have a look and see if they make more sense? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 03/29/2011 08:52 PM, Jason Antman wrote:
This makes MUCH more sense, thanks! Now the next (relatively new-to-radius) person won't end up as confused as I was.
I have MAC auth working with a SQL data source and custom XLAT to check for some special field values in SQL, based on a somewhat custom schema (more from the one-row-per-MAC standpoint than using radcheck and
Yeah, we do a similar thing with a database stored procedure to allocate an appropriate vlan by mac & location combo; it's basically along the lines of: update control { Tmp-String-0 := "%{sql:select .. from proc('%{Calling-Station-Id}')" } if (control:Tmp-String-0 =~ /...regexp for SQL result.../) { update reply { # vlan Tunnel-Private-Group-Id := "%{1}" Other-Stuff := "%{2}" } } FreeRadius is damn clever when you grasp it ;o)
radreply), as well as xlat to include a Username in the reply message. When I'm finished with it and have it working, I'll be more than willing to pass along my code.
Alan can probably give you a wiki account if you want to document it there.
participants (3)
-
Alan DeKok -
Jason Antman -
Phil Mayers