Tenho uma situação muito interessante que não consigo explicar. Tenho dois usuários em dois dispositivos. Ambos os usuários e dispositivos estão configurados da mesma forma. Eu literalmente verifiquei tudo e ambos os usuários e dispositivos são os mesmos no escopo da configuração e dos logs.
No entanto, o primeiro usuário (usando o mesmo navegador que o segundo) é solicitado a usar o método WHFB no modo anônimo como uma opção para passar a validação do MS Entra ID MFA ao fazer login em "office.com". O segundo usuário não tem essa opção (ele deve usar as opções regulares do MS Entra ID MFA).
A Microsoft está me dizendo aqui: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/faq que o WHFB não pode ser usado no modo anônimo. Bem, pela minha experiência, pode e eu me pergunto o que diabos está acontecendo aqui.
Aqui estão as opções para passar o MS Entra ID MFA no modo anônimo com métodos WHFB que foram definidos no primeiro dispositivo:
Estamos usando o Cloud Kerberos Trust em dispositivos híbridos unidos. Tudo está configurado corretamente. Cada log, resultado e depuração estão ok.
Descobri que o segundo usuário pode ser logado com WHFB no modo anônimo de um navegador quando escolho a opção "Sign-in options" no portal "login.microsoftonline.com" em vez de digitar o UPN do usuário. Quando eu digito UPN, vou para o nosso ADFS e então tenho que usar o MS Entra ID MFA (WHFB não é uma opção neste caso). Então, não sei por que o primeiro usuário é solicitado para WHFB após passar pelo ADFS e o segundo usuário não é solicitado para WHFB ao passar pelo ADFS. O que é mais importante é o fato de que o WHFB pode ser usado no modo anônimo de um navegador no nosso caso. Não sei sobre o que a MS está falando no link de perguntas frequentes sobre WHFB que postei aqui.
Então encontrei a resposta.
O problema é (por enquanto) que mesmo quando um usuário híbrido tem o WHFB implantado, provisionado e registrado, o MS Entra ID ainda mostrará o método clássico MS Entra ID MFA no "System preferred multifactor authentication method". Essas informações podem ser encontradas em MS Entra ID - {user} - Authentication methods.
Isso significa que mesmo quando você tem o WHFB registrado como um método de autenticação para um usuário, isso não afeta o "System preferred multifactor authentication method" - pelo menos não na minha experiência.
A coisa começa a ficar engraçada agora.
Quando você registra a chave FIDO2 HW em uma conta de usuário, o "método de autenticação multifator preferido do sistema" será alterado de um método clássico MS Entra ID MFA para FIDO2. Essa alteração afetará o fluxo de login. Você não será mais solicitado pelo método clássico MS Entra ID MFA, mas será solicitado pela chave FIDO2 ou método WHFB . Dessa forma, você pode usar o WHFB como um método primário para pular o método clássico MS Entra ID MFA. No entanto, quando você não tem a chave FIDO2 registrada em sua conta, o uso do WHFB como uma substituição do método clássico MS Entra ID MFA não é possível - você tem que usar o método clássico MS Entra ID MFA (WHFB não é uma opção aqui).
No entanto, seu WHFB está ativo e você ainda pode usá-lo, mas em "login.microsoftonline.com" você tem que selecionar "Opções de login" em vez de digitar seu UPN (e-mail). Quando você seleciona "Opções de login", você pode usar o WHFB para login sem senha. Ao digitar o UPN (e-mail), você estará no cenário com ou sem WHFB (com base no registro FIDO2) que descrevi.
Não sei se isso é algum bug temporário, design ruim ou se há alguma lógica por trás disso. Não entendo por que quando você pode usar o WHFB para login sem senha, você não pode usar o WHFB como um substituto para o método clássico MS Entra ID MFA. Bem, você pode usá-lo dessa forma, mas precisa registrar a chave FIDO2 na sua conta MS Entra ID.
Espero que a Microsoft conserte ou altere esse comportamento em breve, porque não faz sentido algum. Quando você estiver lendo isso, é possível que a lógica já tenha sido alterada pela Microsoft.