Help in understanding variable expansion

[Alan DeKok]

On Feb 11, 2025, at 10:09 AM, Luca Cavana via Freeradius-Users <freeradius-users at 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.