TL;DR
It seems, Mikrotik User Manager always enforces EAP identity string to be identical with "username" in client's certificate (SubjAltName / CN ), when doing EAP-TLS authentication.
Although, this enforcement is discouraged by RFC. More so, it can break Windows compatibility.
Whenever using Windows' "computer authentication mode" for EAP authentication, Windows adds the prefix "host/" to EAP identity. In those cases, EAP identity and "username" in cert cannot be identical, User Manager rejects access.
It would be great, if Mikortik developers could fix this issue. A hotfix could presumably be done in a minute's time.
---
Regarding EAP-TLS authentication there are two entities to point out:
- SubjAltName / CN in client's certificate, also referred to as "username" sometimes
- EAP identity, just an additional string sent by supplicant during EAP auth
Whilst those two may seem similar, actually they are not.
Regarding RFC, implementations should authenticate against certificate's SubjAltName / CN, only. But should not authenticate against EAP identity.
EAP identity is not primarily meant for authentication but other purposes, like request routing for instance. Therefore RFC explicitly discourages implementations to enforce EAP identity string being identical with SubjAltName / CN in cert.
RFC5216 quote:
https://datatracker.ietf.org/doc/html/r ... ection-2.2It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use.
...
Since the identity presented in the EAP-Response/Identity need not be related to the identity presented in the peer certificate, EAP-TLS implementations SHOULD NOT require that they be identical.
Putting this together we may conclude that User Manager doesn't behave fully RFC compliant.
Since most major operating systems provide means to explicitly set EAP identity string in EAP configuration, users can take care themselves, that EAP identity is always identical with "username" in cert, as kind of a workaround in every day use.
Yet, when it comes to Windows, it seems you cannot modify, what Windows supplicant will send as EAP identity.
Basically, Windows has two modes for EAP-TLS authentication:
- user authentication mode
- computer authentication mode (also referred to as machine authentication mode)
Regarding "user auth mode", Windows will send what it finds in client's certificate SujbAltName / CN and send this as EAP identity. Let's say we have a cert with CN="my-username", Windows will just send "my-username" as EAP identity, so authentication should succeed even with User Manager.
When using "computer auth mode", though, Windows will add the prefix "host/" to EAP identity, thus now sending "host/my-username". Obviously, "host/username" cannot be identical with "username" in cert, and User Manager will reject access.
At this point, User Managers non-RFC-compliant behavior actually breaks Windows compatibility.
A very simple yet sufficient kind of hotfix solution could be to let User Manager just ignore the "host/" prefix, by removing the prefix from EAP identity string whenever found there.
This could be done with a single line of code in a minutes time and would already solve a lot in regards to practical every day use. Since User Manager doesn't allow slashes "/" in usernames anyways, this change shouldn't break existing installations, as well, and not require much testing.
Yet, generally speaking, it might be advisable to re-think about User Manager's behavior in order to make it more RFC compliant.
Regarding to RFC, User Manager should authenticate against "username" found in SubjAltName / CN only, but not authenticate against EAP identity string.
Doing so, User Manager must, of course, check that username in radius db is identical with username in client cert (SubjAltName / CN).
When it comes to EAP identity, though, User Manager shouldn't enforce EAP identity string to be identical with username in cert, nor EAP identity to be identical with username in radius database. Maybe User Manager should just ignore EAP identity, for now.