odd workstation login behavior on wireless

[ben.posner]

edit: new details below

has anyone else noticed some odd behavior for windows 10 workstations using machine auth for PEAP on wireless? i cannot confirm if this Win10 only yet as i don't have access to a test workstation running 7 or 8 that are attached to this domain.

we keep seeing in our ISE 2.1 auth logs workstations attempting to authenticate with Domain\WorkstationName$ and of course it gets dropped but we're not sure if it's related to our test workstations connecting pre-user login and then disconnecting just after the user logs in. the user then manually has to reconnect and usually things are fine.

here's a snapshot of what the auth log looks like:

the user has to manually select the SSID mutliple times over the login process as the client keeps disconnecting and i don't understand why.

here's a screenshot of that odd entry's details:

The SSID i'm using for this is configured like all of our others so i don't think it's that. thoughts?

EDIT: found the following bug: ISE rejects access-request does not contain the username attribute

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCva20683/?referring_site=bugquickviewclick

this sounds an awful lot like what i'm seeing. but the bug says "No release planned to fix this bug" which is outstanding...

open a case? devices won't automatically connect thanks to this stupid bug.

[Marvin Rhoads]

It kind of looks like a machine authentication attempt.

Is it possible that your NAM profile indicates that machine authentication should be attempted (but your ISE policy doesn't require it)?

[ben.posner]

Marvin, thanks for responding.

i agree it does look like a machine auth but it's crafted oddly. and we do require the machine auth as well as user auth so we can do MAR checks.

i worked around the issue by adding another identity rewrite rule to allow for the oddly formed machine auth as shown below.

this seems to be working. it doesn't explain why these workstations started sending this style of auth attempt all of a sudden, but that's probably a windows issue and out of my purview.

[gschmitt.ngit]

I am seeing the same issue.

We are requiring both wireless machine and user authentication. We are proving that the user is connecting through a corporate machine by checking that the user login contains the "Other Attribute AD-Host-Join-Point contains addomain.com".

The authentication/authorization process works correctly with the machine authenticating with "host/660-000958LT.addomain.com". This is followed shortly with an authentication that looks as thought it's a user authentication with the machine name as the user "ADDOMAIN\660-000958LT$". This fails with "Username attribute is not present in the authentication request". This is before the user actually logs into the laptop.

When the user logs into the laptop the user authentication/authorization is successful "ADDOMAIN\username". However the successful user connection shown on Live Logs is followed by two unsuccessful attempts with "11038 RADIUS Accounting-Request header contains invalid Authenticator field". Even after these failures, the user is on the wireless network and can operate without issue.

The architecture is machine: Windows 10 native supplicant set to machine and user authentication using PEAP/EAP-MSChapv2, ISE: v2.7 patch 4, wireless: Meraki MR45

[thomas]

Consider using TEAP for machine+user authentication without the need for MAR in Windows 10 20H1 and later.

TEAP for Windows 10 using Group Policy and ISE TEAP Configuration