Microsoft Entra Internet Access for iOS in Public Preview!
With the latest update to Microsoft Defender for Endpoint on iOS, Organisations licensed for Microsoft Entra Suite or Microsoft Entra Internet Access will have access to Microsoft's Secure Web Gateway (SWG) and traffic forwarding for HTTP/HTTPS traffic, with support for Web-Content Filtering. This has been a huge win for iOS Mobile Security. Previously, Defender for Endpoint on iOS has supported Phishing Protection, M365 Traffic, and Entra Private Access Traffic. Combined with Global Secure Access Threat Intelligence, which consumes indicators from Microsoft Intelligent Security Graph (ISG), Organisations can implement granular internet access controls on iOS devices with integrated, context aware protection against malicious threats. Excited to hear what you think! Release notes are available here👉 Microsoft Entra in Action: From Conditional Access to Identity Protection
One of the areas I’m most passionate about is identity-driven security. Microsoft Entra makes it possible to apply Zero Trust principles directly at the identity layer. ⚡ Conditional Access – the backbone of modern access policies. 👤 Privileged Identity Management (PIM) – ensuring just-in-time, least privilege for admins. 🛡️ Identity Protection – risk-based policies to stop compromised sign-ins in real time. In my labs, I’ve seen how these features transform security posture without adding friction for users. Coming soon: - Step-by-step breakdown of a risky user detection scenario. - A visual guide to Conditional Access controls for critical apps. Would love to exchange insights with others experimenting in this space — what Entra features are you finding most impactful? #MicrosoftEntra | #ConditionalAccess | #IdentityProtection | #MicrosoftLearn | #PerparimLabs
Unable to add Azure Virtual Desktop Client Enterprise App to Conditional Access
We currently use conditional access to allow certain contractors to sign into VMs, and from these VMs, access other MS Apps. Currently we block all applications from outside the VM ip range, but exclude the Virtual desktop applications to allow the users to do the initial signin to the VM. When contractors are using the Virtual Desktop app, it seems to work ok. However, recently when signing in via the browser only and launching from there, the conditional access rule is blocking them as the application ID isn't in the exclude list, and we are unable to add it: a85cf173-4192-42f8-81fa-777a763e6e2c The documentation: https://learn.microsoft.com/en-us/azure/virtual-desktop/set-up-mfa?tabs=avd shows that web signins may originate from this application ID, but without the ability to add this to the exclusion apps, we cannot find another workaround that allows access via the browser. I also tried adding this app in to the policy via GraphAPI, but I get an error saying that this first party application isn't allowed. I need to know if there is another workaround or if Microsoft are planning to add this to the CA compatibility list? I'm not sure why some of the Virtual desktop apps are there but this one is not.
Conditional access, Persistant Browser sessions and Azure File shares in Storage Accounts
Hello, I am in the process of doing a POC for Azure file sync from DFS to Azure file shares with a end goal of using Azure files shares and getting rid of DFS. I want to use Entra for identity access. One of the changes I need to make is set Persistant browser session in our MFA all user policy to "Never" so that the storage enterprise app does not get targeted for MFA, otherwise it wont work. How do I go about doing this without effecting any other users as it's a global policy. I know I need to do this because I get this error when I add the Storage Account ent app to the targeted resources (formerly cloud apps) exclusion list; "Message from server: The server could not process the request because it is malformed or incorrect. 1032: ConditionalActionPolicy validation failed due to InvalidConditionsForPersistentBrowserSessionMode." Any ideas of how to get around this without affecting anyone else and only target the storage account ent app. Cheers
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
