The case of the... The Sign-in method you're using isn't allowed

The case of the...

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.

The sign-in method you’re trying to use isn’t allowed. Try a different sign-in method or contact your system administrator.


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


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 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 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:

Failure reason
Device is not in required device state: {state}. Conditional Access policy requires a compliant device, and the device is not compliant. The user must enroll their device with an approved MDM provider like Intune.


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 Azure AD logs.

| 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.