Passwordless POC Blocked by CA BYOD Policy – Looking for Workarounds
We’re currently running a POC for passwordless authentication in our environment. One challenge we’ve hit is that our CA BYOD policy blocks personal devices, which prevents users from enabling passwordless sign-in via the Microsoft Authenticator app. Since Authenticator is not a cloud app, we can’t exclude it from the CA policy using the usual cloud app filters. This is causing issues when users try to register or use passwordless sign-in from their personal phones. Has anyone dealt with this scenario or found a workaround that allows passwordless sign-in while still enforcing BYOD restrictions? Any ideas, suggestions, or creative solutions would be much appreciated! Thanks in advance!
MFA claim expired - Breaking web apps
Hi All, Testing: - Passwordless (Phone Sign-in baseline) - Sign in Frequency (Shorter than tenant setting) - Desktops are hybrid, receiving their PRT but no not use WH4B - Tenant still has Remember Trusted device for X Days enabled I'm seeing some strange behavior where Azure AD is showing the MFA claim has expired when trying to access web portals (Auth loops, webapp access issues (Outlook fine but not Teams), error messages). If I revoke the session completely and re-login to the native app pop-ups, things are fine again for a while. If the user closes the native auth window, the native apps limp along even with the MFA claim issue within the browser but the webapps are still broken. WebApps continue to SSO in with the token in this state. Research is pointing that it might be the tenant wide remember trusted device settings, although I am not in a position to disable this global setting until after the test deployment. Disabling the SIF, seems to resolve the MFA claim expiry immediately, i'll check in a few days to see if that is still the case as it'd be outside the trusted device setting interval too. I have a support request at the moment with the advice to enable persistent browser sessions which I'll test but don't think that is the core of the issue. Is their a way around this, have others had similar issues? Thanks!
Fido passkeys blocked by policy
Hi all I'm helping out a customer with deploying physical passkeys and I'm running into a weird error. I've activated the sign in method and selected the two AAGuids for the Authenticator app and I've added the right AAGuid for the brand and model of passkey we are using. We can select the authentication method and enroll the security correctly but when trying to sign in using it we get the error as displayed in the attached picture. When checking the sign in logs i get this error message FIDO sign-in is disabled via policy and the error code is: 135016 I've not been able to track down any policy that would be blocking passkeys. anyone got any ideas?
Kid finds a way into my account using an old PIN
I have set up parental controls. Somehow my sone managed to find the password logged in the Microsoft Familly app and changed the settings at will. I have changed my password in the meantime but he found an easy way around it as he selects use other methods to sign in and then selects PIN, inputs my old PIN and he is back in. How is this possible? I have changed the password, I have changed the PIN, turned on 2FA and reset Windows Hello and he just goes around all this in one go by introducing my old PIN. Is there a fix for this ?
Disable Windows Hello AND Remove Existing PIN
Previously, after setting up Windows for an Azure AD user, it would give me a prompt saying that my organization requires a PIN for Windows Hello. I would hit next, then close the dialog asking for the PIN, and it would say there was an error or something, I'd hit OK and I'd be in Windows with no further Windows Hello harassment until I restarted. Once I got the device enrolled in Intune, it would apply the policy I have a policy that disables Windows Hello. However, a recent update to Windows seems to have made it impossible to bypass setting up a PIN. Because I can't enroll the device in Intune during the Windows Setup, the disable policy doesn't apply until after the PIN is established on the account. Once the PIN is set up on a Windows Account, it is not removed when Windows Hello is disabled via Intune/GPO, and it is seemingly impossible to remove manually. The only lead I've been able to find is to delete this folder: C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC\. However, Windows simply is not letting that happen, even after taking full ownership of the folder as a local admin. My only workaround is to first setup the device authenticating with my own account which will have the PIN. Then enroll in Intune with the user's account to their policies applied and Hello disabled. Then create the local admin account. Then add the users account. Then log into the local admin account and delete my account. Finally, log into the users account to create shortcuts and do QA. We use Bitlocker with a PIN that effectively does the same thing as Windows Hello with a PIN, except it also encrypts the disk. So I really don't see what it brings to the table besides a redundant password for users to memorize and extra help desk work when they forget it? How do I get devices configured without adding a bunch of work to get around Windows Hello?Issues with Passkey Login Hanging on "Connecting to Your Device"
Hi everyone, I'm currently working on enabling passkey login for some users. I have a test account where I enabled the passkey and enrolled it in Microsoft Authenticator. However, when I try to log in and scan the key, it hangs on "connecting to your device." Has anyone encountered this issue before? How can I find the root cause, and which log would show what might be blocking me? Thanks in advance for your help!
Entra ID FIDO2 with multiple accounts returns "something went wrong" for the first sign-in attempt
I am finding there seems to be a bug possibly with Entra ID authentication when using FIDO2. In a scenario where a user has multiple accounts registered on their FIDO2 security key or Microsoft Authenticator in the same tenant, the first time they sign in the authentication process only sees one account. For example, an IT staff member may have a separate account used for administrative access. The first authentication attempt returns Something went wrong, trying again shows both accounts registered on the FIDO2 device, and the login is successful. I am able to consistently reproduce this with both a hardware FIDO2 token and using Microsoft Authenticator Cross-Device authentication on Android. This happens when authenticating to the Azure Admin portal, some Microsoft 365 PowerShell modules and some 3rd party applications. Interestingly it seems that possibly a newer authentication library for developers fixes the problem. I used to have the behavior in Exchange Online PowerShell, but the most current version of it never has the problem. Does anyone else see this behavior?
Enable MFA method
Dear, Currently in our company, the authentication methods policy > Microsoft Authenticator defaults to “any”. Either “passwordless” or “Push”. It is possible to enable the following authentication method through a conditional access policy, currently it is enabled for some users. Desired authentication method: The current method is as follows: Can it be enabled for professional accounts or is it only focused on personal accounts? Thanks in advance.Phishing resistant MFA options for Entra ID Guest users
What are the phishing resistant MFA options for Entra ID B2B guest users who authenticate from an IDP that is not configured for inbound cross tenant trust? From our testing, there does not appear to be any way to use fido2/passwordless/certificate-based authentication with the guest account on the resource tenant. The following links appear to indicate that this is not supported. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strength-advanced-options#certificate-based-authentication-advanced-options-1 https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless#supported-scenarios-1 When we enable MFA requirements in conditional access policy for Guest users, the only option that seems to work is MS Authenticator which the user can enroll for on our tenant. Would switching the account from a B2B guest to an internal Guest allow something like CBA to function or is the only real option to enable cross tenant trust and force the user to enable MFA on the account in their home IDP?
