April 2021 - Freeradius-Users - lists.freeradius.org

Problems with using Freeradius as systemd
by Mark Antony 19 Apr '21

19 Apr '21

Hello, I have compiled Freeradius 3.0.21 successfully and can run it perfectly as radiusd -X. However when I want to run it as Systemd it doesn't work. This is how I have compiled it under Debian 10.9. Do I have to enable any special flag to support systemd? wget ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.21.tar.gz tar -xvzf freeradius-server-3.0.21.tar.gz cd freeradius-server-3.0.21 sudo ./configure sudo make sudo make install /lib/systemd/system/freeradius.service: [Unit] Description=FreeRADIUS multi-protocol policy server After=network.target [Service] Type=notify NotifyAccess=all EnvironmentFile=-/usr/local/freeradius ExecStartPre=/usr/local/sbin/radiusd $FREERADIUS_OPTIONS -Cxm -lstdout ExecStart=/usr/local/sbin/radiusd -f $FREERADIUS_OPTIONS Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target Nothing obvious in syslog: Apr 19 16:29:25 us-sfo-2 systemd[1]: freeradius.service: Start operation timed out. Terminating. Apr 19 16:29:25 us-sfo-2 systemd[1]: freeradius.service: Failed with result 'timeout'. Apr 19 16:29:25 us-sfo-2 systemd[1]: Failed to start FreeRADIUS multi-protocol policy server. Neither anything useful in journal -x -- The job identifier is 6355. Apr 19 16:37:31 us-sfo-2 radiusd[6129]: FreeRADIUS Version 3.0.21 Apr 19 16:37:31 us-sfo-2 radiusd[6129]: Copyright (C) 1999-2019 The FreeRADIUS server project and contributors Apr 19 16:37:31 us-sfo-2 radiusd[6129]: There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A Apr 19 16:37:31 us-sfo-2 radiusd[6129]: PARTICULAR PURPOSE Apr 19 16:37:31 us-sfo-2 radiusd[6129]: You may redistribute copies of FreeRADIUS under the terms of the Apr 19 16:37:31 us-sfo-2 radiusd[6129]: GNU General Public License Apr 19 16:37:31 us-sfo-2 radiusd[6129]: For more information about these matters, see the file named COPYRIGHT Apr 19 16:37:31 us-sfo-2 radiusd[6129]: Starting - reading configuration files ... Apr 19 16:37:31 us-sfo-2 radiusd[6129]: Debugger not attached Apr 19 16:37:31 us-sfo-2 radiusd[6129]: Built without support for systemd watchdog, but running under systemd. Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_sql (sql): Driver rlm_sql_mysql (module rlm_sql_mysql) loaded and linked Apr 19 16:37:31 us-sfo-2 radiusd[6129]: Creating attribute SQL-Group Apr 19 16:37:31 us-sfo-2 radiusd[6129]: Creating attribute Unix-Group Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_cache (cache_eap): Driver rlm_cache_rbtree (module rlm_cache_rbtree) loaded and linked Apr 19 16:37:31 us-sfo-2 radiusd[6129]: Please use tls_min_version and tls_max_version instead of disable_tlsv1 Apr 19 16:37:31 us-sfo-2 radiusd[6129]: Please use tls_min_version and tls_max_version instead of disable_tlsv1_2 Apr 19 16:37:31 us-sfo-2 radiusd[6129]: tls: Using cached TLS configuration from previous invocation Apr 19 16:37:31 us-sfo-2 radiusd[6129]: tls: Using cached TLS configuration from previous invocation Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_sql_mysql: libmysql version: 10.5.9 Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_sql (sql): Attempting to connect to database "radius_db" Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_sql (sql): Initialising connection pool Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_sql (sql): Processing generate_sql_clients Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_sql (sql) in generate_sql_clients: query is SELECT id, nasname, shortname, type, secret, server FROM nas Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_sql (sql): 0 of 0 connections in use. You may need to increase "spare" Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_sql (sql): Opening additional connection (0), 1 of 1 pending slots used Apr 19 16:37:31 us-sfo-2 radiusd[6129]: rlm_sql_mysql: Starting connect to MySQL server Apr 19 16:37:32 us-sfo-2 radiusd[6129]: rlm_sql (sql): Reserved connection (0) Apr 19 16:37:32 us-sfo-2 radiusd[6129]: rlm_sql (sql): Released connection (0) Apr 19 16:37:32 us-sfo-2 radiusd[6129]: rlm_detail (auth_log): 'User-Password' suppressed, will not appear in detail output Apr 19 16:37:32 us-sfo-2 radiusd[6129]: rlm_mschap (mschap): using internal authentication Apr 19 16:37:32 us-sfo-2 radiusd[6129]: Ignoring "ldap" (see raddb/mods-available/README.rst) Apr 19 16:37:32 us-sfo-2 radiusd[6129]: # Skipping contents of 'if' as it is always 'false' -- /usr/local/etc/raddb/sites-enabled/inner-tunnel:336 Apr 19 16:37:32 us-sfo-2 radiusd[6129]: radiusd: #### Skipping IP addresses and Ports #### Apr 19 16:37:32 us-sfo-2 radiusd[6129]: Configuration appears to be OK Apr 19 16:37:32 us-sfo-2 radiusd[6129]: rlm_sql (sql): Removing connection pool Apr 19 16:37:32 us-sfo-2 radiusd[6129]: rlm_sql (sql): Closing connection (0) Apr 19 16:37:44 us-sfo-2 sudo[6138]: admin : TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/usr/bin/journalctl -xe Apr 19 16:37:44 us-sfo-2 sudo[6138]: pam_unix(sudo:session): session opened for user root by admin(uid=0) I would really appreciate your help on this. Thank you Mark

3 3

Recreate detail file for buffered-sql
by Ángel L. Mateo 19 Apr '21

19 Apr '21

Hello, I have freeradius configured in eduroam to create a detail buffered wich is read by a buffered-sql site to dump connection logs to a mysql. My problem is that I have wrongly delete the buffered file that is created to dump these entries, but I already have the original detail files. Is there any way to recreate the dump file? May a copy from the detail file to the buffered input be enough? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337

2 1

(no subject)
by mohamed almeshal 18 Apr '21

18 Apr '21

thanks Alan But I'm not expert into freeradius code ? sorry for That kindly could you guide me where I put those lines of code ? Sorry for My GitHub Post but I was lost Your's Mohammed Almeshal

2 1

Lts problem with radsec
by mohamed almeshal 17 Apr '21

17 Apr '21

dear all I have problem killing my server . I have cloud server based on freeradius with radsec I notice that it's stop after sometimes due to this : Info: Ignoring new connection due to client max_connections (16) even I set max connection to 0 in all tcp input . I'm using the current version of freeradius 3.0.21 with ubuntu 18.04 install from git any one can help Your's Mohammed Almesshal

2 1

TLS version mismatch EAP TLS
by De Sylvain 16 Apr '21

16 Apr '21

Hello Team, I need to open a case cause I meet an issue with TLS version mismatch between client and server. My scope : - FreeRADIUS Version 3.0.20 - OpenSSL 1.1.1f - Windows client TLS version allowed : TLS1.0/1.1/1.2 Accros few link(show below) I understood that TLS 1.3 was not correctly supported on freeradius. I have the same issue like this post #3665 <https://github.com/FreeRADIUS/freeradius-server/issues/3665> However my window client is correctly configured and it do no use tls version 1.3. Furthermore i make a packet capture and i can see that TLS 1.0 is used during TLS client hello. As show bellow, eap module configuration. I do not use "disable_tls" but tls_min/max feature as recommended. "# disable_tlsv1_2 = no" "# disable_tlsv1_1 = no" "# disable_tlsv1 = no" tls_min_version = "1.0" tls_max_version = "1.2" Freeradius debug : I do not understand how freeradius server can interptrer the tls request with 1.3 version. Client side tls 1.3 is not allowed and also on freeradius side. How can I interpret this issue ? Thanks in advance for your help. Freeradius live debug (1) eap: Expiring EAP session with state 0xcf201259cf221f90 (1) eap: Finished EAP session with state 0xcf201259cf221f90 (1) eap: Previous EAP request found for state 0xcf201259cf221f90, released from the list (1) eap: Peer sent packet with method EAP TLS (13) (1) eap: Calling submodule eap_tls to process data (1) eap_tls: Continuing EAP-TLS (1) eap_tls: Peer indicated complete TLS record size will be 112 bytes (1) eap_tls: Got complete TLS record (112 bytes) (1) eap_tls: [eaptls verify] = length included (1) eap_tls: (other): before SSL initialization (1) eap_tls: TLS_accept: before SSL initialization (1) eap_tls: TLS_accept: before SSL initialization (1) eap_tls: <<< recv TLS 1.3 [length 006b] (1) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal protocol_version (1) eap_tls: ERROR: TLS Alert write:fatal:protocol version tls: TLS_accept: Error in error (1) eap_tls: ERROR: Failed in FUNCTION (SSL_read): error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol (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 (1) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed (1) eap: Sending EAP Failure (code 4) ID 2 length 4 (1) eap: Failed in EAP select (1) [eap] = invalid (1) } # authenticate = invalid

3 2

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