- Freeradius-Users - lists.freeradius.org

Accounting For NAS-Port-Type Wireless-802.11
by Pizu 16 Apr '21

16 Apr '21

Hi, Am having an issue with Sending accounting when nas-port-type is wireless-802.11 If I use Ethernet/Virtual works but when using the wireless-802.11 it authenticates the user but the accounting is not being sent. Under authorize I have the below: if (NAS-Port-Type == "Ethernet") { update control { Proxy-To-Realm := "Realm_802Dot1x_Auth" } } elsif (NAS-Port-Type == "Wireless-802.11") { update control { Proxy-To-Realm := "Realm_Wireless802Dot1x_Auth" } } elsif (NAS-Port-Type == "Virtual") { update control { Proxy-To-Realm := "Realm_CorpadNPS_Auth" } } under accounting I have the below.. update control { Replicate-To-Realm := "Realm_FG_1500D_Agg_Users_Acct" Replicate-To-Realm += "Realm_FG_1500D_Datacentre_Acct" Replicate-To-Realm += "Realm_FG_1500D_Users_Acct" } replicate under post-auth I have.. if (NAS-Port-Type == "Ethernet") { if (LDAP-Group == "LDAP GroupA") { update reply { Tunnel-Type := "VLAN" Tunnel-Medium-Type := "IEEE-802" Tunnel-Private-Group-Id := "943" Class := "CLASS GroupA" } } elsif (LDAP-Group == "LDAP GroupB ") { update reply { Tunnel-Type := "VLAN" Tunnel-Medium-Type := "IEEE-802" Tunnel-Private-Group-Id := "943" Class := "CLASS Group B" } } elsif (NAS-Port-Type == "Wireless-802.11") { if (LDAP-Group == "LDAP GroupA") { update reply { Class := " CLASS Group A" } } } elsif (NAS-Port-Type == "virtual") { if (LDAP-Group == "LDAP GroupA") { update reply { Class := " CLASS Group A" } } Logs at the end: When connecting wireless device: (9) sql: SQL query returned: success (9) sql: 1 record(s) updated rlm_sql (sql): Released connection (0) (9) [sql] = ok (9) [exec] = noop (9) policy remove_reply_message_if_eap { (9) if (&reply:EAP-Message && &reply:Reply-Message) { (9) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (9) else { (9) [noop] = noop (9) } # else = noop (9) } # policy remove_reply_message_if_eap = noop (9) } # post-auth = ok (9) Sent Access-Accept Id 116 from 172.16.193.198:1812 to 10.159.69.13:59535 length 0 (9) MS-MPPE-Recv-Key = 0xb20c21e9c85ce877c24268daad644a7f2745637443dc231a81bced4fd71fa21d (9) MS-MPPE-Send-Key = 0xf0e9aa957319677320881f76bd12fb4bb8885bb2b61a7dcf1fab9de0763b1890 (9) EAP-Message = 0x030a0004 (9) Message-Authenticator = 0x00000000000000000000000000000000 (9) User-Name = "CORPORATE\\Fake.Local2" (9) Class := 0x5253534f2d49542d4e6574776f726b696e67 (9) Finished request When connecting Ethernet: (12) sql: SQL query returned: success (12) sql: 1 record(s) updated rlm_sql (sql): Released connection (2) (12) [sql] = ok (12) [exec] = noop (12) attr_filter.accounting_response: EXPAND %{User-Name} (12) attr_filter.accounting_response: --> CORPORATE\\Fake.Local2 (12) attr_filter.accounting_response: Matched entry DEFAULT at line 12 (12) [attr_filter.accounting_response] = updated (12) update control { (12) Replicate-To-Realm := "Realm_FG_1500D_Agg_Users_Acct" (12) Replicate-To-Realm += "Realm_FG_1500D_Datacentre_Acct" (12) Replicate-To-Realm += "Realm_FG_1500D_Users_Acct" (12) } # update control = noop (12) replicate: Replicating list 'request' to Realm 'Realm_FG_1500D_Agg_Users_Acct' (12) replicate: Replicating list 'request' to Realm 'Realm_FG_1500D_Datacentre_Acct' (12) replicate: Replicating list 'request' to Realm 'Realm_FG_1500D_Users_Acct' (12) [replicate] = ok (12) } # accounting = updated (12) Sent Accounting-Response Id 231 from 172.16.193.198:1813 to 172.16.193.106:1646 length 0 (12) Finished request Can someone help? I am missing something for sure.. :( Thanks & Regards, Pizu

2 3

Unknown or invalid value ":2:IPV4" for attribute Tunnel-Medium-Type
by Khan, Aarif (IT Services) 14 Apr '21

14 Apr '21

Hi, I are trying to upgrade from freeRadius 2.1.12 to 3.0.2. My current issue is with these three attributes "Tunnel-Type", Tunnel-Medium-Type" and "Tunnel-Preference". SQL query of radgroupreply MariaDB [radius]> select * from radgroupreply; | 1060 | Test-Group | Service-Type | = | Framed-User | | 1061 | Test-Group | Framed-Protocol | = | PPP | | 1062 | Test-Group | Framed-IP-Netmask | = | 255.255.255.255 | | 1063 | Test-Group | Framed-MTU | = | 1500 | | 1074 | Test-Group | Cisco-AVPair | += | ip:route=10.48.45.45 255.255.255.248 | | 1080 | Test-Group | Tunnel-Password | += | :1:askdfjwen23 | | 1082 | Test-Group | Tunnel-Server-Endpoint | += | :2:123.46.26.721 | | 1087 | Test-Group | Tunnel-Server-Auth-ID | += | :1:lks1-scaede.core | | 1088 | Test-Group | Tunnel-Client-Auth-ID | += | :1:bt-wbmc-wbc | | 1092 | Test-Group | Tunnel-Preference | += | :2:100 | | 1093 | Test-Group | Tunnel-Medium-Type | += | :2:IPV4 | | 1095 | Test-Group | Tunnel-Type | += | :1:L2TP | freeradius -X debug looks like this (0) sql: EXPAND SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{SQL-Group}' ORDER BY id (0) sql: --> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'Test-Group' ORDER BY id (0) sql: Executing select query: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'Test-Group' ORDER BY id (0) sql: ERROR: Error parsing value: Unknown or invalid value ":2:IPV4" for attribute Tunnel-Medium-Type (0) sql: ERROR: Error parsing user data from database result (0) sql: ERROR: Error retrieving reply pairs for group Test-Group rlm_sql (sql): Released connection (1) (0) [sql] = fail (0) } # authorize = fail (0) Invalid user (sql: Error parsing value: Unknown or invalid value ":2:IPV4" for attribute Tunnel-Medium-Type): [testuser] (from client windowspc port 0) (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (0) Post-Auth-Type REJECT { (0) sql: EXPAND .query We never had any issue with freeRadius 2 but I don't understand why freeRadius 3 doesn't like the value of those 3 attributes. I looked in dictionary everything looks fine and matches with our freeradius 2. I am not sure what I am missing could you please point me to the right direction. Kind Regards, Aarif This email is security checked and subject to the disclaimer on web-page: https://www.capita.com/email-disclaimer.aspx

2 1

iOS devices don't authorize on wireless networks
by Vahap Can Dulkadiroğlu 14 Apr '21

14 Apr '21

Freeradius gives me the following error in debug mode when I try to connect to the wireless network from the iphone(IOS). By the way, the connection with other operating systems (eg ubuntu android, windows) from this wireless network is successfully established.But I can't connect to iOS devices. I'm getting this error; "eap_md5: Cleartext-Password is required for EAP-MD5 authentication" I will be glad if you help. Mon Apr 12 04:17:39 2021 : Debug: (17) ldap: User object found at DN "uid=can.dulkadiroglu,ou=Users,dc=samsun,dc=edu,dc=tr" Mon Apr 12 04:17:39 2021 : Debug: (17) ldap: Processing user attributes Mon Apr 12 04:17:39 2021 : Debug: (17) ldap: Attribute "userPassword" not found in LDAP object Mon Apr 12 04:17:39 2021 : Debug: (17) ldap: Attribute "radiusControlAttribute" not found in LDAP object Mon Apr 12 04:17:39 2021 : Debug: (17) ldap: Attribute "radiusRequestAttribute" not found in LDAP object Mon Apr 12 04:17:39 2021 : Debug: (17) ldap: Attribute "radiusReplyAttribute" not found in LDAP object Mon Apr 12 04:17:39 2021 : WARNING: (17) ldap: No "known good" password added. Ensure the admin user has permission to read the password attribute Mon Apr 12 04:17:39 2021 : WARNING: (17) ldap: PAP authentication will *NOT* work with Active Directory (if that is what you were trying to configure) Mon Apr 12 04:17:39 2021 : Debug: rlm_ldap (ldap): Released connection (0) Mon Apr 12 04:17:39 2021 : Info: Need 1 more connections to reach min connections (3) Mon Apr 12 04:17:39 2021 : Info: rlm_ldap (ldap): Opening additional connection (6), 1 of 30 pending slots used Mon Apr 12 04:17:39 2021 : Debug: rlm_ldap (ldap): Connecting to ldaps:// ldap.google.com:636 Mon Apr 12 04:17:39 2021 : Debug: rlm_ldap (ldap): New libldap handle 0x5631da71dd60 Mon Apr 12 04:17:39 2021 : Debug: rlm_ldap (ldap): Waiting for bind result... ber_get_next failed. Mon Apr 12 04:17:40 2021 : Debug: rlm_ldap (ldap): Bind successful Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authorize]: returned from ldap (rlm_ldap) Mon Apr 12 04:17:40 2021 : Debug: (17) [ldap] = ok Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authorize]: calling expiration (rlm_expiration) Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authorize]: returned from expiration (rlm_expiration) Mon Apr 12 04:17:40 2021 : Debug: (17) [expiration] = noop Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authorize]: calling logintime (rlm_logintime) Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authorize]: returned from logintime (rlm_logintime) Mon Apr 12 04:17:40 2021 : Debug: (17) [logintime] = noop Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authorize]: calling pap (rlm_pap) Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authorize]: returned from pap (rlm_pap) Mon Apr 12 04:17:40 2021 : Debug: (17) [pap] = noop Mon Apr 12 04:17:40 2021 : Debug: (17) if (User-Password) { Mon Apr 12 04:17:40 2021 : Debug: (17) if (User-Password) -> FALSE Mon Apr 12 04:17:40 2021 : Debug: (17) } # authorize = updated Mon Apr 12 04:17:40 2021 : Debug: (17) Found Auth-Type = eap Mon Apr 12 04:17:40 2021 : Debug: (17) # Executing group from file /etc/freeradius/3.0/sites-enabled/inner-tunnel Mon Apr 12 04:17:40 2021 : Debug: (17) authenticate { Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authenticate]: calling eap (rlm_eap) Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Expiring EAP session with state 0x14605457166441b9 Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Finished EAP session with state 0xca0fe817ca0eec20 Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Previous EAP request found for state 0xca0fe817ca0eec20, released from the list Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Peer sent packet with method EAP MD5 (4) Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Calling submodule eap_md5 to process data Mon Apr 12 04:17:40 2021 : ERROR: (17) eap_md5: Cleartext-Password is required for EAP-MD5 authentication Mon Apr 12 04:17:40 2021 : ERROR: (17) eap: Failed continuing EAP MD5 (4) session. EAP sub-module failed Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Sending EAP Failure (code 4) ID 1 length 4 Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Failed in EAP select Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authenticate]: returned from eap (rlm_eap) Mon Apr 12 04:17:40 2021 : Debug: (17) [eap] = invalid Mon Apr 12 04:17:40 2021 : Debug: (17) } # authenticate = invalid Mon Apr 12 04:17:40 2021 : Debug: (17) Failed to authenticate the user Mon Apr 12 04:17:40 2021 : Debug: (17) Using Post-Auth-Type Reject Mon Apr 12 04:17:40 2021 : Debug: (17) # Executing group from file /etc/freeradius/3.0/sites-enabled/inner-tunnel Mon Apr 12 04:17:40 2021 : Debug: (17) Post-Auth-Type REJECT { Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[post-auth]: calling attr_filter.access_reject (rlm_attr_filter) Mon Apr 12 04:17:40 2021 : Debug: %{User-Name} Mon Apr 12 04:17:40 2021 : Debug: Parsed xlat tree: Mon Apr 12 04:17:40 2021 : Debug: attribute --> User-Name Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: EXPAND %{User-Name} Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: --> can.dulkadiroglu Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: Matched entry DEFAULT at line 11 Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: EAP-Message = 0x04010004 allowed by EAP-Message =* 0x Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: Attribute "EAP-Message" allowed by 1 rules, disallowed by 0 rules Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: Message-Authenticator = 0x00000000000000000000000000000000 allowed by Message-Authenticator =* 0x Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: Attribute "Message-Authenticator" allowed by 1 rules, disallowed by 0 rules Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[post-auth]: returned from attr_filter.access_reject (rlm_attr_filter) Mon Apr 12 04:17:40 2021 : Debug: (17) [attr_filter.access_reject] = updated Mon Apr 12 04:17:40 2021 : Debug: (17) update outer.session-state { Mon Apr 12 04:17:40 2021 : Debug: (17) &Module-Failure-Message := &request:Module-Failure-Message -> 'eap_md5: Cleartext-Password is required for EAP-MD5 authentication' Mon Apr 12 04:17:40 2021 : Debug: (17) } # update outer.session-state = noop Mon Apr 12 04:17:40 2021 : Debug: (17) } # Post-Auth-Type REJECT = updated Mon Apr 12 04:17:40 2021 : Auth: (17) Login incorrect (eap_md5: Cleartext-Password is required for EAP-MD5 authentication): [can.dulkadiroglu/<via Auth-Type = eap>] (from client localhost port 2 cli fa33e5c54a33 via TLS tunnel) Mon Apr 12 04:17:40 2021 : Debug: (17) } # server inner-tunnel Mon Apr 12 04:17:40 2021 : Debug: (17) Virtual server sending reply Mon Apr 12 04:17:40 2021 : Debug: (17) EAP-Message = 0x04010004 Mon Apr 12 04:17:40 2021 : Debug: (17) Message-Authenticator = 0x00000000000000000000000000000000 Mon Apr 12 04:17:40 2021 : Debug: (17) eap_ttls: Got tunneled Access-Reject Mon Apr 12 04:17:40 2021 : ERROR: (17) eap: Failed continuing EAP TTLS (21) session. EAP sub-module failed Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Sending EAP Failure (code 4) ID 6 length 4 Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Failed in EAP select Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[authenticate]: returned from eap (rlm_eap) Mon Apr 12 04:17:40 2021 : Debug: (17) [eap] = invalid Mon Apr 12 04:17:40 2021 : Debug: (17) } # authenticate = invalid Mon Apr 12 04:17:40 2021 : Debug: (17) Failed to authenticate the user Mon Apr 12 04:17:40 2021 : Debug: (17) Using Post-Auth-Type Reject Mon Apr 12 04:17:40 2021 : Debug: (17) # Executing group from file /etc/freeradius/3.0/sites-enabled/default Mon Apr 12 04:17:40 2021 : Debug: (17) Post-Auth-Type REJECT { Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[post-auth]: calling attr_filter.access_reject (rlm_attr_filter) Mon Apr 12 04:17:40 2021 : Debug: %{User-Name} Mon Apr 12 04:17:40 2021 : Debug: Parsed xlat tree: Mon Apr 12 04:17:40 2021 : Debug: attribute --> User-Name Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: EXPAND %{User-Name} Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: --> can.dulkadiroglu Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: Matched entry DEFAULT at line 11 Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: EAP-Message = 0x04060004 allowed by EAP-Message =* 0x Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: Attribute "EAP-Message" allowed by 1 rules, disallowed by 0 rules Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: Message-Authenticator = 0x00000000000000000000000000000000 allowed by Message-Authenticator =* 0x Mon Apr 12 04:17:40 2021 : Debug: (17) attr_filter.access_reject: Attribute "Message-Authenticator" allowed by 1 rules, disallowed by 0 rules Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[post-auth]: returned from attr_filter.access_reject (rlm_attr_filter) Mon Apr 12 04:17:40 2021 : Debug: (17) [attr_filter.access_reject] = updated Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[post-auth]: calling eap (rlm_eap) Mon Apr 12 04:17:40 2021 : Debug: (17) eap: Reply already contained an EAP-Message, not inserting EAP-Failure Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[post-auth]: returned from eap (rlm_eap) Mon Apr 12 04:17:40 2021 : Debug: (17) [eap] = noop Mon Apr 12 04:17:40 2021 : Debug: (17) policy remove_reply_message_if_eap { Mon Apr 12 04:17:40 2021 : Debug: (17) if (&reply:EAP-Message && &reply:Reply-Message) { Mon Apr 12 04:17:40 2021 : Debug: (17) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE Mon Apr 12 04:17:40 2021 : Debug: (17) else { Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[post-auth]: calling noop (rlm_always) Mon Apr 12 04:17:40 2021 : Debug: (17) modsingle[post-auth]: returned from noop (rlm_always) Mon Apr 12 04:17:40 2021 : Debug: (17) [noop] = noop Mon Apr 12 04:17:40 2021 : Debug: (17) } # else = noop Mon Apr 12 04:17:40 2021 : Debug: (17) } # policy remove_reply_message_if_eap = noop Mon Apr 12 04:17:40 2021 : Debug: (17) } # Post-Auth-Type REJECT = updated Mon Apr 12 04:17:40 2021 : Auth: (17) Login incorrect (eap: Failed continuing EAP TTLS (21) session. EAP sub-module failed): [can.dulkadiroglu/<via Auth-Type = eap>] (from client localhost port 2 cli fa33e5c54a33) Mon Apr 12 04:17:40 2021 : Debug: (17) Delaying response for 1.000000 seconds Mon Apr 12 04:17:40 2021 : Debug: Waking up in 0.5 seconds. Mon Apr 12 04:17:41 2021 : Debug: (12) Cleaning up request packet ID 248 with timestamp +80 Mon Apr 12 04:17:41 2021 : Debug: (13) Cleaning up request packet ID 249 with timestamp +80 Mon Apr 12 04:17:41 2021 : Debug: (14) Cleaning up request packet ID 250 with timestamp +80 Mon Apr 12 04:17:41 2021 : Debug: Waking up in 0.3 seconds. Mon Apr 12 04:17:41 2021 : Debug: (17) Sending delayed response Mon Apr 12 04:17:41 2021 : Debug: (17) Sent Access-Reject Id 253 from 10.50.2.140:1812 to 10.50.2.166:58160 length 44 Mon Apr 12 04:17:41 2021 : Debug: (17) EAP-Message = 0x04060004 Mon Apr 12 04:17:41 2021 : Debug: (17) Message-Authenticator = 0x00000000000000000000000000000000 Mon Apr 12 04:17:41 2021 : Debug: Waking up in 2.6 seconds. Mon Apr 12 04:17:44 2021 : Debug: (15) Cleaning up request packet ID 251 with timestamp +83 Mon Apr 12 04:17:44 2021 : Debug: (16) Cleaning up request packet ID 252 with timestamp +83 Mon Apr 12 04:17:44 2021 : Debug: Waking up in 1.3 seconds. Mon Apr 12 04:17:45 2021 : Debug: (17) Cleaning up request packet ID 253 with timestamp +83 Mon Apr 12 04:17:45 2021 : Info: Ready to process requests Vahap Can DULKADİROĞLU *Bilgi İşlem Daire Başkanlığı **/ Elektronik ve Haberleşme Mühendisi* *can.dulkadiroglu(a)samsun.edu.tr <can.dulkadiroglu(a)samsun.edu.tr>* 0(362) 313 00 55 - 1454 Canik Yerleşkesi Gürgenyatak Mahallesi Merkez Sokak No:40-2/1 CANİK/SAMSUN www.samsun.edu.tr *SAMSUN ÜNİVERSİTESİ* *‘‘Nitelikli Toplum İçin, Nitelikli Üniversite’’*

2 7

RE: EAP-TLS and elliptic curves (OPEN)
by Weisteen Per 14 Apr '21

14 Apr '21

Hi Setting ecdh_curve parameter to an empty string didn't work. Server fails with "no shared cipher" after it receives TLS client hello. (1) eap_tls: Continuing EAP-TLS (1) eap_tls: Got final TLS record fragment (190 bytes) (1) eap_tls: WARNING: Total received TLS record fragments (190 bytes), does not equal indicated TLS record length (0 bytes) (1) eap_tls: [eaptls verify] = ok (1) eap_tls: Done initial handshake (1) eap_tls: (other): before/accept initialization (1) eap_tls: TLS_accept: before/accept initialization (1) eap_tls: <<< recv TLS 1.2 [length 00b9] (1) eap_tls: >>> send TLS 1.2 [length 0002] (1) eap_tls: ERROR: TLS Alert write:fatal:handshake failure tls: TLS_accept: Error in error tls: TLS_accept: Error in error (1) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (1) eap_tls: ERROR: System call (I/O) error (-1) (1) eap_tls: ERROR: TLS receive handshake failed during operation (1) eap_tls: ERROR: [eaptls process] = fail I'm using OpenSSL 1.0.2k-fips FreeRADIUS Version 3.0.13 ./PerW Sensitivity: Internal > -----Original Message----- > From: Freeradius-Users <freeradius-users- > bounces+per.weisteen=telenor.no(a)lists.freeradius.org> On Behalf Of Alan > DeKok > Sent: tirsdag 13. april 2021 12:21 > To: FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org> > Subject: Re: EAP-TLS and elliptic curves (OPEN) > > On Apr 13, 2021, at 4:39 AM, Weisteen Per <per.weisteen(a)telenor.no> > wrote: > > I've got some supplicants that only supports secp256r1/prime256v1 as > elliptic curve while others support additional curves like x25519, secp384r1 > etc. > > Currently I've set ecdh_curve To prime256v1 which then applies to all > supplicants. > > > > If I set ecdh_curve parameter empty will the server key exchange adjust > curve info dynamically according to what the supplicant has announced in TLS > client hello using the "best" curve available ? > > It's probably faster to try it and see, instead of waiting for an answer on the > list. > > The real answer is: it's all magic in OpenSSL, we really can't tell you. > > Alan DeKok. > > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html

2 1

Overrides for sites-available/inner-tunnel
by Roddie Hasan 13 Apr '21

13 Apr '21

This question is kind of Docker-related, but also a general question. I'm working on a project here (WIP): https://github.com/eiddor/cisco-sda-freeradius/ My goal is to include any customized files that a user would need in order to get this going. So far I've got users, clients.conf, and a sample docker-compose file. It works in general, except I figured out today that I need to change a setting in sites-available/inner-tunnel to get it to work with actual clients. (Found this fix on a ten year old mailer post :-) ). I haven't updated the repo with these findings yet. The fix is simply to change "if (0)" to "if (1)" on line #335 in the post-auth{} section. Because I'm also including instructions for users to run this in Docker, my question is: What's the best way to change this setting while keeping the repo simple and also making it easy for Docker users to implement. The way I see it, I have three options: 1) Spin-off my own Docker image with this setting changed. A heavy-lift and there's really no reason to reinvent this particular wheel for a single character change. 2) Copy sites-available/inner-tunnel out of the container, change it, and just have the user mount it as a volume (similar to clients.conf and users). This seems like the appropriate option, it just seems a bit goofy in my head to break out the full 13K file just to override a single setting. 3) Instruct the user to change the setting inside of the container itself. This isn't really an option, but I didn't want to include only two :-) Are these the only options I have or is there a way to easily override this setting from another file? If I just break out the post-auth{} section and mount it as sites-available/inner-tunnel will the other settings in the original file disappear, or are they set by default? Thanks for any input! Roddie

2 4

Proxy Config/File
by Pizu 13 Apr '21

13 Apr '21

Hi, Is it possible to call multiple proxy files according to the source Ip Address/Range in the pre-proxy? We would like to have the Switch with the 8021x calling a certain proxy file and if coming from VPN will call another. Also if calling different files is not possible something similar to this..? if ((&NAS-IP-Address == 172.16.65.0/24) || (&NAS-IP-Address == 172.16.193.0/24)) { **something here to use realm** } } elsif (&NAS-IP-Address == 10.69.3.182) { **something here to use realm** } } Regards, Pizu

3 4

EAP-TLS and elliptic curves (OPEN)
by Weisteen Per 13 Apr '21

13 Apr '21

Hi I've got some supplicants that only supports secp256r1/prime256v1 as elliptic curve while others support additional curves like x25519, secp384r1 etc. Currently I've set ecdh_curve To prime256v1 which then applies to all supplicants. If I set ecdh_curve parameter empty will the server key exchange adjust curve info dynamically according to what the supplicant has announced in TLS client hello using the "best" curve available ? ./PerW Sensitivity: Internal

2 1

Re: FreeRadius Accounting.
by Linux Threads 08 Apr '21

08 Apr '21

HI Pizu, you mind sharing what you did to get this sorted? Regards > Sorted :) > > Regards, > > Pizu On Wed, 7 Apr 2021 at 19:58, Pizu <pizpower at gmail.com> wrote: > hmm.. something like: Class := "%{Group}" - correct? > > Regards, > > Pizu > > > On Wed, 7 Apr 2021 at 19:44, Pizu <pizpower at gmail.com> wrote: > >> Hi, >> >> I need to forward the class which will reflect to a group not the actual >> LDAP-Group. >> >> The firewall is expecting the Radius Accounting-Start attribute. >> >> Example: >> Acct-Status-Type=Start,Framed-Ip-Address=10.0.0.1,User- Name=user.name >> ,Acct-Session-Id=0211a4ef,Class=usergroup1,Calling-Station-Id=00-0c- 29-44-BE-B8 >> >> I hope I explained better now. >> >> Regards, >> >> Pizu >> >> >> On Wed, 7 Apr 2021 at 19:20, Alan DeKok <aland at deployingradius.com> >> wrote: >> >>> On Apr 7, 2021, at 1:15 PM, Pizu <pizpower at gmail.com> wrote: >>> > What I mean with LDAP-Group is I need to forward the group name that is >>> > assigned to the user towards the firewall (accounting) in order for the >>> > firewall to open the access that is assigned. RSSO >>> >>> So read the firewall documentation to see which attribute it needs. >>> >>> I can guarantee you that it's not LDAP-Group. >>> >>> Alan DeKok. >>> >>> - >>> List info/subscribe/unsubscribe? See >>> http://www.freeradius.org/list/users.html >> >>

2 1

Massaging the behavior of LDAP-Group caching?
by Braden McGrath 07 Apr '21

07 Apr '21

All, I ran into a problem with LDAP-Group and a DN that it was not able to find a friendly name for. I have a function called "group_authz" (loaded from a file in policy.d) that gets called in the post-auth{} section of my site. The function just does a few if comparisons against &LDAP-Group[*] and then updates the reply to the NAS with attributes. I ran into a situation where one of the groups it pulled from a user's memberOf list "did not resolve to an object," which then causes rlm_ldap to return "invalid" and thus rejects the whole attempt. The group it choked on is something used internally by FreeIPA. It's not a group I care about, and not user-created (it's not even visible inside the standard FreeIPA interface). There are actually multiple groups like this that I presume it will complain about, if it wasn't failing at the first one. I was able to work around the problem by trying to match on the full DN instead of the friendly name, but this is obviously a bit harder to read in the config, and I'd prefer to use the friendly names if I can find a way to make it work. Is there a way to tell LDAP-Group to ignore any DN that it finds that it can't "resolve", instead of throwing an "invalid"? Or, is there a way to get the LDAP-Group lookup process to only attempt to resolve DNs that match a specified base/filter? The base_dn in the group{} stanza of the ldap module is already set to the portion of the tree I care about, but LDAP-Group seems to still try to resolve the DNs that aren't in that base (presumably because it's just reading them from "memberOf"). If I have to just stick to matching on full DNs, I will... was just trying to learn if there was a way to deal with this lookup failure gracefully. :-) Snippet of log output in the failure state is below... In this case, I had cacheable_names=yes enabled, but I disabled caching later to test further (caching itself isn't the problem, it's just the unresoveable DN). (0) ldap: Performing search in "cn=users,cn=accounts,dc=foobar,dc=org" with filter "(uid=admin-person)", scope "sub" (0) ldap: Waiting for search result... (0) ldap: User object found at DN "uid=admin-person,cn=users,cn=accounts,dc=foobar,dc=org" (0) ldap: Resolving group DN "cn=admins,cn=groups,cn=accounts,dc=foobar,dc=org" to group name (0) ldap: Performing unfiltered search in "cn=admins,cn=groups,cn=accounts,dc=foobar,dc=org", scope "base" (0) ldap: Waiting for search result... (0) ldap: Group DN "cn=admins,cn=groups,cn=accounts,dc=foobar,dc=org" resolves to name "admins" (0) ldap: Resolving group DN "cn=Replication Administrators,cn=privileges,cn=pbac,dc=foobar,dc=org" to group name (0) ldap: Performing unfiltered search in "cn=Replication Administrators,cn=privileges,cn=pbac,dc=foobar,dc=org", scope "base" (0) ldap: Waiting for search result... (0) ldap: Search returned no results (0) ldap: ERROR: Group DN "cn=Replication Administrators,cn=privileges,cn=pbac,dc=foobar,dc=org" did not resolve to an object rlm_ldap (ldap): Released connection (0) Need 5 more connections to reach 10 spares rlm_ldap (ldap): Opening additional connection (5), 1 of 27 pending slots used rlm_ldap (ldap): Connecting to ldap://ipa1.foobar.org:389 ldap://ipa2.foobar.org:389 ldap://ipa3.foobar.org:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful (0) [ldap] = invalid (0) } # authorize = invalid (0) Invalid user (ldap: Group DN "cn=Replication Administrators,cn=privileges,cn=pbac,dc=foobar,dc=org" did not resolve to an object): [admin-person] (from client dc-srv- sw01 port 11526) (0) Using Post-Auth-Type Reject I appreciate any suggestions! Cheers, Braden

2 4

Implementing PEAP/MSCHAP-v2 at an application level
by Scott Neugroschl 07 Apr '21

07 Apr '21

Hi all, I've had a request to implement a PEAP/MSCHAP-v2 RADIUS client. I've been looking at FreeRADIUS and radcli libraries. My understanding is that PEAP and EAP are MAC level protocols, as opposed to Layer 3 or higher. Is this correct? My problem is that the supplicant is a wired connection that already has an IP address. Are there suggestions for how one would go about implementing this? Or would you recommend using something like stunnel at both ends, and then just implementing the MSCHAPv2 RADIUS protocol using that tunnel? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |

2 1