The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Martin Pauly <pauly AT hrz.uni-marburg.de>]

Hi,

Am 19.10.2018 um 08:48 schrieb Stefan Winter:
> "if user is from @newdeploymentrealm && EAP-Type == PEAP => proxy to the
> new server"
>
> Even if the realm of old and new deployment is identical - with the EAP
> type being part of the condition, you make sure that genuinely old
> accounts with EAP-TLS are authenticated on the old server, while new
> accounts are sent onwards to your new server. All when incoming from the
> same legacy deployment.
>
> The only complication with this is when the old and new realms are
> indeed identical - it can still work, but then EAP type negotiation
> happens on the old server, and you will have to enable "support" for
> PEAP in the first place to allow the client to actually select the EAP type.

this kind of processing fork does work reliably in freeradius.
Whats's more, in certain cases it does not even depend on different realms.
We (like some other German universities) currently run a setup where we
deliberately set the _outer_ identity in the supplicant config to some 
special value
and trigger the processing fork depending on the outer id of the request.
So you would have requests with
special AT common.realm.edu as opposed to
<anythingelse>@common.realm.edu

We use this to tackle an upcoming change of root cert: The "special" requests
are presented with the new cert, everyone else gets the old one.
Although Alan Buxey warned me of this kind of "hack", it has been working
pretty well so far (keep fingers crossed).

Good luck with this, your setup really looks pretty advanced
Martin

--
  Dr. Martin Pauly     Phone:  +49-6421-28-23527
  HRZ Univ. Marburg    Fax:    +49-6421-28-26994
  Hans-Meerwein-Str.   E-Mail: pauly AT HRZ.Uni-Marburg.DE
  D-35032 Marburg

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature