Repository navigation
Fix: Add setting 'Configure Web Sign In Allowed Urls'. Resolves #143. - #266
coredotbin wants to merge 1 commit into
Conversation
…oTheEndpoint#143. Add the setting 'Configure Web Sign In Allowed Urls' with value 'mysignins.microsoft.com'. This resolves an issue preventing MFA setup page from loading when signing in to web sign-in with an account that has not yet set up MFA.
|
@coredotbin I did read your other post as well (issue #143), but I’m still not clear on the scenario where this becomes an issue. With Passwordless Experience enabled, as it is in OIB, TAP is the only credential a user can use to sign in if they haven’t yet registered another authentication method, such as a hardware passkey. I haven’t encountered any issues signing in to Windows with a TAP and then being guided through WHfB setup. Similarly, a TAP can be used to bootstrap Microsoft Authenticator on a mobile device. One use case I’m curious about is organizations that have gone strictly passwordless with hardware passkeys (with or without WHfB too). If Web Sign-in allows a new user to bootstrap hardware passkey registration directly from the Windows sign-in screen, I can see real value in that and would be supportive of the change. The question I’d want answered before enabling this in a baseline, though, is whether this registration path remains subject to Conditional Access policies targeting Register security information. For example, if security-method registration is restricted to trusted corporate locations, is that restriction still enforced through Web Sign-in allowed MFA setup? If this path bypasses those controls, it could create a pinhole that a hardened baseline such as OIB should avoid. |
Add the setting 'Configure Web Sign In Allowed Urls' with value 'mysignins.microsoft.com'. This resolves an issue preventing MFA setup page from loading when signing in to web sign-in with an account that has not yet set up MFA.