What other User-Name format will the Linux supplicants send?
Whatever you want them to send. To keep things simple, I want them to send their FQDNs which are equal to the certificate subject they are issued.
So... you've deleted almost all of the debug output, including information which might be used to help you. All of the documentation says "don't do that".
My apologies. I read that many times but still I didn't wanted to include a manuscript of logging (and related sanitization for some things in it) for what I imagined was an easy fix. But I understand your point, next time I will make sure to include it fully.
The debug output generally contains all the information which is needed. There is rarely a need to enable additional debugging.
This time I feel it was warranted because the Sanitized-Host-Name is not sent in the Access-Request, rather constructed via unlang during post-auth and I wanted to see that.
You can instead use the "tolower" function to compare the two strings:
This worked perfectly. Thank you, thank you very much Alan. I have one last question about this function; it isn't documented in man unlang (at least in Fedora 41 running freeradius 3.2.5). Now that I know it exists I found plenty of references online, including this one https://www.networkradius.com/doc/FreeRADIUS-Implementation-Ch16.pdf. Is there a reference in the documentation provided with the server that I missed? Thank you, Luca Cavana From: Alan DeKok <aland@deployingradius.com> Sent: Tuesday, February 11, 2025 9:04 PM To: FreeRadius users mailing list Cc: Luca Cavana Subject: Re: Help in understanding variable expansion On Feb 11, 2025, at 10:09 AM, Luca Cavana via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
this environment is used to perform (also) EAP-TLS, which is working fine.
That's good.
The supplicants in this environment are a mixture of Linux and Windows that all send the User-Name attribute in the form used by Windows, which is: host/UPPERCASE_HOSTNAME.lowercase.fqdn. To be able to match the certificate's Subject to the User-Name attribute I am using the following piece of unlang (in post-auth) which matches the full fqdn and compares it with the certificate subject with a case insensitive regular expression. ... This works but I have to instruct the Linux supplicants to send their User-Name as Windows does, which I do not like.
What other User-Name format will the Linux supplicants send?
If I change my regular expression match using variable substitution while defaulting another variable, like this:
/%{%{&Sanitized-Host-Name}:-%{&User-Name}}/i
... which I expect to firstly match the Sanitized-Host-Name (which will exist only if a Windows supplicant is trying to authenticate) and if that does not exist, match with the User-Name (which is sent "good" by a Linux client). The problem is that this is what actually happens: the following debug is from a Linux client mimicking the Windows behavior.
So... you've deleted almost all of the debug output, including information which might be used to help you. All of the documentation says "don't do that".
I've enabled some debug and this is the state the AVPs are in: (8) Attributes matching "request:" (8) &request:User-Name = host/ITMIL01CD0002.corp.cavanasystems.com (8) &request:Sanitized-Host-Name := ITMIL01CD0002.corp.cavanasystems.com
Or, just read the attributes listed after the "Received Access-Request" line. The debug output generally contains all the information which is needed. There is rarely a need to enable additional debugging.
I don't understand why it looks like the server is escaping the dots "\\." while doing the EXPAND operation.
Otherwise the users can do an injection attack, and modify the regular expression which is being used. You can instead use the "tolower" function to compare the two strings: if ("%{tolower:%{TLS-Client-Cert-Common-Name}}" != "%{tolower:%{%{&Sanitized-Host-Name}:-%{&User-Name}}}") { reject } Alan DeKok.