Disable MFA for User with certain admin roles
Hello all, we have a user with sharepoint administrator role and a self build application support manager role (the suer is allowed to create apps in Azure). We are now at a point where this user has to register an app for our helpdesk tool, but we have to remove the MFA for the registration. We excluded the user from the "MFA is mandatory for all users"-policy, the "MFA is mandatory for admins"-policy and set his MFA in the MFA-per-user setting on disabled. We have no other policy that enforces MFA for this user. Wenn we try to log in with the user (under http://www.office.com), we still get the request to register MFA Authenticator. I am aware that MS enforced MFA for admins, when they try to log in into the admin portals. Does this also apply for sharepoint admins? Does anyone have an idea, where the MFA request for this user could come from. Any help is appreciated. Cheers, Erik
employeeType attribute for Dynamic Group features
Dear Microsoft, I would like to suggest the feature of Dynamic Groups to support the employeeType attribute. As dynamic groups are used by features like Identity Governance Auto-Assignment policies and could be the base for Conditional Access Policies, this feature would be aligned with the Secure Futures Initiatives and the Conditional Access Policy Architecture implementation recommendation using various personas (Conditional Access architecture and personas - Azure Architecture Center | Microsoft Learn) as well as the Microsoft Recommendation not to use extensionAttributes for purposes other than a Hybrid Exchange deployment, as well as having Named Attributes for such important security configurations and Entitlement Management. Thanks, BUnwanted MFA Method Options Displayed During Login
We have DUO configured and enforced as an MFA provider via an external authentication setup. However, during the login process, users are still being presented with additional method options, including: • Email (Receive a code to reset password) • Hardware token (Sign in with a code from a hardware token) • Phone (Call or text) • Microsoft Authenticator We want to remove at minimum the Email and Hardware token options from being shown, as these are not approved methods in our security policy. They are shown as disabled in Entra with the screenshots provided. What’s been done: • DUO is configured as an external authentication method • An exemption group has been added in Azure AD Authentication Methods policy to exclude users from using SMS and Microsoft Authenticator, yet users are still prompted to set up another authentication method during login We are in the process of transitioning users over to DUO so still need to have Microsoft authenticator as an option, but want users who are configured to use the DUO authentication method to not require another form
Intermittent Non-Compliant Status on Chrome Sessions - Resolved by Switching to Edge
We are experiencing an intermittent issue where certain users' devices are marked as "non-compliant" in Intune, even though there are no visible problems with the Chrome session. Interestingly, the issue resolves itself when users switch to Microsoft Edge and then return to Chrome. Has anyone else encountered this issue? Is there a known root cause or workaround for this behavior? Any guidance on how to prevent this from happening would be greatly appreciated!Conditional Access Policy Loop with Edge on BYOD Devices – Need Help!
Body: Hello Tech Community, I’m facing an issue with an Azure AD Conditional Access Policy that seems to be causing a loop when users access Office 365 resources using Microsoft Edge on Windows 11 24H2 BYOD devices. Here’s the scenario: Problem: The policy is titled "Require App Protection Policy for Edge on Windows for All Users when Browser and Non-Compliant-v1.0" and continuously prompts users to switch profiles in Edge. These devices are BYOD and intentionally excluded from full Intune management (non-compliant by design). However, Edge repeatedly requests authentication or profile switching, creating a frustrating experience. Policy Details: Applies to: Windows devices using browsers (primarily Edge). Excludes: Compliant devices or those with trustType = ServerAD. Includes: Office 365 applications. Excludes Groups: Certain groups that should bypass the policy. What I’ve Tried: Verified device compliance status in Azure AD and Intune. Checked Azure AD Sign-In Logs for errors or repetitive authentications. Cleared Edge browser cache and cookies. Ensured Edge is configured to use Windows sign-in information. Adjusted the App Protection Policy settings for Edge. Questions: Could this be an issue with how Edge handles profile authentication in Conditional Access scenarios? How can I ensure that BYOD devices remain excluded from full Intune management but still work seamlessly with this policy? Are there specific adjustments I can make to the Conditional Access or App Protection Policy to avoid these loops? Additional Context: My goal is to secure access using App Protection Policies (MAM) for BYOD scenarios without requiring full device enrollment in Intune. Any insights, suggestions, or similar experiences would be greatly appreciated! Thank you in advance for your help!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?Users Cannot Change Passwords – Conditional Access Blocking Office 365 Portal (Non-Admin Scenario)
Hi everyone, I’m encountering an issue with Conditional Access that I’d like some input on. 🛑 The Problem: Users are unable to change their passwords (e.g., using Ctrl + Alt + Del on Windows) because access to the Office 365 Portal is blocked by our Conditional Access configuration. The error message states: Access has been blocked by Conditional Access policiesTarget app: Office 365 Portal (App ID: 00000006-0000-0ff1-ce00-000000000000) According to Microsoft documentation, this portal is not classified as an admin portal, yet access is being blocked. ⚙️ The Configuration: We have a Conditional Access policy that: Targets all users Excludes admin accounts Applies to Microsoft Admin Portals Action: Block access This setup worked as designed for preventing users from accessing admin portals — admins can access, users are blocked. However, now when regular users attempt to change their passwords, they seem to trigger access to the Microsoft 365 Portal, which is getting blocked by the policy. ❓ My Questions: Why is the Office 365 Portal (non-admin) being affected by a policy scoped only to admin portals? Is there a recommended exception or configuration change that allows users to perform password changes securely without lifting the block on admin portals? Could this be related to how Microsoft identifies the portal/app in the Conditional Access policy backend? Any insights or experiences with similar setups would be greatly appreciated! Thanks in advance for your help.
Authenticator not displaying numbers on MacOS
I'm have an issue with MFA on a Mac (all the latest versions). We have conditional access policies in place, so once a day I'm prompted for MFA (I work off-site) and the Office app (e.g. Outlook, Teams) will create the pop-up window that 'should' display a number that I then match on my phone. My phone see's the push notification, but the Mac never creates the numbers in the first place. The pop-up is there, just no number. The workaround is: Answer 'its not me' on the phone On the Mac, select 'I can't use Authenticator right now' Tell the Mac to send a new request This time it creates the number and I can authenticate on the phone. It only appears to happen for the installed Office applications i.e. if I'm accessing applications/admin-centre via the browser, then the pop-up is within the browser and everything works first time. Is this a known issue?
