Hi, Arran and Alan! You were both right. I found a setting in Win10 WLAN profile which defines a generic username (RadiusClient) which was used for the outer tunnel. The inner tunnel used the real hostname (host/DESKTOP-FLOQN5Q). Once I cleared the RadiusClient field both tunnels reported the real hostname. The plan is to setup some school owned Win10 clients (in opposite to private devices) in a way they can connect to WLAN automatically w/o user/passwd setting. This is already working with user-based authentication and client certs. As an alternative way I like to try host-based authentication. This would probably work when I add each hostname to AD which is a lot of work. Do you think there is a way to use the anonymous outer identity name (RadiusClient) for authorization? In that case each of these clients can have the same anonymous outer identity name. This would minimize maintenance for new devices. Thanks Uwe Am 28.01.2020 19:36 schrieb Arran Cudbard-Bell:
On 28 Jan 2020, at 09:54, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 28, 2020, at 9:36 AM, uj2.hahn@posteo.de wrote:
I have a question just for my understanding. I installed a Radius client certificate (RadiusClient) on a Win10 client and enabled user authentification on this WLAN profile. This all works fine.
That's good.
Just for my education I switched the client WLAN profile to computer (!) authentification (instead of user), just to see what will happen with freeradius.
FreeRADIUS just processes packets it receives. It does NOT create those packets, or any information in them.
Now the User-Name is the real PC hostname "host/DESKTOP-FLOQN5Q". So it seems the outer and the inner tunnel see different User-Names. Is this on intention?
Ask Microsoft how their software works.
FreeRADIUS just reports on what it sees. It does not (and can not) cause the Windows system to send different User-Names.
In this instance "host/RadiusClient" comes from the EAP-Identity-Response packet sent by the Windows device just as it's starting 802.1X authentication, and "host/DESKTOP-FLOQN5Q" is the identity received within the TLS protected inner-tunnel of the PEAP protocol.
Looks like the Windows 10 supplicant is implementing identity privacy for host authentication, and that's why the first (unprotected) identity is generic, and the second (protected) identity is specific to the host.
You can likely control the unprotected identity by configuring a specific anonymous outer identity in the supplicant. That option used to be there for user-based authentication, not sure if it still exists or is configurable for host-based authentication.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html