Proxy EAP-TLS request after successful authorization with eap module
Hello, I am using v3.0.x branch and want to know is it possible to make proxy request to another freeradius/radius server after proxy radius server successfully handle request in eap module? In general I want to know is it possible to implement the next scheme: [user request eap-tls] | [freeradius proxy server] (check certificate; if certificate is good, read certificate values; proxy call home radius server, if not reject) | [freeradius home server] (home server set additional attributes like port speed) My simplified configuration looks like this server test_virtual_site { authorize { eap debug_all #:Need-Remote-Call - custom radius attribute added to dictionary file if (&reply:Need-Remote-Call = 'yes'){ update control { &Proxy-To-Realm := LOCAL } } } authenticate { eap } post_auth { debug_all } } and inner eap-tls virtual site looks like this server check-eap-tls { authorize { update config { &Auth-Type := Accept } } } In this configuration after check-eap-tls virtual site accept request, test_virtual_site jump to post-auth section, and debug_all and update control instructions are not executing. If I not set Auth-Type := Accept in check-eap-tls virtual site, eap module in debug log inform me what eap virtual site reject user certificate. And if I set Proxy-To-Realm attribute inside check-eap-tls virtual site proxy request to home server does not happen.
On 17 Oct 2017, at 18:46, work vlpl <thework.vlpl@gmail.com> wrote:
Hello, I am using v3.0.x branch and want to know is it possible to make proxy request to another freeradius/radius server after proxy radius server successfully handle request in eap module?
Should be possible, just call eap in authorise with method override. i.e. authorize { eap if (&control:Auth-Type == EAP) { eap.authenticate } } The trick there is determining when EAP has actually finished. I'd look and see if the return code of eap.authenticate changes on the final round after the user has been accepted, and use that as the trigger to proxy the final request to an upstream server. eap.authenticate if (ok) { update control { Proxy-To-Realm := 'foo' } } If the return code doesn't change, then the outcome might be available somewhere else, but that'd require some digging. I don't think the inner tunnel runs for EAP-TLS? At least there's no reason for it to. The other thing would be to check and see if the cert authorisation virtual server runs right before the Accept is returned... It might. In which case you can stick your Need-Remote-Call in the outer.session-state list and check for it in the outer server. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Oct 17, 2017, at 3:26 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Should be possible, just call eap in authorise with method override.
i.e.
authorize { eap
if (&control:Auth-Type == EAP) { eap.authenticate } }
Oh god... that might actually work. You'd also have to delete the Auth-Type := EAP, too. And maybe add an "Auth-Type noop", with a "noop" thing there. Because the server really does expect to run an authenticate method.
The trick there is determining when EAP has actually finished. I'd look and see if the return code of eap.authenticate changes on the final round after the user has been accepted, and use that as the trigger to proxy the final request to an upstream server.
eap.authenticate if (ok) { update control { Proxy-To-Realm := 'foo' } }
That should work. The EAP module returns "ok" only when the user is authenticated. The other problem is that the reply from the home server will over-ride the reply from the EAP module. So you have to cache the EAP reply (just one EAP-Message), and re-add it after you get the reply from the home server. I'll see if I can do some testing today...
If the return code doesn't change, then the outcome might be available somewhere else, but that'd require some digging.
I don't think the inner tunnel runs for EAP-TLS? At least there's no reason for it to.
It's allowed for identity privacy. i.e. use an anonymous outer ID, and then send the certificate via the inner-tunnel. Alan DeKok.
On 17 October 2017 at 13:26, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
...
Should be possible, just call eap in authorise with method override.
i.e.
authorize { eap
if (&control:Auth-Type == EAP) { eap.authenticate } }
I tried the next config, like you suggested authorize { eap if (&control:Auth-Type == EAP) { eap.authenticate } eap.authenticate if (ok) { debug_all update control { Proxy-To-Realm := 'testing-realm' } } } and got this in debug log server tls_only { (6) session-state: No cached attributes (6) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/tls_only (6) authorize { (6) update request { (6) Supplicant-User-Name := TLS-Client-Cert-Common-Name -> 'changed_1' (6) } # update request = noop (6) update config { (6) &Auth-Type := Accept (6) } # update config = noop (6) } # authorize = noop (6) Found Auth-Type = Accept (6) Auth-Type = Accept, accepting the user (6) } # server tls_only (6) Virtual server sending reply (6) eap_tls: caching TLS-Cert-Serial := "f4f7b543fa1eaa80" (6) eap_tls: caching TLS-Cert-Expiration := "370806185333Z" (6) eap_tls: caching TLS-Cert-Subject := "/CN=CHANGED" (6) eap_tls: caching TLS-Cert-Issuer := "/CN=CHANGED" (6) eap_tls: caching TLS-Cert-Common-Name := "CHANGED" (6) eap_tls: caching TLS-Client-Cert-Serial := "changed" (6) eap_tls: caching TLS-Client-Cert-Expiration := "271017150656Z" (6) eap_tls: caching TLS-Client-Cert-Subject := "/C=US/L=Secure Wi-Fi/O=example.com/CN=changed_1" (6) eap_tls: caching TLS-Client-Cert-Issuer := "/CN=changed" (6) eap_tls: caching TLS-Client-Cert-Common-Name := "changed_1" (6) eap_tls: Failed to find 'persist_dir' in TLS configuration. Session will not be cached on disk. (6) eap: Sending EAP Success (code 3) ID 6 length 4 (6) eap: Freeing handler tls: Freeing cached session VPs (6) [eap.authenticate] = ok (6) } # if (&control:Auth-Type == EAP) = ok (6) eap: ERROR: rlm_eap (EAP): No EAP session matching state 0x8920cc6c8c26c12e (6) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request (6) eap: Failed in handler (6) [eap.authenticate] = invalid (6) } # authorize = invalid (6) Using Post-Auth-Type Reject And also I tried delete Auth-Type what suggested by Alan DeKok
On 17 October 2017 at 17:50, Alan DeKok <aland@deployingradius.com> wrote:
Oh god... that might actually work.
You'd also have to delete the Auth-Type := EAP, too. And maybe add an "Auth-Type noop", with a "noop" thing there. Because the server really does expect to run an authenticate method.
authorize { eap if (&control:Auth-Type == EAP) { update control { Auth-Type !* ANY } eap.authenticate } eap.authenticate if (ok) { debug_all update control { Proxy-To-Realm := 'testing-realm' } } } This also not helped. What else can I try, Vladimir
On Oct 17, 2017, at 12:06 PM, work vlpl <thework.vlpl@gmail.com> wrote:
I tried the next config, like you suggested
That's not what was suggested. It helps to have some understanding of how the server works.
authorize { eap
if (&control:Auth-Type == EAP) { eap.authenticate }
eap.authenticate
Running "eap.authenticate" twice is not a good idea. I'm not going to show how to do it, because I think this is an esoteric configuration, and it requires some understanding to get right. Alan DeKok.
On 17 October 2017 at 23:14, Alan DeKok <aland@deployingradius.com> wrote:
That's not what was suggested. It helps to have some understanding of how the server works.
I am sorry for that misunderstanding By looking on debug log I think eap module must set Auth-Type, and nothing can be executed after eap module. Is this correct? If I use this config authorize { eap if(ok) { debug_all } else { debug_all } } there is no debug_all output in log ---not set Auth-Type version of tls_only virtual site--- WARNING: Outer and inner identities are the same. User privacy is compromised. (6) server tls_only { (6) session-state: No cached attributes (6) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/tls_only (6) authorize { (6) update reply { (6) &Auth-Type := Accept (6) } # update reply = noop (6) } # authorize = noop (6) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject (6) Failed to authenticate the user (6) Using Post-Auth-Type Reject (6) Post-Auth-Type sub-section not found. Ignoring. (6) } # server tls_only (6) Virtual server sending reply (6) Auth-Type := Accept (6) eap_tls: Certificate rejected by the virtual server (6) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed (6) eap: Sending EAP Failure (code 4) ID 6 length 4 (6) eap: Failed in EAP select --set Auth-Type version of tls_only virtual site:- WARNING: Outer and inner identities are the same. User privacy is compromised. (6) server tls_only { (6) session-state: No cached attributes (6) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/tls_only (6) authorize { (6) update config { (6) &Auth-Type := Accept (6) } # update config = noop (6) } # authorize = noop (6) Found Auth-Type = Accept (6) Auth-Type = Accept, accepting the user (6) } # server tls_only (6) Virtual server sending reply (6) eap_tls: caching TLS-Cert-Serial := "f4f7b543fa1eaa80" (6) eap_tls: caching TLS-Cert-Expiration := "370806185333Z" (6) eap_tls: caching TLS-Cert-Subject := "/CN=CHANGED ca" (6) eap_tls: caching TLS-Cert-Issuer := "/CN=CHANGED ca" (6) eap_tls: caching TLS-Cert-Common-Name := "CHANGED ca" (6) eap_tls: caching TLS-Client-Cert-Serial := "9cd3e44502ae747b" (6) eap_tls: caching TLS-Client-Cert-Expiration := "271017150656Z" (6) eap_tls: caching TLS-Client-Cert-Subject := "/C=US/L=Some wifi Wi-Fi/O=example.com/CN=CHANGED" (6) eap_tls: caching TLS-Client-Cert-Issuer := "/CN=CHANGED ca" (6) eap_tls: caching TLS-Client-Cert-Common-Name := "CHANGED" (6) eap_tls: Failed to find 'persist_dir' in TLS configuration. Session will not be cached on disk. (6) eap: Sending EAP Success (code 3) ID 6 length 4 (6) eap: Freeing handler tls: Freeing cached session VPs (6) [eap] = ok (6) } # authenticate = ok
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
work vlpl