Windows App Application Protection Policy
I have been testing out an Intune MAM policy to restrict copy/paste and drive redirection to AVD session hosts based on the link here: Require local client device security compliance - Windows App | Microsoft Learn However, I've run into problems (in two separate tenants) that have halted me from being able to test. Setup Intune App Protection Policy targeting Windows Devices & Microsoft Edge\ Conditional Access Policy enforcing App Protection Policy when users access 'Azure Virtual Desktop' target resource via https://windows.cloud.microsoft.com Results First When signing into a user account targeted by the policy, they are prompted to Switch Edge Profile which signs in the user to a new Edge profile for 'Work or School Account'. The account has to sign in again. The account can access Windows App resources When launching a desktop session, this authentication page pops up for an account "local@debugonly" Second When signing into a user account targeted by the policy, they are prompted to Switch Edge Profile which signs in the user to a new Edge profile for 'Work or School Account'. The account has to sign in again. After sign in, the account loops with 'Switch Edge Profile' and gets stuck here I'm curious if anyone has gotten this to work and what was your setup? Or if Microsoft or provide some assistance or if this is in the wrong forum, any help would be appreciated.
Strengthening Enterprise Identity Security with Country Based Blocking in Conditional Access
In a Zero-Trust world, identity is the foundational security perimeter. Securing access begins with full visibility and control over authentication activity - including where login attempts originate. By continuously validating the context of every access request, organizations can detect threats early and enforce least privilege with precision. For public sector agencies and global enterprises alike, defending against unauthorized sign-ins from foreign locations is a top priority, especially when those locations fall outside the boundaries of legitimate business activity. Why Country-Based Blocking Matters Not every foreign login attempt is malicious but when your organization has no employees, contractors, or systems operating out of certain countries, any authentication activity from those regions should be treated as suspicious by default. We’ve seen organizations use this capability to: Block access from countries where they have no personnel or partnerships Reduce exposure to credential stuffing or token replay attacks from known threat regions Enforce geo compliance policies related to data sovereignty or regional restrictions This helps reduce risk without interfering with legitimate business operations—and it’s surprisingly easy to configure. Fortunately, Microsoft Entra ID (formerly Azure Active Directory) provides a powerful, often overlooked feature in Conditional Access: the ability to block authentication attempts by country using Named Locations. 🔧 Step by Step: How to Block Access by Country Using Conditional Access 1. Create a Named Location for the Country Go to the Microsoft Entra admin center (Entra Portal). Navigate to Protection > Conditional Access > Named locations. Click + Country location. Name the location (e.g., Blocked - China). Check the box for the country or countries you want to block (e.g., North Korea). Click Create. 2. Create the Conditional Access Policy Still in Conditional Access, click + Create New policy. Name your policy, e.g., Block Sign-ins from Forbidden Countries. Under Assignments: Users: Choose All users (or specific groups), and exclude your break glass accounts. Target resources: Select All resources (or target specific apps). Under Network: Set Configure to Yes. Include: Selected networks and locations, Choose the Named Location(s) you created earlier (e.g., Blocked - North Korea). This setup tells Conditional Access to apply the policy unless the sign-in is from an excluded location i.e., from a blocked country. Under Access controls > Grant: Select Block access. Enable the policy (set to On) or test it first by setting it to Report-only. Click Create. 🛡️ Best Practices Begin with Report-only mode to simulate the effect of your policy before enforcement. Exclude break-glass (emergency) accounts to avoid accidental lockout. Monitor sign-in activity in Microsoft Entra sign-in logs to validate the policy’s effect. Combine with sign-in risk policies or device compliance to further refine access decisions. Consider the service limits for Named Locations and IP address ranges. While these limits are generous and unlikely to affect most organizations, it is good practice to review them to ensure your design remains scalable. More details can be found in the Microsoft Entra service limits documentation. Final Thoughts Blocking access from foreign countries where your organization has no legitimate activity is one of the most straightforward and effective Conditional Access strategies available. It strengthens your authentication perimeter and supports a zero trust approach to identity security. However, it is important to remember that Named Locations should be part of a broader defense-in-depth strategy. Sophisticated attackers can use VPNs or proxy services to disguise their location, so country-based controls alone are not enough. For stronger protection, combine them with additional signals such as sign-in risk, device compliance, and multi-factor authentication. Whether you're protecting a government agency or a multinational enterprise, adding country-based controls to your Conditional Access policy set remains a simple but powerful step forward. 🧭 Ready to get started? Dive into the official docs here: ➡️ Block access by location using Conditional Access ➡️ Simplify Conditional Access policy deployment with templates - Microsoft Entra ID | Microsoft Learn
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!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!
