[RADIATOR] EAP-TTLS: How to forward inner requests to different backends depending on the inner authentication? [EXT]

[Martin Burton]

Hi Matti,

To my eyes that *looks* like it would work if you changed the
AuthByPolicy from ContinueAlways to ContinueUntilAccept.

With ContinueAlways even if the request was accepted by the MSCHAPv2
group, the request would still be processed by the PAP group which could
reject it.  The last result is the one that is ultimately returned.

I don't have a config that chains groups together that way however, so
I'm not sure whether the overall logic flow works the way it looks.

Hope that helps,

Martin.

On 13/01/2020 14:14, Matti Saarinen wrote:
> 
> Hello!
> 
> We have some clients that use EAP-TTLS+PAP and others that use
> EAP-TTLS+MSCHAPv2. So far, RADIATOR has stripped of the EAP-TTLS and
> forwarded the inner requests to Windows RADIUS servers and everything
> has worked. Now, the Widows admins want to drop PAP support and I would
> need to configure RADIATOR to forward PAP requests to different backend.
> This is probably a very simple to thing to accomplish but I haven't had
> the skills with which to write a working configuration. Below, is what
> I'm trying to do. I hope that if the backend MSCHAPv2 doesn't accep the
> request RADIATOR will move to the next one.
> 
> 
> <Handler TunnelledByTTLS=1>
> 
>         Identifier EAP-TTLS
>         AuthByPolicy ContinueAlways
> 
>         <AuthBy GROUP>
>           # MSCHAPv2 should be processed here
>           <AuthBy RADIUS>
>                   ### PacketTrace
>                   Identifier TTLS-MSCHAPv2
>                   LocalAddress n.n.n.n
>                   Host ad1
>                   FailureBackoffTime 300
>                   RetryTimeout 3
>                   Secret *
>                   Retries 0
>                   Synchronous
>           </AuthBy>
>         </AuthBy>
>         <AuthBy GROUP>
>           # PAP should be processed here
>           <AuthBy RADIUS>
>                   ### PacketTrace
>                   RewriteUsername s/^([^@]+).*/$1/
>                   Identifier TTLS-PAP-R1
>                   Host r1
>                   AuthPort 1812
>                   AcctPort 1813
>                   Secret *
>                   RetryTimeout 3
>                   Retries 0
>                   Synchronous
>           </AuthBy>
>           <AuthBy RADIUS>
>                   ### PacketTrace
>                   Identifier TTLS-PAP-R2
>                   RewriteUsername s/^([^@]+).*/$1/
>                   Host r2
>                   AuthPort 1812
>                   AcctPort 1813
>                   Secret *
>                   RetryTimeout 3
>                   Retries 0
>                   Synchronous
>           </AuthBy>
>         </AuthBy>
> 
> </Handler>
> 
> 
> 
> 
> // Matti
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.open.com.au_mailman_listinfo_radiator&d=DwICAg&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=Pmm7Evpg3H5MI4_C7ltAOg&m=N_OiiJaZRDhgtxY8JHxt6GguuKPhtlfPZnqMDs2K81U&s=hxeZKjaWvAe-3uDbirquvfGp0WH4ufMkdgEg0cCBFfc&e= 
> 

-- 
Martin Burton
Principal Systems Administrator            \\\|||///
Infrastructure Team                       \\  ^ ^  //
Wellcome Sanger Institute                  (  6 6  )
-----------------------------------------oOOo-(_)-oOOo---
t: +44 (0)1223 496945             http://www.sanger.ac.uk
Extreme Networks Specialist:      a1780000003uG1BAAU

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20200113/b31ae0b4/attachment.sig>