Event banner
Event details
We have been struggling at implementing MFA for windows login, it seems that the only way to reliably enforce requiring 2 factors is to disable all the built-in credential providers that only use one factor, notably disabling the traditional password provider which breaks things like LAPS. Leaving only credential providers that themselves enforce the 2FA such as smartcard/FIDO token providers, Windows Hello for Business, or third-party providers made by companies like DUO or yubikey.
Further when using WHfB there isn't a reliable way to audit which methods users configure for logging in. This is worrying since users can bypass configuring additional credential providers, or at least the fingerprint provider I was able to test with. This happens because the screen the user is confronted with appears to have been reused form the standard OOBE, which has a skip button, which when used will allow the user to bypass the requirement. On subsequent logons only needing a combination of a PIN and password
RichardWakeman
Microsoft
MicrosoftHowdy Seamus, for Windows login, we do recommend WHfB paired with FIDO2 for unphishable MFA. We have a great roadmap to extend to dirived credentials and a managed Authenticator app. Once you establish the hybrid identity / cloud identity with Azure AD, you can support SSO into legacy authn methods like LDAP, Kerberos, NTLM, etc. via proxies. Our first party solution includes the Azure App Proxy. Our partners also offer solutions such as F5, Cisco, etc. As for enforcing the WHfB using a specific authn method, you may control that with GPO's and with MEM (Intune) with local policies. Many of our customers choose to lay down a STIG for Windows & Office to help with hardening the end-point as well, so it may be used as a compliant device in Azure AD Conditional Access Policies. Lots to unfold here, but should steer you in the right direction.
- Thank you for pointing me to the STIGs I've been meaning to take a look in that direction. Currently we are just using the Windows 365 sec baseline in Intune. SSO is also on our radar as something we want to implement. Which is why we are focusing on ensuring the strong token generated by the windows login /WHfB is actually generated from a 2FA authentication and not relying on the devices TPM as an authentication factor (we feel that MFA should authenticate the user not the device). -- We have experimented with the GPO/Intune method. Unfortunately, this does not solve any of the problems I noted. It currently only includes PIN, Fingerprints, Facial recognition and trusted signals as options in the GPO. Is Microsoft planning on adding the other methods to these options such as FIDO keys? Ideally it would be useful to split the policy into two groups, one group of providers that count as a single factor and a second group for providers like FIDO/certificate which are inherently 2FA.
- RichardWakemanHave a read of Ehud's blog. He will be updating it for CMMC 2.0 soon, but will let you know where we stand on WHfB using the TPM as a factor for authn. https://techcommunity.microsoft.com/t5/public-sector-blog/satisfying-cmmc-level-3-ia-3-083-mfa-requirement-with-windows/ba-p/2122250?msclkid=575b26a0ba9211ec9a547dd766d98cab. We do support FIDO2 today in WHfB + GPO enforcement.
- we might be talking about different GPOs. Here's a link to the documentation I was looking at. https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock Ideally this would have some sort of group c for credential providers that have inherent 2fa.