- Freeradius-Users - lists.freeradius.org

Authenticate against FreeIPA PBKDF2_SHA256
by Marc Sauer 07 Apr '21

07 Apr '21

Hello, I would like to authenticate against our FreeIPA servers. The problem is that our passwords are stored in the following format: PBKDF2_SHA256 FreeRADIUS did not support this at all until version 3.0.22 [1]. The functionality has been merged into the v3.0.x branch in September 2020. Unfortonately it still does not work in 3.0.22 with FreeIPA passwords. The example-password I'm trying to authenticate against has the following content: {PBKDF2_SHA256}AAAIAEwR4+gKWf4IQAoqJWD7qwaUtanUiuYCJzD7ISaOwuvoBE4Ltq58p7hF4Or32gz2vrbGcD9JL7hUHoswrqGFlgCvDSNZD9MmuNePPk5SK/G3OdBMjZ6/6ioy5WJjKToPkE4cwsxL3F7nq0XzjvhzF9muy7I5HHSFYxxYCE92xk03JHi2Q1dlKqdsMDxF6wa50JO3aoVD6ZfqYr3It+JxzQTKrUS5JxHetbBdmm3WEhuMf4kgwfsCstE55kYfQCvB94D9Ro5s05MOgQulX9VyvOTB0xugOii290gLUssX1/qkacHVabTbA252kdxfguonASGEX7mpjJRskubgTHFadJ5i5TfodqvxJ/cghMaxZ1rkHXTZ9fBXxNZHltYHZVexhV3sJOq3Cq3eyvVuLfp3qwixPBJBWDC3Wv/mCSzdW5v6 When I try to authenticate against it, it shows the following error when running freeradius -X: (1) pap: Unknown header {PBKDF2_SHA256} in Password-With-Header, re-writing to Cleartext-Password (1) pap: Removing &control:Password-With-Header (1) [pap] = updated (1) } # authorize = updated (1) Found Auth-Type = PAP (1) # Executing group from file /etc/freeradius/sites-enabled/default (1) Auth-Type PAP { (1) pap: Login attempt with password (1) pap: Comparing with "known good" Cleartext-Password (1) pap: ERROR: Cleartext password does not match "known good" password What I don't understand is, that FreeRADIUS says "Unknown header", although the PBKDF2_SHA256 support seems to be implemented. Is there anything wrong with my configration or is there still something wrong with the implementation of those kinds of hashes in FreeRADIUS? If I'd know C, I would love to help implementing the support. Maybe someone can help me with that. Cheers, Marc Sauer [1]: https://github.com/FreeRADIUS/freeradius-server/issues/2649 -- Marc Sauer Linux Systems Administrator Kunsthochschule für Medien Köln/ Academy of Media Arts Cologne Peter-Welter-Platz 2 50676 Köln https://www.khm.de https://en.khm.de tel: +49 221 20189 - 239 business mobile: +49 151 74230781

2 1

Fwd: Duplicate module "sql sql", in file /etc/freeradius/mods-enabled/sql
by rajabu kitindi 06 Apr '21

06 Apr '21

Folks I have no idea what's going on here, this is version 3.0.21 latest version. How do we solve this? I am running freeradius -X Raj -- MOTD: When we stop to think, we often miss our opportunity -- MOTD: When we stop to think, we often miss our opportunity

2 6

COA NAK simulation from server using radclient
by tejeswi 05 Apr '21

05 Apr '21

Hi Team, We are in need of your support to generate COA NAK message from server. Attached is the output of radiusd server output. Please help us in resolving this issue. Please note that we tried almost all possible ways to simulate COA NAk form server POV but no luck. -- ------------------------ Regards Tejeswi K -----------------------

2 6

Authorization problem in wireless networks in windows 10 for eduroam
by Vahap Can Dulkadiroğlu 31 Mar '21

31 Mar '21

Hello, For our university, we want to do Eduroam verification over FreeRadius (using version 3 and LDAP) using EAP-TTLS / PAP in Microsoft Windows 10 operating systems, but the password cannot be verified (access-challenge) because FreeRadius does not receive clear text. The same protocols (EAP-TTLS / PAP) are performed successfully for the Android operating system and ubuntu operating systems. As Freeradius stated in the directory settings, we think that the answer to this challenge is because there is no windows certificate compatibility. How can we solve this problem ? We look forward to your help. I share the relevant photos with you 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 1

802.1x issues with different NAS' types
by Marco Miglietta 31 Mar '21

31 Mar '21

Hi. In order to solve the problem in passing VLAN related attribute during 802.1x authentication with Aruba AP, I found the post below useful. But this caused problems with VLAN assignment on Junipers switches during the 802.1x authentication process. What is a way to solve the problem? The solutions seem to be mutually exclusive. Thanks. Marco. ______________________________________________________________________________________________ Sending an attribute with the Access-Accept instead of Access-Challenge Phil Mayers p.mayers at imperial.ac.uk Wed Jan 12 18:00:05 CET 2011 Previous message: Sending an attribute with the Access-Accept instead of Access-Challenge Next message: Sending an attribute with the Access-Accept instead of Access-Challenge Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On 12/01/11 16:33, Vivek Umasuthan wrote: > Hi All, > I am testing 802.1x support on our platform and I'm having trouble > figuring out how to include some attributes with Access-Accept. I read > the 'users' file man page but could not get the answer. You need to add the attribute in the "inner-tunnel" virtual server, and ensure you've set: use_tunneled_reply = yes ...in the "peap {}" section of "eap.conf" Previous message: Sending an attribute with the Access-Accept instead of Access-Challenge Next message: Sending an attribute with the Access-Accept instead of Access-Challenge Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the Freeradius-Users mailing list --

4 6

Mongo and operators
by Giedrius Baronas 31 Mar '21

31 Mar '21

Hello all, I try mongo db query in default instalation but I get error about key 'op' value ':=' witch is incorrect. How to solve the use of special characters in a mongo query? main/mongo/queries.conf <85 line> { \ '$project': { \ '_id': 0, \ 'attribute': '$attributes.k', \ 'value': '$attributes.v', \ 'op': ':=' \ } \ <92 line> } \ radius -X output: #(0) sql: ERROR: The op field for attribute ':= = (null)' is NULL, or non-existent. #(0) sql: ERROR: You MUST FIX THIS if you want the configuration to behave as you expect #(0) sql: ERROR: Value field is empty or NULL, skipping the entire row Giedrius Baronas www.baronai.lt

3 7

In need of your support to generate COA NAK using radclient tool
by tejeswi 29 Mar '21

29 Mar '21

Hi Team, We are in need of your support for generating COA NAK message using radclient tool. Please note that COA ACK simulation is successful. Also do share us the document to be referred for understanding configurations of radclient tool in detail. -- ------------------------ Regards Tejeswi K -----------------------

2 4

Re: Logging EAP-TLS certificate details
by Roberto.Franceschetti＠ocfl.net 25 Mar '21

25 Mar '21

I thank you both for letting me know that it's not possible to obtain certificate information when logging the accounting information. I had been looking for a way for the past week and would still be looking for one if it wasn't for your reply. However I believe my point of this being a big freeradius security issue is incorrectly overlooked. Consider a scenario where freeradius is configured to authenticate against an LDAP/Active Directory. * We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the UserName that was logged in as being "JohnS". We thus know exactly which LDAP account is compromised, are able to block the attack and quickly investigate how the account was compromised. The key there is that access was granted with a username/password credential. The username in this case unequivocally identifies the account used to login WiFi, and that "identity" information was logged by freeradius. Now consider a different scenario (ours...) were, in addition to LDAP/Active Directory, we also allow EAP-TLS authentication via certificates issues by our certificate authority (we have issued over 40,000 certificates). * We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the UserName that was logged in as being "HaHaHaTryToCatchMeIfYouCan". We discover that the account "HaHaHaTryToCatchMeIfYouCan" does not exist in our LDAP/Active Directory. We then think the user probably authenticated with EAP-TLS and a certificate, but we're guessing since neither the radacct nor the radpostauth tables provide any clues as to the authentication used. * We check the "CallingStationID" in radacct to see if the MAC address of the hacker appears elsewhere, but it's a fake MAC. We are thus in a nightmare scenario where the hacker was able to obtain the private key for one of our 40,000 certificates to authenticate with our WiFi, but we have absolutely no idea which of these 40K certificates was compromised. We will need to revoke them all and that would be a disaster. Saying "this is how radius works" does not apply here. There's nothing wrong with RADIUS. It's authenticating correctly. EAP-TLS allows the user to specify a random username as it's not taking part of the authentication process. There's nothing wrong with that either. WHY? Because they are authenticating with a certificate that we issued, and given any specific certificate's serial number, we know who it was issued to. If there's a problem with the specific certificate being compromised, we revoke it. Freeradius checks the CRL so it will not allow access to revoked certificates. BUT WAIT. Freeradius is logging usernames for users who authenticating with a password, BUT it's NOT logging absolutely anything at for the certificate used by users who authenticate with a certificate. NOTHING. The issue is thus that while freeradius is be default logging the critical "Username" when regular authentication is occurring, freeradius is completely oblivious when it comes to logging the equivalent of the username when dealing with EAP-TLS. Any properly written application will have adequate auditing for who is logging into it. Freeradius is instead allowing users to login via EAP-TLS with absolutely no auditing whats-over. Auditing means auditing the identity used to login. Auditing an EAP-TLS username that is not actually being used for login purposes is useless - Freeradius MUST log whatever method is used to authenticate a user, and with EAP-TLS that means logging the TLS-Client-Certificate information. As you said there's nothing from with RADIUS protocol. But there everything wrong with the default installation of freeradius when it comes to auditing EAP-TLS authentications. This is a huge issue security hole as the logging of EAP-TLS certificate information that should be included in the default freeradius configuration, not left to admins to figure out that (1) they actually have an auditing problem of an application that's not logging who's authenticating, and (2) for them to figure out how to log it. We were able to implement what was missing after much pain and Googling. For anyone who thinks this is an actual concern, this is how we addressed it. 1. Our NAS logs the MAC address of our wireless clients on authentication requests. So we modified the radpostauth table to include the "CallingStationID" (which has the MAC address of the client) and the client cert information. This allows us to had an audit trail of usernames, MAC and Client Cert for every Access-Request: ALTER TABLE `radius`.`radpostauth` ADD COLUMN `CallingStationId ` VARCHAR(64) AFTER `nasipaddress`, ADD COLUMN `TLS_Client_Cert_Common_Name` VARCHAR(256) AFTER `CallingStationId`, ADD COLUMN `TLS_Client_Cert_Serial` VARCHAR(128) DEFAULT NULL AFTER `TLS_Client_Cert_Common_Name`, ADD COLUMN `TLS_Client_Cert_Issuer` VARCHAR(50) DEFAULT NULL AFTER `TLS_Client_Cert_Serial`; 2. Modify the radacct table to add the client cert information in it so we can populate it afterwards: ALTER TABLE `radius`.`radacct` ADD COLUMN `TLS_Client_Cert_Common_Name` VARCHAR(256) AFTER `xascendsessionsvrkey`, ADD COLUMN `TLS_Client_Cert_Serial` VARCHAR(128) DEFAULT NULL AFTER `TLS_Client_Cert_Common_Name`, ADD COLUMN `TLS_Client_Cert_Issuer` VARCHAR(50) DEFAULT NULL AFTER `TLS_Client_Cert_Serial`; 3. Change the linelog module to log the certificate information on the Access-Request so it would be available in syslog as a backup: Access-Request = "Packet-Type=\"%{Packet-Type}\" ...... ,Timestamp = %l,%{User-Name},%{Framed-IP-Address},TLS-Client-Cert-Common-Name = \"%{TLS-Client-Cert-Common-Name}\",TLS-Client-Serial=\"%{TLS-Client-Cert-Serial}\",TLS-Client-Cert-Issuer = \"%{TLS-Client-Cert-Issuer}\"," 4. Change the postauth_query in the dialup.conf module to log the CallingStationid and the Client Cert data in the database on the Access-Request: postauth_query = "INSERT INTO ${postauth_table} \ (username, message, nasipaddress, reply, authdate, CallingStationid, TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) \ VALUES ( \ '%{User-Name}', \ '%{Module-Failure-Message}', \ '%{NAS-IP-Address}', \ '%{reply:Packet-Type}', '%S', '%{Calling-Station-Id}', \ '%{TLS-Client-Cert-Common-Name}', '%{TLS-Client-Cert-Serial}', '%{TLS-Client-Cert-Issuer}')" 5. Create and call every minute or so the following stored procedure which will update the certificate details for the records in the radacct table by matching logins via their MAC address (CallingStationId) in the radpostauth table (which does contain the certificate information previously retrieved/stored by the access-request). CREATE PROCEDURE `radacct_add_cert_info`() UPDATE radacct INNER JOIN radpostauth ON radacct.CallingStationId = radpostauth.CallingStationId SET radacct.TLS_Client_Cert_Common_Name=radpostauth.TLS_Client_Cert_Common_Name, radacct.TLS_Client_Cert_Serial=radpostauth.TLS_Client_Cert_Serial, radacct.TLS_Client_Cert_Issuer=radpostauth.TLS_Client_Cert_Issuer WHERE `authdate` > DATE_SUB(NOW(), INTERVAL '10' MINUTE) AND `AcctStartTime` > DATE_SUB(NOW(), INTERVAL '10' MINUTE) AND (radpostauth.TLS_Client_Cert_Common_Name<>'' OR radpostauth.TLS_Client_Cert_Serial<>'' OR radpostauth.TLS_Client_Cert_Issuer<>'');; The nightmare scenario above where EAP-TLS clients would be untraceable now becomes the following: * We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the certificate's serial number and common name in the radacct table for that record * We revoke the certificate, force a re-download of the CRL in the cron job, stop the attack, and can now focus on investigating how the user the certificate was issued to mishandled it. Roberto From: Alan DeKok Subject: Re: Logging EAP-TLS certificate details Date: March 19, 2021 at 8:04:04 AM EDT To: FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> On Mar 18, 2021, at 10:43 PM, Roberto.Franceschetti(a)ocfl.net<mailto:Roberto.Franceschetti@ocfl.net> wrote: We see this "feature" of EAP-TLS that allows to specify a completely random username as a serious security risk, as there is no information being logged in the radacct table to indicate what certificate was used to authenticate a particular session. As Matthew says, that's how the protocols work. It's not a security issue with FreeRADIUS. It's an issue with your local configuration. TBH, it's RADIUS. If it "just works", then great. Otherwise, it's your responsibility to understand what's going on, and to work around issues with broken clients, broken NASes, etc. This is simply the reality of RADIUS. FreeRADIUS gives you not only the information on exactly what's going on, it gives you the power to fix it. So the only question here is "how do you work around the issues you're seeing". You can send the Class attribute back in the Access-Accept. And the NAS *should* echo it back in Accounting-Request packets for the same session. You can create Class fairly easily in v3, and there are examples to do this. In 2.2.9, it's a little harder, but not impossible. Maybe: update reply { Class := "0x%{md5:%{NAS-Identifier}%{TLS-Client-Cert-Common-Name}%{TLS-Client-Cert-Serial}%{TLS-Client-Cert-Issuer}" } You'll have to try some things to see what works. The idea is to have Class be a 16-byte value, which is taken from an MD5 hash of a bunch of things specific to that particular session. This hash MUST be unique. i.e. if two users log in at the same time, with the same certificate, then they MUST get different values for the Class attribute. You'll have to (surprise) read the debug output to see wha's in the packets, and what makes those sessions unique. Things like NAS-Port, etc. Once you find out which attributes make the request unique, then put them into the input for the MD5 hash. And also log the Class attribute, along with any information about the session (TLS cert information, Framed-IP-Address, NAS-IP-Address, NAS-Port, NAS-Identifier, etc.) before sending the Access-Accept. Logging this information lets you cross-check the Class when the server receives an Accounting-Request packet which contains the Class. Here is our scenario. Hundreds of IoT devices, each authenticating with certs, connecting/disconnecting multiple times per minute. All of them are logging in with the username "user". If one of those certificates is compromised and is used in a malicious way in a different device, while the radius accounting table will show us the IP address of the attacker, there will be absolutely no way to find out which of the hundreds of certificates we issued was abused, and we would thus not know which certificate was compromised and needs to be revoked. If you have the Class attribute in the Accounting-Request packets, you just look up that in a DB, find the TLS cert information, and revoke the cert. If you don't have Class, you can likely just look up NAS-IP, port, etc. And that *should* generally be enough. But not always. Which is why Class exists. And whatever you do, you have to log things when sending the Access-Accept. We were able to log the certificate information and link it to the client's IP during the Access-Request via syslog by modifying this in the linelog: Access-Request = "Packet-Type=\"%{Packet-Type}\" ...... ,Timestamp = %l,%{User-Name},%{Framed-IP-Address},TLS-Client-Cert-Common-Name = \"%{TLS-Client-Cert-Common-Name}\",TLS-Client-Serial=\"%{TLS-Client-Cert-Serial}\",TLS-Client-Cert-Issuer = \"%{TLS-Client-Cert-Issuer}\"," That's good, if the NAS sends Framed-IP-Address. Except the whole point of RADIUS is that it happens *before* the system has network access. So in general, the Access-Request will not contain a Framed-IP-Address. But if Framed-IP-Address exists in the Access-Request *and* Accounting-Request packets, then you can use it to associate the two packets, and then revoke the correct certificate. The above will ultimately probably allow us identify the compromised certificate if we're able to capture/archive the syslog data (which we do...), but this is a workaround - the certificate information should really be available in the radacct table as that's what's used to examine user's activity (time remaining connected, bytes transferred, time of connection and so forth). No. Absolutely not. This is NOT how RADIUS works. Read the debug output. See what's in the Accounting-Request packets. Note that there's no certificate information. Customizing the accounting queries in the dialup.conf however does not seem to work for adding the same TLS-Cert fields to the radacct table (we did of course modify the schema to add the extra TLS-Cert fields). The TLS-Cert fields are being filled with blank values in the radacct table. We're thinking it's probably because the various %{TLS-Client-Cert-nnnnn} are not available during the "Accounting-Request" process. Our modified query is below. Read the debug output to see what's in the Accounting-Request packets. It really is that easy. There is no magic here. If you want to know WHY something is in the radacct table, then read the debug output. Just... PLEASE read the debug output. Note that there's no certificate information in the Accounting-Request packet. So... any idea why the certificate information isn't being logged into radacct? Has anyone found a solution to log certificate information in the radius accounting table for users who authenticate via EAP-TLS? You don't. It's impossible. What you DO is log the certificate information during authentication, AND log some information which identifies the session. THEN when receiving an Accounting-Request packet, look up the session information in a database, in order to find the certificate information. You're running into the limitations of the RADIUS protocol. These are NOT limitations in FreeRADIUS. These are not security issues in FreeRADIUS. Every system using RADIUS has it's own set of bizarreness and breakages. NASes which ignore the standards, supplicants which do weird things, etc. Your responsibility is to figure out what's going on, and then to use FreeRADIUS and databases in order to glue together a solution. You simply cannot rely on the NAS to do anything intelligent. The NAS gives you packets containing "something". You have to work with that. You can't make the NAS do anything else (except usually echo back Class). So the ONLY solution here is to write FreeRADIUS policies which read/write a database, in order to get the results you want. Welcome to RADIUS. It's a horrific nightmare of insanity. But FreeRADIUS gives you back control, and lets you work around almost every issue you'll see. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html PLEASE NOTE: Florida has a very broad public records law (F. S. 119). All e-mails to and from County Officials are kept as a public record. Your e-mail communications, including your e-mail address may be disclosed to the public and media at any time.

5 13

Plans to provide upstream ubuntu 20.04 focal packages?
by Enno Gröper 25 Mar '21

25 Mar '21

Hi, I happily used the suggested upstream freeradius packages from packages.networkradius.com in the past. Unfortunately there don't seem to be any packages for the current Ubuntu LTS release 20.04 focal, yet. Are there plans to provide current versions of freeradius for Ubuntu focal as well? Thanks and kind regards, Enno -- Enno Gröper Charité – Universitätsmedizin Berlin Geschäftsbereich IT | Netz

2 1

How to check values of TLS-Client-Cert-X509v3-Extended-Key-Usage-OID attribute ?
by Arnaud LAURIOU 24 Mar '21

24 Mar '21

Hi, I would like to check the values of the TLS-Client-Cert-X509v3-Extended-Key-Usage-OID attribute contained in a client's certificate when establishing an incoming RadSec connection on a proxy server. If those values match known strings then process the request else close the RadSec connection. How can I do that with FR 3.0.21 ? Regards, Arnaud Lauriou

2 2