Entra Enterprise apps and App registrations - Global Secure Access - Conditional Access Block
I am working on a rollout for Global Secure Access and ran into an issue with Entra Enterprise apps setup in the tenant. With Global Secure Access I have a Conditional Access Policy set to Block access to All Resources excluding some resources like Intune and Defender tap required for mobile setup. When I added an administrator account which had done some Enterprise application setup and authorization for various third-party applications, those third-party applications stopped working with failed logins indicating token access issues. Upon review I found the majority of applications to be using client secret authentication with this administrator account as the authorizer. My limited knowledge of Enterprise apps leads me to believe this client secret is an application password that the third-party uses to keep generating tokens based on the authorizing account. My questions surrounding this setup and further understanding are mainly in relation to how Enterprise apps and app registrations authenticate, as well as user authentication directly. 1. How does the token authorization work? Does the application just use the client secret to authenticate as the user who authorized it to generate an access token? Why does MFA requirements and changing passwords not affect this but specific Block policy does? 2. What are best practices in relation to authorizing third-party applications? My thoughts are a dedicated account to authorize applications when needed. 3. How will this work with applications regular users use? Say a user has a digital notebook that syncs with their OneNote or a calendar app that syncs calendars between Outlook and their website. Do these applications also use client secrets with the user's token and will break when added to the GSA setup I have? Is the only way around this to authorize with an admin account for token issuance? Thank you for your time reading this and any insight you may have for any of the questions or ideas mentioned.
Conflict status after having 2 Local user group membership Policy
Hello, I have an issue with applying two "Local User Group Membership" policies on a PC. The Intune policy report shows a conflict between having two "Local User Group Membership" policies despite having different configurations. For example, one is a Global Policy, which applies an admin privilege to all PCs, and the other one is more specific to a certain group, and it is just about giving remote access to the PCs on this group. So, my question is, why does Intune mark these two policies as a conflict of each other? If it is not possible to have two "Local User Group Membership" policies applying to the PC. Is there a way to have a global policy for admin users on the PC and one more private policy for remote user access using "Local User Group Membership"?
From “No” to “Now”: A 7-Layer Strategy for Enterprise AI Safety
The “block” posture on Generative AI has failed. In a global enterprise, banning these tools doesn't stop usage; it simply pushes intellectual property into unmanaged channels and creates a massive visibility gap in corporate telemetry. The priority has now shifted from stopping AI to hardening the environment so that innovation can run at velocity without compromising data sovereignty. Traditional security perimeters are ineffective against the “slow bleed” of AI leakage - where data moves through prompts, clipboards, and autonomous agents rather than bulk file transfers. To secure this environment, a 7-layer defense-in-depth model is required to treat the conversation itself as the new perimeter. 1. Identity: The Only Verifiable Perimeter Identity is the primary control plane. Access to AI services must be treated with the same rigor as administrative access to core infrastructure. The strategy centers on enforcing device-bound Conditional Access, where access is strictly contingent on device health. To solve the "Account Leak" problem, the deployment of Tenant Restrictions v2 (TRv2) is essential to prevent users from signing into personal tenants using corporate-managed devices. For enhanced coverage, Universal Tenant Restrictions (UTR) via Global Secure Access (GSA) allows for consistent enforcement at the cloud edge. While TRv2 authentication-plane is GA, data-plane protection is GA for the Microsoft 365 admin center and remains in preview for other workloads such as SharePoint and Teams. 2. Eliminating the Visibility Gap (Shadow AI) You can’t secure what you can't see. Microsoft Defender for Cloud Apps (MDCA) serves to discover and govern the enterprise AI footprint, while Purview DSPM for AI (formerly AI Hub) monitors Copilot and third-party interactions. By categorizing tools using MDCA risk scores and compliance attributes, organizations can apply automated sanctioning decisions and enforce session controls for high-risk endpoints. 3. Data Hygiene: Hardening the “Work IQ” AI acts as a mirror of internal permissions. In a "flat" environment, AI acts like a search engine for your over-shared data. Hardening the foundation requires automated sensitivity labeling in Purview Information Protection. Identifying PII and proprietary code before assigning AI licenses ensures that labels travel with the data, preventing labeled content from being exfiltrated via prompts or unauthorized sharing. 4. Session Governance: Solving the “Clipboard Leak” The most common leak in 2025 is not a file upload; it’s a simple copy-paste action or a USB transfer. Deploying Conditional Access App Control (CAAC) via MDCA session policies allows sanctioned apps to function while specifically blocking cut/copy/paste. This is complemented by Endpoint DLP, which extends governance to the physical device level, preventing sensitive data from being moved to unmanaged USB storage or printers during an AI-assisted workflow. Purview Information Protection with IRM rounds this out by enforcing encryption and usage rights on the files themselves. When a user tries to print a "Do Not Print" document, Purview triggers an alert that flows into Microsoft Sentinel. This gives the SOC visibility into actual policy violations instead of them having to hunt through generic activity logs. 5. The “Agentic” Era: Agent 365 & Sharing Controls Now that we're moving from "Chat" to "Agents", Agent 365 and Entra Agent ID provide the necessary identity and control plane for autonomous entities. A quick tip: in large-scale tenants, default settings often present a governance risk. A critical first step is navigating to the Microsoft 365 admin center (Copilot > Agents) to disable the default “Anyone in organization” sharing option. Restricting agent creation and sharing to a validated security group is essential to prevent unvetted agent sprawl and ensure that only compliant agents are discoverable. 6. The Human Layer: “Safe Harbors” over Bans Security fails when it creates more friction than the risk it seeks to mitigate. Instead of an outright ban, investment in AI skilling-teaching users context minimization (redacting specifics before interacting with a model) - is the better path. Providing a sanctioned, enterprise-grade "Safe Harbor" like M365 Copilot offers a superior tool that naturally cuts down the use of Shadow AI. 7. Continuous Ops: Monitoring & Regulatory Audit Security is not a “set and forget” project, particularly with the EU AI Act on the horizon. Correlating AI interactions and DLP alerts in Microsoft Sentinel using Purview Audit (specifically the CopilotInteraction logs) data allows for real-time responses. Automated SOAR playbooks can then trigger protective actions - such as revoking an Agent ID - if an entity attempts to access sensitive HR or financial data. Final Thoughts Securing AI at scale is an architectural shift. By layering Identity, Session Governance, and Agentic Identity, AI moves from being a fragmented risk to a governed tool that actually works for the modern workplace.How to foce intune client in Ubuntu to synch automatically
Hello, in my company we have enrolled Devs Ubuntu devices to control some security setting and allow or not the access to our company apps and content. We have set compliance policies and enabled conditional access to check its. i have been surprised this morning by the last checking date of my Ubuntu laptops and ask my Devs of last signin in company portal client and the date match with the last checking date. I concluded, the company portal is synching only when the user open it and signin. This is a big problem for us because we are certified ISO27001 and we must check all devices compliance. Somebody has a script to deploy on those ubuntu devices and force a synch every day waiting for a Microsoft evolution of this process. Thanks a lot and regards Majid
Conditional Access Policy Not Allowing Users to Access AVD
We have an existing conditional access policy which requires a users' device to be marked as "compliant" in order to access "All Agent Resources". We are trying to deploy an AVD as an alternative to allowing users to use personal devices, but this CA policy seems to be interfering with users being able to access the AVD via Windows App. Yhe device they're accessing from isn't "Compliant" with Intune enrollment being one of the requirements for being compliant. Again, we do not want to allow personal devices into Intune which the MSP allowed previously. For the CA policy it's applied to all users EXCEPT for specific users in an exclusion group. Putting users in this exclusion group allows them to access the AVD via Windows App but at this point they can just access all resources from their personal machine defeating the purpose of the AVD. Target Resources Include All Resources Exclude: The AVD Itself, Windows 365, Azure Virtual Desktop, Azure Windows VM Sign-in Conditions Device Platforms - Windows, MacOS Client apps - Browser, Mobile apps and desktop clients, exchange ActiveSync clients, other clients are checked Grant Access Require MFA and Require device to be marked as compliant are both checked. Access to the AVD works in the browser but not in Windows App.
Cert Based Auth no longer working on Android devices.
Curious as to how wide spread this is/will be. Windows and iOS is fine, only affecting android. You can easily test this by revoking MFA sessions on a user who is using cert based auth on a android phone. I'm not sure if there has been a update recently to Android Microsoft Office apps where it thinks the certs live inside the intune company portal and is not looking for certs in the phones cert store. BYOD work profile Android 14 phones are being problematic, when a user changed their password and Azure revoked their sessions for a reauth, the issue started occurring. I tested this on another user manually revoking their MFA sessions without changing their password same issue occurred. I also setup a brand new Android phone and had the same issue after enrolling it. The issue is when the user opens outlook or teams and goes to sign in, it will pop up asking to use a cert on the device or a physical key. When selecting on the device the phone will freeze it will then eventually say ""company portal isn't responding" with the options of wait or cancel. Opening chrome in the work profile and going to a office app site will popup asking for the cert and works fine. So the issue doesn't appear to be the phone getting the cert, just the Office Apps are not accessing the Phones cert Store. I can confirm the Cert is inside the work profile as a browser or cert viewer app inside the workprofile can see it, auths work fine when using a browser in work profile, just not outlook or teams inside the work profile.Global Secure Access - Conditional Access Require GSA - Android Blocked
Hello all, I am currently working on deploying Global Secure Access client with Microsoft Forward Traffic profile and a conditional access policy to block access to M365 services unless connected through the GSA client. I have this working as I want it for Windows and mobile devices in a tenant we use for development. However, when I set this up at our live tenant, I cannot get the Android device to work. My setup is a Personally Owned Work Profile with the Defender app deployed and configured to enable GSA. I can connect to Global Secure Access and it does show some traffic tunneling to Microsoft. However, when I go to login to another app like Outlook, it blocks the sign-in. This is not the case for an iPhone I have personally enrolled and my Entra Joined laptop. Upon investigation of any differences between our development tenant (working fully) and our tenant (Android not working) I found that in the GSA section under Services, there is an extra service called “Microsoft Entra Channel Access”. This service does not show up when I am logged in our developer tenant. Even on the same phone by removing work profiles and signing in to both tenants, our live tenant shows the new channel, and the developer tenant does not have it. I did some log review with the advanced diagnostics feature and the app and noted a few things I am lead to believe that the issue is with this new Entra Channel that has been deployed to our live tenant and not to our dev tenant yet. When I go to sign-in to the Outlook application in the work profile for the developer tenant, I can see the authentication traffic being tunneled through the Microsoft 365 profile. (login.live.com, login.microsoftonline.com, and aadcdn.msftauth.net). However, in our production tenant when doing the same test I do not see those destinations being tunneled at all. I do see the traffic being collected in the “Hostname” section, but is not being tunneled. Another interesting point with this is that on an iPhone I am testing; I do see the authentication destinations being tunneled through the Entra Channel. Here are the screenshots of my findings. https://imgur.com/a/82r3HQC I have an open Microsoft support case and hoping to get the attention of a Microsoft employee or MVP who may be able to get this in front of the Entra product team to see if this is a bug.
Block all 365 apps except Outlook via CA
Trying to block 365 for a subset of users, except email. The old app-based CA rules made this easy. The new 'resource' based setup... I'm not even sure if it's possible. CoPilot just keeps telling me to use the old version of CA, because it hasn't clued into Microsoft's downgrade cycle. If I try to filter by resource attribute, I'm told I don't have permission to do so. I'm the global admin. Here's what searching for Outlook gives me and Exchange Advice? We ARE intune licensed, but i'm not sure App Protection Policies will help here. The intention is to block BYOD from accessing anything but Outlook / Exchange. That is, Mobile devices that aren't (whatever param I decide on)
