ExtremeCloud A3

 A3, EAP-TLS, Realm Use SAN instead of CN on lookup?

Martin Flammia's profile image
Martin Flammia posted 08-12-2021 19:00

Hi,

Just trying to understand realms, which I have some context below that helps understand what the NULL and DEFAULT realms do, not sure about LOCAL? But as of yet not found anything that really explains the detail, what all the fields do to fully understand all the options?

 

So here is my scenario; just doing certificate authentication, my certificate CN is as follows:

mflammia.ingleby.co.uk

When the devices connects using EAP-TLS I see the following:

 

This is perfect and works as expected.

What's happening here is I have the ‘Strip Radius’ disabled:

 

So when the username gets extrapolated from CN, and with Strip Radius disabled, it shows up in the A3 with the username of:

host/mflammia.ingleby.co.uk

Now the domain of ‘ingleby.co.uk’ can match to a realm called ‘ingleby.co.uk.

Issue I have is if instead you want to use the SAN user principle name instead within the client certificate to populate the username field in A3, and match the realm, how do you do this?

In my scenario the customers certificate was formed with a CN that didn’t include the domain part, so it would never match, the username for example would just show up ‘mflammia’

So my questions are:

  • How can you tell A3 to look at SAN instead of CN within the client cert, when doing a realm lookup?
  • Why must you associate a Realm to the authentication source when doing just certificate authentication i.e. you are not proxying request or using AD?

Some useful information explaining the use of the different realms from this source:

https://www.packetfence.org/downloads/PacketFence/doc/PacketFence_Administration_Guide-5.6.1.pdf

 

The DEFAULT realm will apply to any client that attempts to authenticate with a realm that is not other wise defined.

The REALM is set based on the domain found by the suffix

The suffix or ntdomain modules try to find a domain either withan @domain or suffix\username.

▪ If none is found,the REALM is NULL.
▪ If a domain is found, FreeRADIUS tries to match one of the REALMS defined in this file.
▪ If the domain is either example.edu or EXAMPLE FreeRADIUS sets the corresponding REALM,
i.e.example.edu or EXAMPLE. 
▪ If the REALM does not match either(and it isn’t NULL),that means there was a domain other than
EXAMPLE or example.edu and we assume it is meant to be proxied to eduroam.FreeRADIUS
sets the DEFAULT realm (which is proxied to the eduroam authentication pool).
 
The REALM determines where the request is sent to. If the REALM authenticates locally the
requests are processed entirely by FreeRADIUS. If the REALM sets a different homeserverpool,
the requests are proxied to the servers defined within that pool.