deployment with two completely different sets of certificates
Dear List, I am considering use case with two completely different sets of certificates (different keys, certificates signed by different CAs). First, original set, will be used for clients without the realm and clients from old.realm. The new set, signed by well-know CA, will be used for TTLS-EAP and PEAP authentications only for the new.realm. If such a scenario requires deploying anther instance of FreeRADIUS, then please let me know, but most likely current instance could be configured to handle it. So far I have extended mods-enabled/eap and have there: eap eap1 { old realm / without realm settings } eap eap2 { new realm settings } eap { old realm / without realm settings } then added to sites-enabled/old.realm: if ((User-Name =~ /new\.realm$/) || ( Inner-Realm-Name =~ /new\.realm$/)) { update control { Auth-Type := eap2 } } but the authentications though successful, are still handled by eap1: (0) suffix: Checking for suffix after "@" (0) suffix: Looking up realm "new.realm" for User-Name = "anonymous@new.realm" (0) suffix: Found realm "new.realm" (0) suffix: Adding Stripped-User-Name = "anonymous" (0) suffix: Adding Realm = "new.realm" (0) suffix: Authentication realm is LOCAL (0) [suffix] = ok (0) eap1: Peer sent EAP Response (code 2) ID 130 length 29 (0) eap1: EAP-Identity reply, returning 'ok' so we can short-circuit the rest of authorize (0) [eap1] = ok (0) } # authorize = ok (0) Found Auth-Type = eap2 (0) Found Auth-Type = eap1 (0) ERROR: Warning: Found 2 auth-types on request for user 'anonymous' (0) # Executing group from file /usr/local/etc/raddb/sites-enabled/old.realm (0) authenticate { (0) eap1: Peer sent packet with method EAP Identity (1) (0) eap1: Calling submodule eap_peap to process data (0) eap_peap: (TLS) Initiating new session (0) eap1: Sending EAP Request (code 1) ID 131 length 6 (0) eap1: EAP session adding &reply:State = 0x16f700fc167419f8 (0) [eap1] = handled (0) } # authenticate = handled (0) Using Post-Auth-Type Challenge So I am stuck. Please, any clues helping to proceed this further will be appreciated. Cheers ! -- Marek Zarychta
On 07/11/2023 20:33, Marek Zarychta wrote:
So far I have extended mods-enabled/eap and have there:
eap eap1 { old realm / without realm settings } eap eap2 { new realm settings } eap { old realm / without realm settings }
"eap" is just a duplicate of "eap1" then? It sounds like you don't need it.
then added to sites-enabled/old.realm:
if ((User-Name =~ /new\.realm$/) || ( Inner-Realm-Name =~ /new\.realm$/)) {
You don't have access to any inner details in the outer section, so that won't work.
update control { Auth-Type := eap2 } }
No, don't set Auth-Type. All the documentation says to never set Auth-Type. Call the appropriate eap module, something like split_username_nai if (&Stripped-User-Domain == "new.realm") { eap2 { ok = return } } else { eap1 { ok = return } } and comment out the existing "eap" call. You'll need to add "eap1" and "eap2" to the authenticate{} section, too. And also copy sites-enabled/inner-tunnel to two different files, and configure the eap modules to use their own particular one that calls the appropriate eap1/2 module as well.
but the authentications though successful, are still handled by eap1:
Yes, beacuse you're modifying Auth-Type when the eap module should be doing it.
So I am stuck. Please, any clues helping to proceed this further will be appreciated.
Don't try and use one shared eap module, you need to make sure everything is split into two and always calls the appropriate one. -- Matthew
W dniu 8.11.2023 o 10:37, Matthew Newton via Freeradius-Users pisze:
On 07/11/2023 20:33, Marek Zarychta wrote:
So far I have extended mods-enabled/eap and have there:
eap eap1 { old realm / without realm settings } eap eap2 { new realm settings } eap { old realm / without realm settings }
"eap" is just a duplicate of "eap1" then? It sounds like you don't need it.
then added to sites-enabled/old.realm:
if ((User-Name =~ /new\.realm$/) || ( Inner-Realm-Name =~ /new\.realm$/)) {
You don't have access to any inner details in the outer section, so that won't work.
update control { Auth-Type := eap2 } }
No, don't set Auth-Type. All the documentation says to never set Auth-Type.
Call the appropriate eap module, something like
split_username_nai
if (&Stripped-User-Domain == "new.realm") { eap2 { ok = return } } else { eap1 { ok = return } }
and comment out the existing "eap" call.
You'll need to add "eap1" and "eap2" to the authenticate{} section, too. And also copy sites-enabled/inner-tunnel to two different files, and configure the eap modules to use their own particular one that calls the appropriate eap1/2 module as well.
but the authentications though successful, are still handled by eap1:
Yes, beacuse you're modifying Auth-Type when the eap module should be doing it.
So I am stuck. Please, any clues helping to proceed this further will be appreciated.
Don't try and use one shared eap module, you need to make sure everything is split into two and always calls the appropriate one.
Thank you Matthew, your tips were invaluable as always. The configuration was fixed and now the whole solution works as intended. -- Marek Zarychta
participants (2)
-
Marek Zarychta -
Matthew Newton