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.