Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
Hi Sami, We made progress with our setup thanks to your previous tips. We now have following setup simplyfied a bit: Handler TunnelledByPEAP=1 Identifier TunnelledByPEAP=1 AuthByPolicy ContinueWhileAccept AuthBy SQLauthenticate AuthBy INTERNALextractFunnyStuffFromRequest AuthBy SQLauthorize /Handler Handler Identifier Outer AuthBy FILE /Handler the issue we are currently chasing is that the customer also wants failed authentications to proceed into SQLauthorize so he can possible put people into a walled garden with specific reply attributes. The issue seems to be that when MS-CHAP2 fails in TunneledByPeap it seems to kill the EAP session and authentication terminates. Subsequent packets are not forwarded to the tunneled handler by the outer handler. Do you have a suggestion how to accomplish authorization after failed chap authentication. Terveisin Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
Hello Christian,
MSCHAPv2 is mutual authentication protocol where client requires
response from server. If the server doesn't send correct response client
will terminate connection.
So server can not just decide to accept authentication like in PAP case.
I think that it is not possible to build walled garden solution with
that protocol.
If you use for example PEAP/GTC or EAP-TTLS/PAP you can use AuthBy GROUP
to group sequences and use different policy inside them.
for example like this:
Handler TunnelledByPEAP=1
Identifier TunnelledByPEAP=1
AuthByPolicy ContinueWhileAccept
AuthBy GROUP
AuthByPolicy ContinueWhileReject
AuthBy SQLauthenticate
AuthBy INTERNAL
AuthHook sub {my $p = $_[0];\
$p-add_attr('X-OSC-Auth-Status', 'Rejected');\
return $main::ACCEPT}
/AuthBy
/AuthBy
AuthBy INTERNALextractFunnyStuffFromRequest
AuthBy SQLauthorize
/Handler
In this example the inner AuthBy INTERNAL will change reject to accept
and mark it with vendor specific attribute that you can use in later
INTERNAL to determine if authentication was successful or not.
Best Regards,
Sami
On 02/24/2015 01:12 PM, Christian Kratzer wrote:
Hi Sami,
We made progress with our setup thanks to your previous tips.
We now have following setup simplyfied a bit:
Handler TunnelledByPEAP=1
Identifier TunnelledByPEAP=1
AuthByPolicy ContinueWhileAccept
AuthBy SQLauthenticate
AuthBy INTERNALextractFunnyStuffFromRequest
AuthBy SQLauthorize
/Handler
Handler
Identifier Outer
AuthBy FILE
/Handler
the issue we are currently chasing is that the customer also wants
failed authentications to proceed into SQLauthorize so he can possible
put people into a walled garden with specific reply attributes.
The issue seems to be that when MS-CHAP2 fails in TunneledByPeap it
seems to kill the EAP session and authentication terminates.
Subsequent packets are not forwarded to the tunneled handler by the
outer handler.
Do you have a suggestion how to accomplish authorization after failed
chap authentication.
Terveisin
Christian
--
Sami Keski-Kasari sam...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
What we've seen is that if a Windows client does EAP authentication, regardless which one, and it fails it doesn't try to do a DHCP request even if you reply a radius success and vlan attributes to the switch. On 2015-02-24 12:12, Christian Kratzer wrote: Hi Sami, We made progress with our setup thanks to your previous tips. We now have following setup simplyfied a bit: Handler TunnelledByPEAP=1 Identifier TunnelledByPEAP=1 AuthByPolicy ContinueWhileAccept AuthBy SQLauthenticate AuthBy INTERNALextractFunnyStuffFromRequest AuthBy SQLauthorize /Handler Handler Identifier Outer AuthBy FILE /Handler the issue we are currently chasing is that the customer also wants failed authentications to proceed into SQLauthorize so he can possible put people into a walled garden with specific reply attributes. The issue seems to be that when MS-CHAP2 fails in TunneledByPeap it seems to kill the EAP session and authentication terminates. Subsequent packets are not forwarded to the tunneled handler by the outer handler. Do you have a suggestion how to accomplish authorization after failed chap authentication. Terveisin Christian *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
Hi Sami,
On Tue, 24 Feb 2015, Sami Keski-Kasari wrote:
Hello Christian,
MSCHAPv2 is mutual authentication protocol where client requires
response from server. If the server doesn't send correct response client
will terminate connection.
So server can not just decide to accept authentication like in PAP case.
I think that it is not possible to build walled garden solution with
that protocol.
Thanks. That makes sense. I forgot about the mutality in CHAP.
Greetings
Christian
If you use for example PEAP/GTC or EAP-TTLS/PAP you can use AuthBy GROUP
to group sequences and use different policy inside them.
for example like this:
Handler TunnelledByPEAP=1
Identifier TunnelledByPEAP=1
AuthByPolicy ContinueWhileAccept
AuthBy GROUP
AuthByPolicy ContinueWhileReject
AuthBy SQLauthenticate
AuthBy INTERNAL
AuthHook sub {my $p = $_[0];\
$p-add_attr('X-OSC-Auth-Status', 'Rejected');\
return $main::ACCEPT}
/AuthBy
/AuthBy
AuthBy INTERNALextractFunnyStuffFromRequest
AuthBy SQLauthorize
/Handler
In this example the inner AuthBy INTERNAL will change reject to accept
and mark it with vendor specific attribute that you can use in later
INTERNAL to determine if authentication was successful or not.
Best Regards,
Sami
On 02/24/2015 01:12 PM, Christian Kratzer wrote:
Hi Sami,
We made progress with our setup thanks to your previous tips.
We now have following setup simplyfied a bit:
Handler TunnelledByPEAP=1
Identifier TunnelledByPEAP=1
AuthByPolicy ContinueWhileAccept
AuthBy SQLauthenticate
AuthBy INTERNALextractFunnyStuffFromRequest
AuthBy SQLauthorize
/Handler
Handler
Identifier Outer
AuthBy FILE
/Handler
the issue we are currently chasing is that the customer also wants
failed authentications to proceed into SQLauthorize so he can possible
put people into a walled garden with specific reply attributes.
The issue seems to be that when MS-CHAP2 fails in TunneledByPeap it
seems to kill the EAP session and authentication terminates.
Subsequent packets are not forwarded to the tunneled handler by the
outer handler.
Do you have a suggestion how to accomplish authorization after failed
chap authentication.
Terveisin
Christian
--
Christian Kratzer CK Software GmbH
Email: c...@cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
