post-auth not being entered in inner-tunnel
Hi, I've got a number of FR 2.2.0 servers that invoke sql_log in the inner-tunnel post-auth in order to write user-name some other attributes into a back end mysql database server and it all works. If I've got non-eap requests coming in , the "default" site deals with it. If I've got eap-based requests coming in the inner-tunnel deals with them. About a week ago I downloaded the latest 2.2 code from git.freeradius, built that and upgraded one of my FR2.2 servers. Since then I can't see an invocation of post-auth within the inner-tunnel. I can see it for the "default" site but not the inner-tunnel. Everything else seems to work but not that. Same hardware platform, same config files just different FR code. I've generated two radius -X dumps, vsn220.log and vsn221.log on my test server. The only raw client accessing this server is the switch my mac is sitting on configured to do macauth and 802.1x on my ethernet port. By simply disconnecting and reconnecting my mac I've generated a macauth followed by an 802.1x auth. In both files you can see post-auth being invoked for the default site. but only the vsn220.log file has a corresponding post-auth for the inner-tunnel. It may be that there's something else I've configured wrong that is only showing up in van 2.2.1 (ish). Should I be sending these traces to the free radius list or is there another address I can email them to Rgds Alex
On 13.03.2013 12:46, Alex Sharaz wrote:
Hi,
I've got a number of FR 2.2.0 servers that invoke sql_log in the inner-tunnel post-auth in order to write user-name some other attributes into a back end mysql database server and it all works. If I've got non-eap requests coming in , the "default" site deals with it. If I've got eap-based requests coming in the inner-tunnel deals with them. About a week ago I downloaded the latest 2.2 code from git.freeradius, built that and upgraded one of my FR2.2 servers. Since then I can't see an invocation of post-auth within the inner-tunnel. I can see it for the "default" site but not the inner-tunnel. Everything else seems to work but not that. Same hardware platform, same config files just different FR code.
I've generated two radius -X dumps, vsn220.log and vsn221.log on my test server. The only raw client accessing this server is the switch my mac is sitting on configured to do macauth and 802.1x on my ethernet port. By simply disconnecting and reconnecting my mac I've generated a macauth followed by an 802.1x auth. In both files you can see post-auth being invoked for the default site. but only the vsn220.log file has a corresponding post-auth for the inner-tunnel.
It may be that there's something else I've configured wrong that is only showing up in van 2.2.1 (ish). Should I be sending these traces to the free radius list or is there another address I can email them to
Sounds weird. But again hard to tell without a radius -X output. Just send it here on the list, a complete request output, and maybe the relevant virtual-server configuration snippet Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
o.k. Attached are cut down versions of the log files inner-tunnel server = root@nasaaa3:/etc/freeradius/sites-enabled# cat inner-tunnel # inner-tunnel virtual server # # This virtual server is used to unwrap and process EAP requests - whether they # originate locally, or from the NRPS. # # Depending on the EAP type, requests may pass through this virtual server # multiple times - especially with EAP types involving a challenge/response, # or a TLS tunnel (PEAP, TTLS, MSCHAPv2...) # # as 17/12/12 - Added Session Timeout setting so people have to reauth # every 3600 seconds # # 18/12/12 - Wrapped a check round Session Timout to make sure it only gets # added to an Access-Accept # # 03/02/13 - Dont sql access-accept responses if user is nagios health check usr # server inner-tunnel { listen { # Where to listen ipaddr = 127.0.0.1 port = 18120 type = auth # Accounting packets do not contain EAP } authorize { # Parse the realm/username suffix # Allow AuthN modules to scan for the attributes they need and assign themse chap #mschap_default mschap # Make sure that the request is not proxied (i.e. if the user were to have p update control { Proxy-To-Realm := LOCAL } # Handle EAP-MSCHAP-v2 requests, plus set some EAP related attributes eap { ok = return } # Read in the users file files york_passwd if (Packet-Type == Access-Accept) { update reply { Session-Timeout := "3600" Termination-Action := "RADIUS-Request" } } if (request:Aruba-Location-Id) { update reply { York-Auth-Type := "wireless" York-Auth-Device := "%{Aruba-Location-Id}" York-Calling-Station-Id := "%{Calling-Station-Id}" } if (!(request:Realm == "NULL") && !(request:Realm == "york.ac.uk")) { update reply { York-Accept-Vlan := "Visiting Eduroam Users" } } } if ((request:NAS-Port-Type =~ /^Ethernet$/) ) { update reply { York-Auth-Device := "%{NAS-Identifier}" York-Auth-Device-Port := "%{NAS-Port-Id}" York-Calling-Station-Id := "%{Calling-Station-Id}" } } if ((request:NAS-Port-Type =~ /^Ethernet$/) && !(User-Name =~ /^[0-9A-F][0-9 update reply { York-Auth-Type := "dot1x" } } # # if we are sending a vlan we also need to add these two attributes # Put it here so that we cover both wired and wireless Vlan specification # if (reply:Tunnel-Private-Group-ID) { update reply { Tunnel-Type := VLAN Tunnel-Medium-Type := IEEE-802 } } # Has users account expired? expiration # Check for plaintext pap ################# # Don't really need these in a properly working system # # detail # auth_log reply_log ################ } # Note that all of these requests are wrapped in an if block - this is to reduce loa # from certain EAP types that cycle through this stage multiple times before a passw # is actually sent authenticate { # Handle plaintext passwords Auth-Type PAP { if ((EAP-Type == 1) || (EAP-Message =~ /^0x02..00061a..$/)) { noop } else { pap } } # Handle chap passwords Auth-Type CHAP { if ((EAP-Type == 1) || (EAP-Message =~ /^0x02..00061a..$/)) { noop } else { chap } } # Handle mschap passwords Auth-Type MS-CHAP { if ((EAP-Type == 1) || (EAP-Message =~ /^0x02..00061a..$/)) { noop } else { mschap { reject = 2 } if (reject) { mschap_default } } } # Inner message is also EAP eap } post-auth { update reply { User-Name := "%{User-Name}" } sql_log Post-Auth-Type REJECT { sql_log attr_filter.access_reject } # set_session_time # } # # # 11/02/13 - Not live yet # perl reply_log } session { # eduroam has no requirement for simultaneous usage checking } pre-proxy { # The inner tunnel should not be proxied pre_proxy_log } post-proxy { # The inner tunnel should not be proxied post_proxy_log eap } } # inner-tunnel server block On 13 Mar 2013, at 13:05, Olivier Beytrison <olivier@heliosnet.org> wrote:
On 13.03.2013 12:46, Alex Sharaz wrote:
Hi,
I've got a number of FR 2.2.0 servers that invoke sql_log in the inner-tunnel post-auth in order to write user-name some other attributes into a back end mysql database server and it all works. If I've got non-eap requests coming in , the "default" site deals with it. If I've got eap-based requests coming in the inner-tunnel deals with them. About a week ago I downloaded the latest 2.2 code from git.freeradius, built that and upgraded one of my FR2.2 servers. Since then I can't see an invocation of post-auth within the inner-tunnel. I can see it for the "default" site but not the inner-tunnel. Everything else seems to work but not that. Same hardware platform, same config files just different FR code.
I've generated two radius -X dumps, vsn220.log and vsn221.log on my test server. The only raw client accessing this server is the switch my mac is sitting on configured to do macauth and 802.1x on my ethernet port. By simply disconnecting and reconnecting my mac I've generated a macauth followed by an 802.1x auth. In both files you can see post-auth being invoked for the default site. but only the vsn220.log file has a corresponding post-auth for the inner-tunnel.
It may be that there's something else I've configured wrong that is only showing up in van 2.2.1 (ish). Should I be sending these traces to the free radius list or is there another address I can email them to
Sounds weird. But again hard to tell without a radius -X output. Just send it here on the list, a complete request output, and maybe the relevant virtual-server configuration snippet
Olivier --
Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, On Wed, Mar 13, 2013 at 04:09:55PM +0000, Alex Sharaz wrote:
On 13 Mar 2013, at 13:05, Olivier Beytrison <olivier@heliosnet.org> wrote:
On 13.03.2013 12:46, Alex Sharaz wrote:
coming in the inner-tunnel deals with them. About a week ago I downloaded the latest 2.2 code from git.freeradius, built that and upgraded one of my FR2.2 servers. Since then I can't see an invocation of post-auth within the inner-tunnel. I can see it for the "default" site but not the inner-tunnel. Everything else seems to work but not that. Same hardware platform, same config files just different FR code.
Sounds weird. But again hard to tell without a radius -X output. Just send it here on the list, a complete request output, and maybe the relevant virtual-server configuration snippet
I hacked around on master in September (see commits 5f03313da, 00cadac7 and c625bf173) to fix up auth.c so that inner-tunnel post-auth worked properly. It looks like Arran may have backported 5f03313da to 2.2 in commit a00c4432, which means that rad_postauth is called from event.c, rather than from auth.c Unfortunately, this also means that the inner-tunnel code needs fixing, as it then won't call post-auth at all. I'd suggest that either a00c4432 needs backing out, or 00cadac7 and need backporting as well. Cheers, 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 Wed, Mar 13, 2013 at 12:58:15PM -0400, Arran Cudbard-Bell wrote:
00cadac7
Defines the function rad_virtual_server, but doesn't call it from anywhere. Where should that be called? Was there another commit?
Grr, fatfinger paste bug :)
I'd suggest that either a00c4432 needs backing out, or 00cadac7 and need backporting as well.
should have read: I'd suggest that either a00c4432 needs backing out, or 00cadac7 and c625bf173 need backporting as well. There are three commits in series that all go together. Cheers! 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 13 Mar 2013, at 13:19, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
On Wed, Mar 13, 2013 at 12:58:15PM -0400, Arran Cudbard-Bell wrote:
00cadac7
Defines the function rad_virtual_server, but doesn't call it from anywhere. Where should that be called? Was there another commit?
Grr, fatfinger paste bug :)
I'd suggest that either a00c4432 needs backing out, or 00cadac7 and need backporting as well.
should have read:
I'd suggest that either a00c4432 needs backing out, or 00cadac7 and c625bf173 need backporting as well.
There are three commits in series that all go together.
Ok done. Most of it just came over cleanly. -Arran
so is that done as in post-auth in the inner-tunnel now works? Rgds Alex On 13 Mar 2013, at 20:14, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 13 Mar 2013, at 13:19, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
On Wed, Mar 13, 2013 at 12:58:15PM -0400, Arran Cudbard-Bell wrote:
00cadac7
Defines the function rad_virtual_server, but doesn't call it from anywhere. Where should that be called? Was there another commit?
Grr, fatfinger paste bug :)
I'd suggest that either a00c4432 needs backing out, or 00cadac7 and need backporting as well.
should have read:
I'd suggest that either a00c4432 needs backing out, or 00cadac7 and c625bf173 need backporting as well.
There are three commits in series that all go together.
Ok done. Most of it just came over cleanly.
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, Mar 14, 2013 at 10:10:28AM +0000, Phil Mayers wrote:
On 03/14/2013 09:36 AM, Alex Sharaz wrote:
so is that done as in post-auth in the inner-tunnel now works?
Should be. Please "git pull" and recompile and confirm.
It should fully work now. Previously, inner-tunnel post-auth reject was skipped, so inner post-auth was only called for success. Some confirmation would be useful - I haven't got time to check right now. Cheers, 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>
Yup works just fine thanks Rgds Alex On 14 Mar 2013, at 14:22, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
On Thu, Mar 14, 2013 at 10:10:28AM +0000, Phil Mayers wrote:
On 03/14/2013 09:36 AM, Alex Sharaz wrote:
so is that done as in post-auth in the inner-tunnel now works?
Should be. Please "git pull" and recompile and confirm.
It should fully work now. Previously, inner-tunnel post-auth reject was skipped, so inner post-auth was only called for success.
Some confirmation would be useful - I haven't got time to check right now.
Cheers,
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
participants (5)
-
Alex Sharaz -
Arran Cudbard-Bell -
Matthew Newton -
Olivier Beytrison -
Phil Mayers