November 2023 - Freeradius-Users - lists.freeradius.org

EAP-TLS with CRLs broken on RHEL 8.8
by Fraser Hess 13 Nov '23

13 Nov '23

We have a working FreeRADIUS implementation. It is configured for EAP-TLS. Our production systems use stock rpms for FreeRADIUS and OpenSSL on CentOS 7.9. Current RPMs: freeradius-3.0.13-15.el7.x86_64 and openssl-1.0.2k-26.el7_9.x86_64 We are moving to Red Hat Enterprise Linux 8.8. We built a test system from scratch, installed our RADIUS config and our tests failed. The RPMs in RHEL 8.8 are: freeradius-3.0.20-14.module+el8.8.0+17558+3f8a93b9.x86_64 and openssl-1.1.1k-9.el8_7.x86_64 The failure occurs in CRL checking. With check_crl = yes and check_all_crl = yes, FreeRADIUS is unable to find our root CA's CRL to validate the intermediate CA. Setting either check_crl or check_all_crl to no resolves the issue. (8) eap_tls: TLS-Cert-Serial := "XXX" (8) eap_tls: TLS-Cert-Expiration := "250901211201Z" (8) eap_tls: TLS-Cert-Subject := "/C=US/O=Organization/CN=Organization Intermediate CA" (8) eap_tls: TLS-Cert-Issuer := "/C=US/O=Organization/CN=Organization Root CA" (8) eap_tls: TLS-Cert-Common-Name := "Organization Intermediate CA" (8) eap_tls: ERROR: SSL says error 3 : unable to get certificate CRL (8) eap_tls: >>> send TLS 1.2 [length 0002] (8) eap_tls: ERROR: TLS Alert write:fatal:unknown CA tls: TLS_accept: Error in error (8) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed (8) eap_tls: ERROR: System call (I/O) error (-1) (8) eap_tls: ERROR: TLS receive handshake failed during operation (8) eap_tls: ERROR: [eaptls process] = fail (8) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed Checking the leaf certificate against the intermediate CA appears to work. All of the certificates in /etc/raddb/certs have the correct hashed symlinks. We have tried setting tls_min_version = 1.2 and auto_chain = no, adding the intermediate CA certificate to the certificate_file. The same error results. I can break our production servers in the same manner by removing the hash symlink to the root CA's CRL file. In our test system, it's as if the hash symlink doesn't exist. The permissions on the files are correct - radiusd can read them all. Thank you for any help/suggestions Fraser Hess Workstation Engineer Pinnacol Assurance -- This communication and any attachments are for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer.

2 1

Reg: Freeradius 4.0 TACACS testing support
by shalini arivazhagan 10 Nov '23

10 Nov '23

Hi, I recently downloaded the 4.0 freeradius version to start my TACACS authentication. But I am facing an issue in authentication Added a new client in tacacs file. Add added a user<test> in the /etc/raddb/users file. But authentication is failed, it is giving error "No "known good" password found for user". Kindly help me on the TACACS testing. Where to add users for TACACS authentication in conf file. Thanks, Salini

2 1

Odd behavior on authentication
by Philip Prindeville 10 Nov '23

10 Nov '23

Hi, I had a test client (Ubuntu 22.04) set up, and I was running tcpdump on the server (also Ubuntu, running Freeradius 3.0). I had created a username & password on the Radius server, and if I tried to log into the client with those credentials, it failed. But as soon as I created a "cut out" on the client (same username, but '*' password in the shadow file), I could log in because the server was no longer rejecting the authorization request. I don't get it. How would the server know if there was a local user or not? Nothing in the messages seems to be different, other than the things you'd expect (the message id, and the random seed that the password gets hashed with). All other parts of the message looked to be identical. How was the client conveying to the server that there wasn't a local account present? Also, I've run "pam-auth-update --enable radius" to get pam_radius_auth.so plugged into the PAM stack, but how do I integrate it into /etc/nsswitch.conf as well? This is on Ubuntu so I don't have authconfig/authselect which are RedHat only. Thanks

3 5

deployment with two completely different sets of certificates
by Marek Zarychta 08 Nov '23

08 Nov '23

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(a)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

2 2