Hi, Okay, I munched over the source code and I'm guessing I'm being a crettin, but I'm hoping you can tell me what I'm doing wrong. If you use the 'virtual_server' functionality in the ttls{} section of eap.conf, everything works great if you get an Access-Accept from the inner virtual server ('auth' for me). When I say "works great", I mean the 'post-auth' section of the EAP calling ('auth-eap') virtual server is munched through. However, if 'Access-Reject' is returned then 'post-auth' is not parsed and it bombs immediently back out to the to outer virtual server's ('dot1x') post-proxy section. My convoluted (for reasons of 'code' reuse) virtual server approach is: dot1x -> auth-eap -> auth Down in 'auth' is where all the LDAP magic to check user credentials is done, 'auth-eap' is dead simple: ---- server auth-eap { authorize { eap } authenticate { eap } post-auth { # if 'eap' fails, post-auth does not get run # and we have no way to get User-Name/Reply-Message :( # probably a bug I should report at some stage #Post-Auth-Type Reject { #} # slip some goodies upstream (goes into 'control' so # we can get the original request username if need be) update outer.control { User-Name := "%{reply:User-Name}" } # if we put this into 'control' then we get two # Auth-Type's (although it works), if we put it # into 'reply' it gets filtered update outer.request { Auth-Type := "%{%{reply:Auth-Type}:-%{Auth-Type}}" EAP-Type := "%{EAP-Type}" } } } ---- Any suggestions, it would be nice if on Access-Reject that post-auth section was passed in 'auth-eap'. Of course if you want config files and/or logs, do ask. Cheers -- Alexander Clouter .sigmonster says: Pushing 30 is exercise enough.
Okay, I munched over the source code and I'm guessing I'm being a crettin, but I'm hoping you can tell me what I'm doing wrong.
If you use the 'virtual_server' functionality in the ttls{} section of eap.conf, everything works great if you get an Access-Accept from the inner virtual server ('auth' for me). When I say "works great", I mean the 'post-auth' section of the EAP calling ('auth-eap') virtual server is munched through. However, if 'Access-Reject' is returned then 'post-auth' is not parsed and it bombs immediently back out to the to outer virtual server's ('dot1x') post-proxy section.
Try testing the reply:Packet-Type there. If it's Access-Reject do those updates. Ivan Kalik Kalik Informatika ISP
Ivan Kalik <tnt@kalik.net> wrote:
Okay, I munched over the source code and I'm guessing I'm being a crettin, but I'm hoping you can tell me what I'm doing wrong.
If you use the 'virtual_server' functionality in the ttls{} section of eap.conf, everything works great if you get an Access-Accept from the inner virtual server ('auth' for me). When I say "works great", I mean the 'post-auth' section of the EAP calling ('auth-eap') virtual server is munched through. However, if 'Access-Reject' is returned then 'post-auth' is not parsed and it bombs immediently back out to the to outer virtual server's ('dot1x') post-proxy section.
Try testing the reply:Packet-Type there. If it's Access-Reject do those updates.
That's the problem, I cannot test *anything* there. Even if I make the authenticate section: Auth-Type EAP { eap if ( .... ) { } } That 'if ()' block never gets checked. To me it looks like it should go into 'post-auth {}' and then nosey for a 'Post-Auth-Type Reject', but it does not do that either...annoyingly. Not the end of the world, but it would let me see which usernames are failing to login (as my logging occurs in 'dot1x' I only see there '@example.com' and get 'auth' and 'auth-eap' to pass up the User-Name to the outer virtual server). Cheers -- Alexander Clouter .sigmonster says: Do, or do not; there is no try.
Alexander Clouter wrote:
If you use the 'virtual_server' functionality in the ttls{} section of eap.conf, everything works great if you get an Access-Accept from the inner virtual server ('auth' for me). When I say "works great", I mean the 'post-auth' section of the EAP calling ('auth-eap') virtual server is munched through. However, if 'Access-Reject' is returned then 'post-auth' is not parsed and it bombs immediently back out to the to outer virtual server's ('dot1x') post-proxy section.
Yes.
Any suggestions, it would be nice if on Access-Reject that post-auth section was passed in 'auth-eap'.
That takes source code patches. Part of the issue is that the server *pretends* that the inner session is a separate authentication request. But actually treating it as separate is hard. So the TTLS && PEAP module fake it, and sometimes don't do a good job. This involves copying some more code from the server core into the modules. Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So you have two issues: 1) Post-Auth REJECT isn't processed in the inner tunnel 2) Authenticate->EAP does not process additional statements after EAP has rejected the user. Regarding 1: I've discussed this with Alan before. Not running Post-Auth in the inner server probably is a bug. It's certainly not intuitive behavior. But you can work around it. Regarding 2: Good news and bad news. Yes, that's normal, bug free behavior. Override the rcode for EAP not to be reject e.g. inner-eap { invalid = 1 fail = 1 reject = 1 } Bad news, I believe there's a logic error with how rcodes propagate through unlang stanzas. You may find an If or Update statement rejecting the user at a later time. I reviewed the source code with Alan a while back and he said there'd probably be a fix in a later versions. Arran - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrF8P4ACgkQcaklux5oVKLYpACeJCKMKSri09e54jE4uxCjggmR qcwAnjrt/+ZQ+FiegumyXqmCuxvcZtWB =8emf -----END PGP SIGNATURE-----
Hi, I was expecting a reply from you, what took you so long! :) Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk> wrote:
So you have two issues: 1) Post-Auth REJECT isn't processed in the inner tunnel
2) Authenticate->EAP does not process additional statements after EAP has rejected the user.
Regarding 1: I've discussed this with Alan before. Not running Post-Auth in the inner server probably is a bug. It's certainly not intuitive behavior. But you can work around it.
Good good, thought I was doing something wholly stupid.
Regarding 2: Good news and bad news. Yes, that's normal, bug free behavior. Override the rcode for EAP not to be reject e.g.
Right, there I was strange then. I rejigged things....
inner-eap { invalid = 1 fail = 1 reject = 1 }
...and realised once I saw this bit I can lower the load on the LDAP server by 90% with your advice. Should have remembered this trick eariler, cheers :)
Bad news, I believe there's a logic error with how rcodes propagate through unlang stanzas. You may find an If or Update statement rejecting the user at a later time. I reviewed the source code with Alan a while back and he said there'd probably be a fix in a later versions.
...and this explains the quirk I stumbled on with my rejigging. I owe you a beer, tokens redeemable in April. :) Cheers -- Alexander Clouter .sigmonster says: Life is difficult because it is non-linear.
participants (4)
-
Alan DeKok -
Alexander Clouter -
Arran Cudbard-Bell -
Ivan Kalik