What's the recommended way to achieve this? I need to alter outer and inner identity: - if outer identity is empty then alter it to "anon@domain.tld" - if a domain is missing in inner identity then add it (so username will become username@domain.tld) I already tried this for outer identity: operator_name = "domain.tld" authorize { linelog_recv_request split_username_nai if (noop || !&Stripped-User-Domain) { #reject update request { Stripped-User-Domain := "${operator_name}" Stripped-User-Name := "anon" } } I am getting ERROR: EAP-Identity Unknown.
On Aug 6, 2019, at 10:43 AM, Marek Des <desmarek1@gmail.com> wrote:
What's the recommended way to achieve this?
I need to alter outer and inner identity:
Don't do that. Altering the identities will break EAP.
update request { Stripped-User-Domain := "${operator_name}" Stripped-User-Name := "anon" } }
Setting Stripped-User-Name is fine.
I am getting ERROR: EAP-Identity Unknown.
You can't alter the EAP-Identity field. Perhaps you could explain why you think this is necessary. Alan DeKok.
I need to handle to different realms: 1) realm: domain.tld, username: user@domain.tld, EAP + MSCHAPv2 + LDAP 2) realm: empty, username: user, EAP + MSCHAPv2 + LDAP Do I need to run 2 different virtual servers (2x outer + 2x inner or 1x outer + 2x inner)? On Tue, Aug 6, 2019 at 5:17 PM Alan DeKok <aland@deployingradius.com> wrote:
On Aug 6, 2019, at 10:43 AM, Marek Des <desmarek1@gmail.com> wrote:
What's the recommended way to achieve this?
I need to alter outer and inner identity:
Don't do that.
Altering the identities will break EAP.
update request { Stripped-User-Domain := "${operator_name}" Stripped-User-Name := "anon" } }
Setting Stripped-User-Name is fine.
I am getting ERROR: EAP-Identity Unknown.
You can't alter the EAP-Identity field.
Perhaps you could explain why you think this is necessary.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Aug 11, 2019, at 4:04 AM, Marek Des <desmarek1@gmail.com> wrote:
I need to handle to different realms: 1) realm: domain.tld, username: user@domain.tld, EAP + MSCHAPv2 + LDAP 2) realm: empty, username: user, EAP + MSCHAPv2 + LDAP
Please be *specific*. I have no idea what you mean by "handle different realms"
Do I need to run 2 different virtual servers (2x outer + 2x inner or 1x outer + 2x inner)?
To do WHAT? If you want to authenticate users from multiple domains at the same time, the server can do that. Just define all of the realms in proxy.conf. The server will figure it out, and will do the right thing. realm example.com { # empty == "my realm" } This is extensively documented in the proxy.conf file. Alan DeKok.
Well, about empty realm - I mean this: 1) outer identity: empty 2) inner identity: username I need to authenticate two kind of users: 1) ones with credentials above 2) eduroam The only difference is in outer and inner identity. The both setups use EAP + MSCHAPv2 and OpenLDAP. I am trying to handle those two kind of users in single virtual server and it doesn't work - it says it's proxying request to localhost and that's it. proxy.conf: realm LOCAL { authhost = localhost:1812 accthost = localhost:1813 secret = testing123 nostrip } realm "domain.tld" { authhost = localhost:1812 accthost = localhost:1813 secret = testing123 nostrip } realm NULL { authhost = localhost:1812 accthost = localhost:1813 secret = testing123 nostrip } realm "~.+$" { auth_pool = pool_eduroam nostrip } Virtual server for outer identity: authorize { linelog_recv_request split_username_nai #if (noop || !&Stripped-User-Domain) { # reject #} ######################################################################## if ((!&Stripped-User-Domain) || (&Stripped-User-Domain == "")) { update { control:Proxy-To-Realm := 'domain.tld' } return } Virtual server for inner identity: authorize { split_username_nai #if (noop || (&Stripped-User-Domain && (&outer.Stripped-User-Domain != &Stripped-User-Domain))) { # reject #} if ( (!&Stripped-User-Domain) || (&Stripped-User-Domain =~ /domain.tld/) || (&Stripped-User-Domain == "")) { ldap } update { &outer.session-state:Stripped-User-Name := &Stripped-User-Name } On Sun, Aug 11, 2019 at 1:46 PM Alan DeKok <aland@deployingradius.com> wrote:
On Aug 11, 2019, at 4:04 AM, Marek Des <desmarek1@gmail.com> wrote:
I need to handle to different realms: 1) realm: domain.tld, username: user@domain.tld, EAP + MSCHAPv2 + LDAP 2) realm: empty, username: user, EAP + MSCHAPv2 + LDAP
Please be *specific*. I have no idea what you mean by "handle different realms"
Do I need to run 2 different virtual servers (2x outer + 2x inner or 1x outer + 2x inner)?
To do WHAT?
If you want to authenticate users from multiple domains at the same time, the server can do that. Just define all of the realms in proxy.conf. The server will figure it out, and will do the right thing.
realm example.com { # empty == "my realm" }
This is extensively documented in the proxy.conf file.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Aug 14, 2019, at 12:58 PM, Marek Des <desmarek1@gmail.com> wrote:
Well, about empty realm - I mean this: 1) outer identity: empty
That's an issue. The outer identity shouldn't be empty. In RADIUS, it's *forbidden* to have an empty User-Name. See RFC 7542. The outer identity should be "anonymous", or maybe "@realm" where it's your realm.
2) inner identity: username
I need to authenticate two kind of users: 1) ones with credentials above 2) eduroam
Except that an empty outer identity means that your users will *never* be able to use eduroam. An outer User-Name of "@example.com" is routable back to you via eduroam. An empty outer User-Name will just get dropped on the floor.
The only difference is in outer and inner identity. The both setups use EAP + MSCHAPv2 and OpenLDAP.
I am trying to handle those two kind of users in single virtual server
You generally *must* run them in a single virtual server. Because the Ads will send both user authentications to one RADIUS server. And the RADIUS server has to figure it out.
and it doesn't work - it says it's proxying request to localhost and that's it.
See the FAQ for "it doesn't work". And post the *actual* debug output. Not a one-line summary. What you
proxy.conf:
We don't need to see that. The documentation says to post the debug log, *not* the configuration files.
Virtual server for inner identity:
We don't need to see that, either. If it doesn't work, it's wrong. If you post the debug output, we see it *running* the configuration, which is infinitely more useful. What you should be doing is: * all users log in with a non-empty outer identity. * *your* users log in with outer identity of "@my.domain.tld" * the FreeRADIUS configuration has that domain as a local one * everything else gets proxied to eduroam A long and detailed guide is in the Wiki: https://wiki.freeradius.org/guide/eduroam Alan DeKok.
On 15.08.19 03:24, Alan DeKok wrote:
What you should be doing is:
* all users log in with a non-empty outer identity. * *your* users log in with outer identity of "@my.domain.tld" * the FreeRADIUS configuration has that domain as a local one * everything else gets proxied to eduroam
A long and detailed guide is in the Wiki: https://wiki.freeradius.org/guide/eduroam
If I may add, as an University admin having to deal with foreign (meaning not from my University) users: For the love of $deity, enforce the existence of a realm in the Eduroam SSID for every user, even your local ones. I really really really hate all the users from other universities who try to log in to our Eduroam SSID using only "username" instead of "username@uni.ver.sity", causing unneccesary chatter and rejects from the local RADIUS servers. This additionally serves the purpose of ensuring that your *own* users have a realm configured, so their configuration continues to work in foreign Eduroam networks. Please, don't allow just "username" for your local users to work in your Eduroam, you will create a heap of problems for you and your users down the line. Believe me, I was down that line and it was a real mess to clean up. Grüße, Sven.
I am still running two RADIUS servers (I mean two different physical installations), one handle eduroam SSID and other handle internal SSID - "the one with no outer identity". They work perfectly as each of servers has its own configuration. Now I am trying to combine those two into one server. Here we go: mschap.conf: network={ key_mgmt=WPA-EAP eap=PEAP identity="testuser" anonymous_identity="" password="testpasswd" phase2="auth=MSCHAPV2 mschapv2_retry=0" phase1="peapver=0" } eapol_test -c ./mschap.conf -a 127.0.0.1 -s testing123 Reading configuration file './mschap.conf' Line: 1 - start of a new network block key_mgmt: 0x1 eap methods - hexdump(len=16): 00 00 00 00 19 00 00 00 00 00 00 00 00 00 00 00 identity - hexdump_ascii(len=6): 39 39 39 30 30 30 testuser anonymous_identity - hexdump_ascii(len=0): password - hexdump_ascii(len=10): 75 66 54 65 37 78 6a 44 39 71 testpasswd phase2 - hexdump_ascii(len=30): 61 75 74 68 3d 4d 53 43 48 41 50 56 32 20 6d 73 auth=MSCHAPV2 ms 63 68 61 70 76 32 5f 72 65 74 72 79 3d 30 chapv2_retry=0 phase1 - hexdump_ascii(len=9): 70 65 61 70 76 65 72 3d 30 peapver=0 Priority group 0 id=0 ssid='' Authentication server 127.0.0.1:1812 RADIUS local address: 127.0.0.1:59004 ENGINE: Loading dynamic engine ENGINE: Loading dynamic engine EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portValid=0 EAPOL: External notification - portEnabled=1 EAPOL: SUPP_PAE entering state CONNECTING EAPOL: SUPP_BE entering state IDLE EAP: EAP entering state INITIALIZE EAP: EAP entering state IDLE Sending fake EAP-Request-Identity EAPOL: Received EAP-Packet frame EAPOL: SUPP_PAE entering state RESTART EAP: EAP entering state INITIALIZE EAP: EAP entering state IDLE EAPOL: SUPP_PAE entering state AUTHENTICATING EAPOL: SUPP_BE entering state REQUEST EAPOL: getSuppRsp EAP: EAP entering state RECEIVED EAP: Received EAP-Request id=29 method=1 vendor=0 vendorMethod=0 EAP: EAP entering state IDENTITY CTRL-EVENT-EAP-STARTED EAP authentication started EAP: Status notification: started (param=) EAP: EAP-Request Identity data - hexdump_ascii(len=0): EAP: using anonymous identity - hexdump_ascii(len=0): EAP: EAP entering state SEND_RESPONSE EAP: EAP entering state IDLE EAPOL: SUPP_BE entering state RESPONSE EAPOL: txSuppRsp WPA: eapol_test_eapol_send(type=0 len=5) TX EAP -> RADIUS - hexdump(len=5): 02 1d 00 05 01 Encapsulating EAP message into a RADIUS packet Learned identity from EAP-Response-Identity - hexdump(len=0): Sending RADIUS message to authentication server RADIUS message: code=1 (Access-Request) identifier=0 length=114 Attribute 1 (User-Name) length=2 Value: '' Attribute 4 (NAS-IP-Address) length=6 Value: 127.0.0.1 Attribute 31 (Calling-Station-Id) length=19 Value: '02-00-00-00-00-01' Attribute 12 (Framed-MTU) length=6 Value: 1400 Attribute 61 (NAS-Port-Type) length=6 Value: 19 Attribute 6 (Service-Type) length=6 Value: 2 Attribute 77 (Connect-Info) length=24 Value: 'CONNECT 11Mbps 802.11b' Attribute 79 (EAP-Message) length=7 Value: 021d000501 Attribute 80 (Message-Authenticator) length=18 Value: 27476a384e7596824785e4efdc30b52c Next RADIUS client retransmit in 3 seconds EAPOL: SUPP_BE entering state RECEIVE EAPOL: startWhen --> 0 STA 02:00:00:00:00:01: Resending RADIUS message (id=0) Next RADIUS client retransmit in 6 seconds STA 02:00:00:00:00:01: Resending RADIUS message (id=0) Next RADIUS client retransmit in 12 seconds ^CSignal 2 received - terminating EAPOL: EAP key not available EAPOL: EAP Session-Id not available WPA: Clear old PMK and PTK MPPE keys OK: 0 mismatch: 1 FAILURE On Thu, Aug 15, 2019 at 3:25 AM Alan DeKok <aland@deployingradius.com> wrote:
On Aug 14, 2019, at 12:58 PM, Marek Des <desmarek1@gmail.com> wrote:
Well, about empty realm - I mean this: 1) outer identity: empty
That's an issue. The outer identity shouldn't be empty. In RADIUS, it's *forbidden* to have an empty User-Name.
See RFC 7542. The outer identity should be "anonymous", or maybe "@realm" where it's your realm.
2) inner identity: username
I need to authenticate two kind of users: 1) ones with credentials above 2) eduroam
Except that an empty outer identity means that your users will *never* be able to use eduroam. An outer User-Name of "@example.com" is routable back to you via eduroam. An empty outer User-Name will just get dropped on the floor.
The only difference is in outer and inner identity. The both setups use EAP + MSCHAPv2 and OpenLDAP.
I am trying to handle those two kind of users in single virtual server
You generally *must* run them in a single virtual server. Because the Ads will send both user authentications to one RADIUS server. And the RADIUS server has to figure it out.
and it doesn't work - it says it's proxying request to localhost and that's it.
See the FAQ for "it doesn't work". And post the *actual* debug output. Not a one-line summary.
What you
proxy.conf:
We don't need to see that. The documentation says to post the debug log, *not* the configuration files.
Virtual server for inner identity:
We don't need to see that, either. If it doesn't work, it's wrong. If you post the debug output, we see it *running* the configuration, which is infinitely more useful.
What you should be doing is:
* all users log in with a non-empty outer identity. * *your* users log in with outer identity of "@my.domain.tld" * the FreeRADIUS configuration has that domain as a local one * everything else gets proxied to eduroam
A long and detailed guide is in the Wiki: https://wiki.freeradius.org/guide/eduroam
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Aug 15, 2019, at 12:03 PM, Marek Des <desmarek1@gmail.com> wrote:
I am still running two RADIUS servers (I mean two different physical installations), one handle eduroam SSID and other handle internal SSID - "the one with no outer identity". They work perfectly as each of servers has its own configuration. Now I am trying to combine those two into one server.
You have two choices: a) use different servers (or different virtual servers + IPs + ports) for the two kinds of users b) make the "no outer identity" users have a real identity, by fixing their configuration You've been told how to fix the problem. Again, for the third time, using empty outer identities is wrong, broken, stupid, irresponsible. It WILL cause more problems than what you're seeing now. ALL of the solutions to those problems are "use a real domain in the outer identity". If you're not going to listen to the experts, then we clearly can't help you. Alan DeKok.
participants (3)
-
Alan DeKok -
Marek Des -
Sven Hartge