The case of the... The Sign-in method you're using isn't allowed
In this category I publish blog post explaining a problem and the solution but more important the analysis that lead to the root cause.
The name is a homage to “The Case of the Unexplained” from Mark Russinovich.
The error
You are using the sign-in feature on a Windows virtual machine in Azure with Azure Active Directory authentication, and users receive the following error message when they sign-in.
Microsoft’s Troubleshooting Guide describes that the cause is a conditional access policy configured with multi-factor authentication (MFA), an unsupported Windows 10 client version, and Windows Hello for Business not enabled.
But what if all the conditions are met?
- The client has Windows Hello for Business configured
- The installed Windows 10 version is 1809 or newer
For sign-in with biometrics this is necessary, with PIN it worked longer.
The analysis
Eventlog
The security event log on the server was not very fruitful.
The sign-in event is logged with an incorrect login in the context of the SYSTEM account.
EventID | 4625 | An account failed to log on |
SubjectDomainName | WORKGROUP | |
SubjectLogonId | 0x3e7 | SYSTEM |
TargetUserSid | S-1-0-0 | SYSTEM |
Status | 0xc000006d | An account failed to log on |
FailureReason | %%2304 | An Error occurred during Logon |
SubStatus | 0xc0000250 | |
LogonType | 10 | Remote interactive logon |
LogonProcessName | User32 | |
AuthenticationPackageName | Negotiate |
Further information could not be found on the server.
Azure AD Sign-In logs
Since this is a login to Entra ID (Azure AD), there must be other logs available.
Interactive Sign-In logs
There is no information about this login in the interactive sign-in logs. This was to be expected, since the sign-in with Windows Hello for Business is not interactive, but is performed with the Entra ID (Azure AD) user certificate.
Non-interactive Sign-In logs
In the first step, I only filtered for incorrect logins for the affected user.
The following Windows Sign-In logs caught my eye. The sign-in is done at the Policy Administration Service from an IP address from the Microsoft data center in Amsterdam (West Europe).
The important thing about the non-interactive logs is that the events are grouped together. By default, all events of a day are displayed together and can then be expanded.
The error message in this case was clear:
A look at the Device Infos shows that the server is listed as noncompliant.
The root cause
In this case, this is completely correct. The Windows Server is not managed by Intune and should not be without official support.
However, the conditional access policy in question always requires a compliant device when signing-in to cloud apps.
If you want to find all affected users, you can use the following KQL query in the Entra ID (Azure AD) logs.
AADNonInteractiveUserSignInLogs
| where AppId == "38aa3b87-a06d-4817-b275-7a316988d93b"
| where ConditionalAccessStatus == "failure"
| sort by CreatedDateTime
| project CreatedDateTime, UserPrincipalName,AppDisplayName, AppId, IPAddress, ConditionalAccessStatus, ConditionalAccessPolicies
The solution
The solution is to exclude the cloud app “Azure Windows VM Sign-In” from the corresponding Conditional Access Policy.
This is somewhat unintuitive, as the app shown in the log is the Policy Administration Service. Fortunately, Microsoft has already documented the correct app in the exception for MFA authentication.