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

Authenticate to AD but only allow certain group
by Brian C. Huffman 16 Aug '25

16 Aug '25

All, I've got authentication working nicely with MSCHAP, but now I'd like to only allow users that are members of a certain AD group. I would prefer to have this happen only when requests come from a specific client (wireless access point). In this case the idea is to have users only be able to get wireless access when they're in a specific AD group. How can I do this in freeradius? Thanks, Brian

7 18

RE: EAP-TLS Signature Check Failure
by nabble＠felix.world 12 Jul '22

12 Jul '22

Hi Together, we finally got the issue and for the anyone else, how will face the issue, the fix is quite simple. Update your TPM Firmware! In fact, during the authentication the client is sending a signature which only includes nulls. The packet itself is intact, sizes of the packets are valid and the signature algorithm is also well. The only thing that's not in the tls authentication is a signature. : ```` (4) eap_tls: <<< recv TLS 1.2 (type: 0016) [length 0108] handshake_type: 0f, alert_level: 00, alert_description: 00 0f000104 TLS handshake certificate_verify len 0x000104 = 260 0804 signature algorithm: rsa_pss_rsae_sha256 0100 signature size: 0x0100 = 256 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 000000000000 ```` That's also the reason why some of our clients are able to authenticate and some not, with the key, stored in TPM. Intel ships end customer TPM updater, STM as we know not. We also don't have clients with Infineon chips but they should also ship updates to the end customer. FYI: This was a team operation and thanks to all that helped here. Regards, Lineconnnect <quote author='Users mailing list'> 2 months later, a quick update on this topic (apologies, I may have broken the threading as I don't have a copy of the original e-mails any more!), just so there's an online reference here for anyone encountering the same error. Turns out I was wrong about it being Windows and OpenSSL getting muddled over TLS 1.2 vs. 1.3... To recap: Windows 10 clients, corporate WiFi network using EAP-TLS to RADIUS with machine certificate (SCEP) authentication only. Error in Freeradius logs: (6) eap_tls: ERROR: TLS Alert write:fatal:decrypt error tls: TLS_accept: Error in error (6) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read) (6) eap_tls: ERROR: error:0407E086:rsa routines:RSA_verify_PKCS1_PSS_mgf1:last octet invalid (6) eap_tls: ERROR: error:1417B07B:SSL routines:tls_process_cert_verify:bad signature (6) eap_tls: ERROR: System call (I/O) error (-1) (6) eap_tls: ERROR: TLS receive handshake failed during operation (6) eap_tls: ERROR: [eaptls process] = fail After encountering the error on a few machines again, even with "tls_max_version" set, I delved into the guts of Windows again, and found the error (which isn't helpful or descriptive) was actually caused because: * Some machine certificates had were stored/managed by the "Microsoft Platform Crypto Provider" (TPM-backed) * Built-in security measures control access to keys in that CSP, and it cannot be used non-interactively * Windows WiFi profile was set to auto-join (non-interactive) * Windows couldn't get the key, so $deity knows what signature it was sending * OpenSSL rightly got confused The solution: Ensure machine certificate keys are stored in the "Microsoft Software Key Storage Provider" (or another CSP/KSP that permits non-interactive use). All is well again, and I'm close to shutting down NPS :-) -- Peter Bance Information Security Adviser Alan DeKok wrote: > A final update on this, in case anyone here's interested (or to "wrap > up" for anyone stumbling across this thread online) - I fixed it, and > Windows clients are now happily joining WiFi. It's a beautiful thing to > behold :-) > > In the end, I had to force OpenSSL on FreeRADIUS to stop offering > TLS1.3 ciphers using the mods/eap config: > > tls_max_version = "1.2" Good to hear. > It seems there may be a bug in OpenSSL 1.1.1 such that even though the > negotiation resulted in a TLS 1.2 session, the weird back-port of TLS > 1.3 ciphers into TLS 1.2 confused things (a lot), and it tried checking > for TLS 1.3 style signatures inappropriately. Weird, but OK. It's OpenSSL :( Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html </quote> Quoted from: http://freeradius.1045715.n5.nabble.com/RE-EAP-TLS-Signature-Check-Failure-… _____________________________________ Sent from http://freeradius.1045715.n5.nabble.com

3 4

EAP-TLS PKI management
by Munroe Sollog 17 Jun '21

17 Jun '21

Has anyone deployed EAP-TLS in concert with BYOD? This Android 11 change that removes the ability for the user to "Do Not Validate" the CA certificate has forced us to re-evaluate our .1x PEAP solution. EAP-TLS seems like the best option, however the onboarding of user-brought devices seems tricky. With MDM or AD-joined devices pushing the certificates out are easy. In an environment where "bring your own device" is encouraged, I'm curious how network admins are making client certificate installations easy enough for end users to do. Android 11 change article for reference: https://www.xda-developers.com/android-11-break-enterprise-wifi-connection/ -- Munroe Sollog (He/Him/His) Senior Network Engineer munroe(a)lehigh.edu

5 7

CentOS 8 packages missing winbind support?
by Josef Vybíhal 14 Jun '21

14 Jun '21

Packages for CentOS 8 at https://networkradius.com/freeradius-packages/ appear to be compiled without winbind support. Is there a reason for that? CentOS 7 package have it - not sure about other distros. ... snip... # Instantiating module "expiration" from file /etc/raddb/mods-enabled/expiration # Instantiating module "files" from file /etc/raddb/mods-enabled/files reading pairlist file /etc/raddb/mods-config/files/authorize reading pairlist file /etc/raddb/mods-config/files/accounting reading pairlist file /etc/raddb/mods-config/files/pre-proxy # Instantiating module "linelog" from file /etc/raddb/mods-enabled/linelog # Instantiating module "log_accounting" from file /etc/raddb/mods-enabled/linelog # Instantiating module "log_accounting_syslog" from file /etc/raddb/mods-enabled/linelog # Instantiating module "vlanlog" from file /etc/raddb/mods-enabled/linelog # Instantiating module "logintime" from file /etc/raddb/mods-enabled/logintime # Instantiating module "mschap_winbind" from file /etc/raddb/mods-enabled/mschap /etc/raddb/mods-enabled/mschap[1]: 'winbind' auth not enabled at compiled time /etc/raddb/mods-enabled/mschap[1]: Instantiation failed for module "mschap_winbind" P.

6 12

Fwd: Question regarding the direction of eap_tls: <<< recv and eap_tls: >>> send
by Eric Nguyen 17 Mar '21

17 Mar '21

Hi, I'd like to ask a question regarding the direction of the exchanges in the radius log (radiusd -X). I used eapol_test as a client/authenticator against FreeRADIUS 3.0.21. - If I set the following parameters in the FreeRADIUS eap file, espol_test will results in a failure. In this case, "eap_tls: <<< recv TLS 1.3" looks like an exchange from FreeRADIUS to eapol_test (SERVER -> CLIENT): tls_min_version = "1.3" tls_max_version = "1.3" The FREERADIUS log shows: (2) eap_tls: <<< recv TLS 1.3 [length 00b9] (2) eap_tls: >>> send TLS 1.2 [length 0002] (2) eap_tls: ERROR: TLS Alert write:fatal:protocol version - If I set the following parameters in the FreeRADIUS eap file, espol_test will results in a success. In this case, "eap_tls: <<< recv TLS 1.2" looks like an exchange from eapol_test to FreeRADIUS (CLIENT TO SERVER): tls_min_version = "1.2" tls_max_version = "1.3" (6) eap_tls: <<< recv TLS 1.2 [length 08de] (6) eap_tls: TLS - Creating attributes from certificate OIDs Could you please clarify the meaning of these "eap_tls: <<< recv" log messages? Thanks, Eric ------------------------------------------------------------------------------------------------------------------------------------------- FULL LOG tls_min_version = "1.3" tls_max_version = "1.3" (2) eap: Calling submodule eap_tls to process data (2) eap_tls: Continuing EAP-TLS (2) eap_tls: [eaptls verify] = ok (2) eap_tls: Done initial handshake (2) eap_tls: (other): before SSL initialization (2) eap_tls: TLS_accept: before SSL initialization (2) eap_tls: TLS_accept: before SSL initialization (2) eap_tls: <<< recv TLS 1.3 [length 00b9] (2) eap_tls: >>> send TLS 1.2 [length 0002] (2) eap_tls: ERROR: TLS Alert write:fatal:protocol version tls: TLS_accept: Error in error (2) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol (2) eap_tls: ERROR: System call (I/O) error (-1) (2) eap_tls: ERROR: TLS receive handshake failed during operation (2) eap_tls: ERROR: [eaptls process] = fail (2) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed (2) eap: Sending EAP Failure (code 4) ID 54 length 4 (2) eap: Failed in EAP select (2) [eap] = invalid (2) } # authenticate = invalid ------------------------------------------------------------------------------------------------------------------------------------------- tls_min_version = "1.2" tls_max_version = "1.3" (6) eap: Calling submodule eap_tls to process data (6) eap_tls: Continuing EAP-TLS (6) eap_tls: Got final TLS record fragment (1272 bytes) (6) eap_tls: [eaptls verify] = ok (6) eap_tls: Done initial handshake (6) eap_tls: TLS_accept: SSLv3/TLS write server done (6) eap_tls: <<< recv TLS 1.2 [length 08de] (6) eap_tls: TLS - Creating attributes from certificate OIDs (6) eap_tls: TLS-Cert-Serial := "315fa3c827cb5c44e13222c88ff80369d1a176f1" (6) eap_tls: TLS-Cert-Expiration := "210113170058Z" (6) eap_tls: TLS-Cert-Valid-Since := "201114170058Z" (6) eap_tls: TLS-Cert-Subject := "/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin(a)example.org/CN=Example Certificate Authority" (6) eap_tls: TLS-Cert-Issuer := "/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin(a)example.org/CN=Example Certificate Authority" (6) eap_tls: TLS-Cert-Common-Name := "Example Certificate Authority" (6) eap_tls: TLS - Creating attributes from certificate OIDs (6) eap_tls: TLS-Client-Cert-Serial := "02" (6) eap_tls: TLS-Client-Cert-Expiration := "210113170058Z" (6) eap_tls: TLS-Client-Cert-Valid-Since := "201114170058Z" (6) eap_tls: TLS-Client-Cert-Subject := "/C=FR/ST=Radius/O=Example Inc./CN=user@example.org/emailAddress=user@example.org" (6) eap_tls: TLS-Client-Cert-Issuer := "/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress= admin(a)example.org/CN=Example Certificate Authority" (6) eap_tls: TLS-Client-Cert-Common-Name := "user(a)example.org" (6) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage += "TLS Web Client Authentication" (6) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.2" (6) eap_tls: TLS_accept: SSLv3/TLS read client certificate (6) eap_tls: <<< recv TLS 1.2 [length 0046] (6) eap_tls: TLS_accept: SSLv3/TLS read client key exchange (6) eap_tls: <<< recv TLS 1.2 [length 0108] (6) eap_tls: TLS_accept: SSLv3/TLS read certificate verify (6) eap_tls: TLS_accept: SSLv3/TLS read change cipher spec (6) eap_tls: <<< recv TLS 1.2 [length 0010] (6) eap_tls: TLS_accept: SSLv3/TLS read finished (6) eap_tls: >>> send TLS 1.2 [length 0001] (6) eap_tls: TLS_accept: SSLv3/TLS write change cipher spec (6) eap_tls: >>> send TLS 1.2 [length 0010] (6) eap_tls: TLS_accept: SSLv3/TLS write finished (6) eap_tls: (other): SSL negotiation finished successfully (6) eap_tls: TLS - Connection Established (6) eap_tls: TLS-Session-Cipher-Suite = "ECDHE-RSA-AES256-GCM-SHA384" (6) eap_tls: TLS-Session-Version = "TLS 1.2" (6) eap_tls: TLS - got 51 bytes of data (6) eap_tls: [eaptls process] = handled

3 3

EAP-TLS host certificates
by Vieri Di Paola 10 Feb '21

10 Feb '21

Hi, Several years ago when Windows XP clients were around in my organization I had successfully configured freeradius with EAP-TLS and host certificates. Now, most of my clients are Windows 10 and just a few Windows 7. They can access with PEAP mschap-v2 via WiFi. I am now trying to configure WiFi access with EAP-TLS and host certificates. Please bear with me as I haven't handled freeradius for years now, and I'm a bit rusty. I already have a custom Signing Authority (ca.pem). So, within /etc/raddb/certs I ran the following after adjusting the corresponding *.cnf files: # make server.pem # make server.csr # make inner-server.pem # make client.pem The Windows 10 client has imported both the CA in trusted roots and the client certificate in the "local computer" store. I chose the common name "PC2036" (see below). The wireless connection is set up with a "smart card or other certificate" (computer account). When I try to connect I see this in the radiusd log (please let me know if you need the full log): (132) Received Access-Request Id 67 from 192.168.216.36:58425 to 10.215.144.91:1812 length 209 (132) User-Name = "host/PC2036" (132) NAS-IP-Address = 192.168.216.36 (132) NAS-Identifier = "10:be:f5:c9:ce:90" (132) NAS-Port = 0 (132) Called-Station-Id = "10-BE-F5-C9-CE-98:HMprv" (132) Calling-Station-Id = "4C-1D-96-4E-48-0F" (132) Framed-MTU = 1400 (132) NAS-Port-Type = Wireless-802.11 (132) Connect-Info = "CONNECT 0Mbps 802.11b" (132) EAP-Message = 0x028a001201686f73742f484d414e32303336 (132) Message-Authenticator = 0xc6775ce6e83151b7ecde4018fb87f5d8 (132) # Executing section authorize from file /etc/raddb/sites-enabled/default (132) authorize { [...] (132) ntdomain: Checking for prefix before "\" (132) ntdomain: No '\' in User-Name = "host/PC2036", looking up realm NULL (132) ntdomain: No such realm "NULL" (132) [ntdomain] = noop (132) [expiration] = noop (132) [logintime] = noop (132) } # authorize = updated (132) Found Auth-Type = eap (132) # Executing group from file /etc/raddb/sites-enabled/default (132) authenticate { (132) eap: Peer sent packet with method EAP Identity (1) (132) eap: Calling submodule eap_tls to process data (132) eap_tls: Initiating new TLS session (132) eap_tls: Setting verify mode to require certificate from client (132) eap_tls: [eaptls start] = request (132) eap: Sending EAP Request (code 1) ID 139 length 6 (132) eap: EAP session adding &reply:State = 0x007a782400f175f1 (132) [eap] = handled (132) } # authenticate = handled (132) Using Post-Auth-Type Challenge (132) # Executing group from file /etc/raddb/sites-enabled/default (132) Challenge { ... } # empty sub-section is ignored (132) Sent Access-Challenge Id 67 from 10.215.144.91:1812 to 192.168.216.36:58425 length 0 (132) EAP-Message = 0x018b00060d20 (132) Message-Authenticator = 0x00000000000000000000000000000000 (132) State = 0x007a782400f175f114c01cbf42164dc9 (132) Finished request Waking up in 4.9 seconds. (132) Cleaning up request packet ID 67 with timestamp +2318 Ready to process requests I then read this: https://wiki.freeradius.org/guide/certificate-compatibility So I decided to replace the whole certificate directory just to make sure the test certs work. So I ran this: # ./bootstrap # make inner-server.pem However, when I run the server I get an error reading its certificate. # radiusd -X [...] tls: Failed reading private key file "/etc/raddb/certs/server.pem" tls: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt tls: error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error tls: error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error tls: error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib tls: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib rlm_eap_tls: Failed initializing SSL context rlm_eap (EAP): Failed to initialise rlm_eap_tls /etc/raddb/mods-enabled/eap[14]: Instantiation failed for module "eap" # ls -l /etc/raddb/certs/server.pem -rw-r----- 1 root radius 3588 Jun 12 2020 /etc/raddb/certs/server.pem freeradius v. 3.0.20 I'm sure this is a silly mistake on my behalf. Any suggestions? Vieri

4 12

Fwd: help
by valeriobaroni 30 Jan '21

30 Jan '21

HELP Hi all, im trying to setup freeradius witch WLC cisco, but when i trying to connect i cannot receive any IP from the vlan 102, can you help me? # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default authorize { policy filter_username { if (&User-Name) { if (&User-Name) -TRUE if (&User-Name) { if (&User-Name =~ / /) { if (&User-Name =~ / /) -FALSE if (&User-Name =~ /@[^@]*@/ ) { if (&User-Name =~ /@[^@]*@/ ) -FALSE if (&User-Name =~ /\.\./ ) { if (&User-Name =~ /\.\./ ) -FALSE if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\.(.+)$/)) { if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\.(.+)$/)) -FALSE if (&User-Name =~ /\.$/) { if (&User-Name =~ /\.$/) -FALSE if (&User-Name =~ /(a)\./) { if (&User-Name =~ /(a)\./) -FALSE } # if (&User-Name) = notfound } # policy filter_username = notfound [preprocess] = ok [chap] = noop [mschap] = noop [digest] = noop suffix: Checking for suffix after "@" suffix: No '@' in User-Name = "antonio.spagnolo", looking up realm NULL suffix: No such realm "NULL" [suffix] = noop eap: Peer sent EAP Response (code 2) ID 8 length 46 eap: Continuing tunnel setup [eap] = ok } # authorize = ok Found Auth-Type = eap # Executing group from file /etc/freeradius/3.0/sites-enabled/default authenticate { eap: Expiring EAP session with state 0x15e01da017e4042c eap: Finished EAP session with state 0xb7b3f30ab1bbeaee eap: Previous EAP request found for state 0xb7b3f30ab1bbeaee, released from the list eap: Peer sent packet with method EAP PEAP (25) eap: Calling submodule eap_peap to process data eap_peap: Continuing EAP-TLS eap_peap: [eaptls verify] = ok eap_peap: Done initial handshake eap_peap: [eaptls process] = ok eap_peap: Session established. Decoding tunneled attributes eap_peap: PEAP state send tlv success eap_peap: Received EAP-TLV response eap_peap: Success eap_peap: Using saved attributes from the original Access-Accept eap_peap: Cleartext-Password = "l63dJ2Ye" eap_peap: Tunnel-Type = VLAN eap_peap: Tunnel-Medium-Type = IEEE-802 eap_peap: Tunnel-Private-Group-Id = "102" eap: Sending EAP Success (code 3) ID 8 length 4 eap: Freeing handler [eap] = ok } # authenticate = ok # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default post-auth { if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) { if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) -FALSE update { &reply::TLS-Session-Cipher-Suite += &session-state:TLS-Session-Cipher-Suite[*] -'ECDHE-RSA-AES256-GCM-SHA384' &reply::TLS-Session-Version += &session-state:TLS-Session-Version[*] -'TLS 1.2' } # update = noop sql: EXPAND .query sql: --.query sql: Using query template 'query' rlm_sql (sql): Reserved connection (14) sql: EXPAND %{User-Name} sql: --antonio.spagnolo sql: SQL-User-Name set to 'antonio.spagnolo' sql: EXPAND INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{SQL-User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S.%M') sql: --INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'antonio.spagnolo', '', 'Access-Accept', '2021-01-21 16:11:14.451111') sql: EXPAND /var/log/freeradius/sqllog.sql sql: --/var/log/freeradius/sqllog.sql sql: Executing query: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'antonio.spagnolo', '', 'Access-Accept', '2021-01-21 16:11:14.451111') sql: SQL query returned: success sql: 1 record(s) updated rlm_sql (sql): Released connection (14) [sql] = ok [exec] = noop policy remove_reply_message_if_eap { if (&reply:EAP-Message && &reply:Reply-Message) { if (&reply:EAP-Message && &reply:Reply-Message) -FALSE else { [noop] = noop } # else = noop } # policy remove_reply_message_if_eap = noop } # post-auth = ok Sent Access-Accept Id 34 from 192.168.11.5:1812 to 192.168.14.250:50788 length 0 Tunnel-Type = VLAN Tunnel-Medium-Type = IEEE-802 Tunnel-Private-Group-Id = "102" MS-MPPE-Recv-Key = 0x7271712b4d569cfb7ca3339e0a7b56057fbb82f2d1c0571a16de929285a7b101 MS-MPPE-Send-Key = 0x43dd9dbc85f67a42325568da028912e22fc1587cb3d2df3ed4c5b076731f8e85 EAP-Message = 0x03080004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "antonio.spagnolo" Finished request

4 5

[802.1x] FreeRADIUS OpenLDAP
by Christian VAN DER ZWAARD 28 Jan '21

28 Jan '21

Hello, I'm actually trying to set up network authentication with FreeRADIUS and OpenLDAP. I'm trying to provide a VLAN depending on the users group. It actually works if I set the *Tunnel-Private-Group-Id* attribute on my user but I'd love to set a Group ID on my group object in LDAP only. FreeRADIUS won't take the Group ID when it's set in *Tunnel-Private-Group-Id* attribute on the group object. Do you have any idea how I can get this to work? Thank you so much for your help Kind regards. -- Christian VAN DER ZWAARD

3 4

AW: Additional reply attributes via eap-pwd possible?
by denny.friebe＠icera-network.de 27 Jan '21

27 Jan '21

I have now found my mistake. I had commented out "updated = return" in the default configuration under authorize in the eap module. The attributes are now passed on an access-accept.

1 0

Passing attributes into inner-tunnel
by lingctam 27 Jan '21

27 Jan '21

Dear all, Is there a way to pass specific attributes from the outer session into the eap_peap tunnels to be processed? I haven't had any success in doing this nor able to find any hints online. Any help would be appreciated. Thanks.

1 1