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

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

Make compile error in 3.0.x branch
by nabble＠felix.world 24 Mar '21

24 Mar '21

Hi Guys, i don't want to open a useless issue on github so the question here. The current 3.0.x branch get's a compile error on ubuntu as shown in your test https://github.com/FreeRADIUS/freeradius-server/runs/2169587583#step:12:1675 I just want to ask if you're aware of it? Best regards, Lineconnect

2 2

VLAN assignment based on NAS ID
by Max Elzinga 23 Mar '21

23 Mar '21

Hello, I would like to assign VLANs based on NAS ID. We have different subnets with switches that do 802.1x. I have tried adding NAS-IP-Address to the Users file but without any success. DEFAULT NAS-Port-Type = Ethernet Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-Id = 207, NAS-IP-Address = 10.2.106.0/24 DEFAULT NAS-Port-Type = Ethernet Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-Id = 200 NAS-IP-Address = 10.2.16.0/24 How to accomplish this the right way? Thanks. Kind regards, Max

6 13

how to configure authorization using Active Directory + SQL
by Lucian Kim 23 Mar '21

23 Mar '21

Hello, I am trying to configure a RADIUS authentication server by linking FreeRADIUS and Active Directory. Authenticating in Active Directory using the mschap module was successful. However, I do not know how to set up authorization, so I ask. after merging reply items in the authorize {} section i want to authenticate using Active Directory(mschap), can I merge reply items using the sql module? Or, if there is another way, please help. I'm using EAP-PEAP(MSCHAPV2). thank you for your help.

2 1

IP Pools Question
by Richard J Palmer 22 Mar '21

22 Mar '21

Good Evening We have FreeRadius 3.0.20 running here quite happily - but have a very small issue we' like some help with Some of our connections use ippools (running from a mssql server) As a general rule this works exactly as it should Very occasionally the sql server will time out - maybe once or twice a day due to transactions clashing When this happens the session comes on-line but is not issued a IP. What I'd ideally like to do is simply reject that connection IF that happens which will force the router to log in again - it will then get an IP and will be happy Is there an easy way to catch this and reject the connection (or even re-try the ippool module) ? Thanks in advance Richard

2 1

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

19 Mar '21

We have several hundreds of IoT WiFi devices, each authenticating with their own individual client certificates against our FreeRADIUS v2.2.9 servers. While each device has its own unique client certificate having the device's serial number as the CN in the cert, the hardware vendors is using a generic username of "user" when specifying the username during the authentication process. This is allowed as we do not enable the "check_cert_cn" option, since this would cause other issues not only with this vendor, but with Microsoft/Apple as well as we've seen those OS sometime specify the MAC address of the client as the "Username" when authenticating with client certificates. 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. 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. 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}\"," 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). 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. Has anyone found a solution to log certificate information in the radius accounting table for users who authenticate via EAP-TLS? Thanks, Roberto accounting_start_query = " \ INSERT INTO ${acct_table1} \ (acctsessionid, acctuniqueid, username, \ realm, nasipaddress, nasportid, \ nasporttype, acctstarttime, acctstoptime, \ acctsessiontime, acctauthentic, connectinfo_start, \ connectinfo_stop, acctinputoctets, acctoutputoctets, \ calledstationid, callingstationid, acctterminatecause, \ servicetype, framedprotocol, framedipaddress, \ acctstartdelay, acctstopdelay, xascendsessionsvrkey, \ TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) \ VALUES \ ('%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', \ '%{SQL-User-Name}', \ '%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', \ '%{NAS-Port-Type}', '%S', NULL, \ '0', '%{Acct-Authentic}', '%{Connect-Info}', \ '', '0', '0', \ '%{Called-Station-Id}', '%{Calling-Station-Id}', '', \ '%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IP-Address}', \ '%{%{Acct-Delay-Time}:-0}', '0', '%{X-Ascend-Session-Svr-Key}', \ '%{TLS-Client-Cert-Common-Name}', '%{TLS-Client-Cert-Serial}', '%{TLS-Client-Cert-Issuer}')" 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.

3 2