Recent Discussions
Priority Handling in GSA Client Forwarding Profile Rules
Hello, I would like to provide feedback and propose a functional improvement regarding priority control for forwarding rules in Global Secure Access (GSA). In our environment, we are using Microsoft Entra Private Access with a combination of CIDR-based rules and FQDN-based rules. We understand that it is not possible to create Enterprise Applications with overlapping IP address ranges. Based on this limitation, our current operational model is as follows: Administrators create Enterprise Applications using CIDR ranges that broadly cover entire datacenter networks. Access for application owners to specific servers and ports is defined using FQDN-based rules. With this type of configuration, when reviewing the list of rules shown in the GSA Client → Forwarding Profile → Rules tab, we can see that each rule is assigned a Priority, and the rules appear to be evaluated sequentially from top to bottom. From this behavior, it is clear that: DNS rules are evaluated first Enterprise Application rules are evaluated next Quick Access rules are evaluated last However, between CIDR-based Enterprise Application rules and FQDN-based Enterprise Application rules, there does not appear to be a clear or explicit priority model. Instead, the position — and therefore the evaluation order — seems to depend on the order in which the Enterprise Applications were created. As a result, even when we intend to apply a more specific FQDN-based rule for a particular host, the broader CIDR-based administrative rule may be evaluated first. In such cases, access can be unintentionally blocked, preventing us from achieving the intended access control behavior. After understanding this mechanism, we have been working around the issue by carefully controlling the creation order of Enterprise Applications — creating host-specific FQDN-based applications first, followed by broader CIDR-based rules. While this approach avoids the issue, it significantly increases administrative complexity and makes long-term management more difficult. Based on this experience, we would strongly appreciate enhancements such as: The ability to manually control rule evaluation order in the UI, or More intelligent and predictable automatic prioritization between FQDN-based and CIDR-based rules Such improvements would greatly enhance usability, predictability, and maintainability of GSA forwarding rule configurations. Thank you for considering this feedback.
Free Webinar: Microsoft Entra ID Break-Glass Accounts Done Right (Live Demo + Q&A)
Hi everyone, I’m hosting a free community webinar focused on one of the most common (and painful) Entra ID issues: tenant lockouts caused by break-glass account misconfiguration. This session is practical and demo-driven, and I’ll cover real-world scenarios I’ve seen involving Conditional Access and emergency access design. What we’ll cover Why every tenant should have at least two break-glass accounts Common misconfigurations that lead to lockouts Conditional Access exclusions: what works and what fails Recommended hardening approach (without blocking emergency access) Monitoring + alerting best practices Live demo + Q&A Who it’s for Microsoft 365 admins Entra ID / Conditional Access admins Security engineers MSP engineers The recording will be shared with registrants after the session. Registration link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_MjkwYzExNzItMzY4OC00NThmLTg2ZDYtM2ExMTRiNWYwMGZl%40thread.v2/0?context=%7b%22Tid%22%3a%224bb6dd74-2dd1-459b-b867-f51781e1e7ed%22%2c%22Oid%22%3a%2251c6a848-6393-44f9-bac5-21855d5c7c3d%22%7d Thanks! Jaspreet Singh
Orphaned TPM-bound Entra Workplace Join device — no tenant access, backend deletion required
I have a personal Windows device that remains stuck in a TPM-protected Workplace Join to a former Microsoft Entra ID tenant. I no longer have tenant access and am not an admin. Local remediation completed: - dsregcmd /leave executed as SYSTEM - All MS-Organization / AAD certificates removed - Device still reports WorkplaceJoined : YES Azure Support ticket creation fails with: AADSTS160021 – interaction_required Application requested a user session which does not exist. Tenant inaccessible / user not present in tenant. This is an orphaned Entra ID device object. Requesting guidance or escalation for backend deletion. Tenant ID: 99f9b903-8447-4711-a2df-c5bd1ad1adf7 Device ID: f47987f4-a20b-4c34-a5f7-40ab0f593c6c
Blocking User Mode Installation
Hi Experts, I have a Hybrid Azure AD Join environment with all Windows devices enrolled in Intune. I have removed Domain Users from the local Administrators group on all devices via an on-premises Group Policy from the Domain Controller (Restricted Groups / Local Admin configuration). But what I observe is users are still able to install application in user move no elevation, how can I block this so that when get get a prompt only IT team can enter their credentials which will allow install. Currently apps are being installed in Appdata folder under user profile. Thanks
AADSTS50105 error message is unreadable for end users — UX improvement suggestion
1. What’s wrong with the current error message a. It’s written for administrators, not users The message exposes: Internal system names (AADSTS50105) GUIDs (aaaabbbb-cccc-dddd-eeee-ffff01234567) Identity provider jargon (“direct member of a group with access”) None of this helps the person who sees the error decide what to do next. b. The actual problem is buried in a wall of text The real issue is simply: You don’t have permission to access this app. Instead, the message forces users to: Read a long paragraph Decode domain-specific language Guess which part matters Cognitively, this is high effort for low payoff. c. “Contact your administrator” is vague and unhelpful Users ask: Which administrator? IT? Security? App owner? Their manager? What should they say? Without context, users either: Ignore the error Forward screenshots randomly Open the wrong support ticket d. Error codes without guidance increase support load AADSTS50105 may be meaningful internally, but: Users don’t know whether to Google it Support teams receive unclear tickets (“it doesn’t work”) This paradoxically raises support cost instead of lowering it. 2. What a better error message should do A good error message answers four questions in order: What happened? Why did it happen (in plain language)? What can the user do next? Who specifically can help? And it does so in under 30 seconds of reading time. 3. Example of a much better error message You don’t have access to [APPLICATION] Your account (email address removed for privacy reasons) isn’t currently authorized to use [APPLICATION]. This usually means: You haven’t been added to the required security group, or Access hasn’t been requested or approved yet. What to do next If you believe you should have access, contact IT Service Desk or your [APPLICATION] owner and request access. Helpful details to include in your request Application name: [APPLICATION] Your email: email address removed for privacy reasons Error reference: Access not assigned (Error ID: AADSTS50105 — for IT use) 4. Optional but high-impact improvement: Add a “Request Access” button or link One-click takes users to: ServiceNow / Jira / internal form Auto-populates app name and user email Administrators configure support link when configuring the applicationRequest to enable preview feature - Face Check with CAP
Dear Microsoft, I am on a business premium plan for my home test tenant. I cannot raise ticket nor do I have an account manager. I know this is in private preview. I would like my tenant to be enabled to test this new Verified ID feature to have "Face Check" in CAP as one of the Grant conditions. tenant id: bc85b508-0107-4472-a49c-fc8cefd4f0d7 Thank you.
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.Convert Group Source of Authority to the cloud. Global Groups support?!
This is the exact feature we need, unfortunately it's also unusable for an existing environment. Does anyone know when Entra SOA will support global groups? We have ZERO universal groups and we are not going to convert into them.Does Rights Management Service currently support MFA claims from EAM?
We've been testing EAM (external authentication methods) for a few months now as we try to move our Duo configuration away from CA custom controls. I noticed today that when my Outlook (classic) client would not correctly authenticate to Rights Management Service to decrypt OME-protected emails from another org. It tries to open the message, fails to connect to RMS, and opens a copy of the email with the "click here to read the message" spiel. It then throws a "something is wrong with your account" warning in the Outlook client's top right corner. If I try to manually authenticate & let it redirect to Duo's EAM endpoint, it simply fails with an HTTP 400 error. When you close that error, it then presents another error of "No Network Connection. Please check your network settings and try again. [2603]". I can close/reopen Outlook and that warning message in the top right stays suppresses unless I attempt signing into RMS all over again. However.. If I do the same thing and instead use an alternate MFA method (MS Authenticator, for example), it signs in perfectly fine and will decrypt those OME-protected emails on the fly in the Outlook client, as expected. I verified that we excluded "aadrm.com" from SSL inspection and that we're not breaking certificate pinning. So all I can assume at the moment is that Rights Management Service isn't honoring MFA claims from EAM. Any experience/thoughts on this? Thanks in advance!Feature Request: DLP Controls for App Registrations Using Sites.Selected to Prevent PII/PHI Exposure
We’re using the Sites.Selected SharePoint API to restrict app access to specific sites, which is a great improvement over tenant-wide permissions. However, we’re increasingly concerned about the lack of native DLP enforcement at the app registration level—especially for AI-powered apps or integrations that may unintentionally access sensitive data. Does Microsoft offer any capability to safeguard against PII/PHI data transfer across the Graph API that can: Flag apps as restricted from accessing PII/PHI. Prevent apps from reading content labeled with sensitivity labels like “Confidential,” “PII,” or “PHI.” Enforce real-time inspection and blocking of Graph API calls that attempt to access sensitive data. Generate alerts and audit logs when apps approach or violate these boundaries. If not, are there plans to introduce these protections? Protection across all APIs is desirable, but currently our greatest concern are SharePoint APIs.
Workplace Benefits Program (earlier meaning: home Use)
Hello, let me describe our current situation: Tenant A: our first tenant, should be decom. soon Tenant B: our new productive tenant On Tenant A we are able to use the Workplace Benefits Program. Unfortunatelly we have to decom this tenant. so we have created an new one, Tenant B. Enterprise Agreement was transfered well to the new, but one topic is missing, we couldn't transfer the existing workplace benefits from A to B. Perhaps someone here has been in the same situation and has found a solution? Thanks a lot. best regards, MarkusIdentity, access, and agent governance—Microsoft Entra at Ignite 2025
Security is a core focus at Microsoft Ignite this year, with the Security Forum on November 17, deep dive technical sessions, theater talks, and hands-on labs designed for security leaders and practitioners. Join us in San Francisco, November 17–21, or online, November 18–20, to learn what’s new and what’s next across identity and access management to the forefront, with sessions focused on Zero Trust, agent governance, and securing AI-powered apps. Featured sessions: BRK243: Microsoft Entra: What's new in secure access on the AI frontier Strengthen your Zero Trust foundation, manage and govern the rising tide of agents, and enable AI to accelerate your success. BRK265: Secure access for AI agents with Microsoft Entra Discover, manage, govern, and protect agent identities and access—just as you do for human identities. LAB549: Strengthen your identity security posture with Conditional Access Learn safe rollout patterns and use the CA Optimization Agent (Security Copilot in Entra) to find and fix gaps with one-click and phased enforcement. Explore and filter the full security catalog by topic, format, and role: aka.ms/Ignite/SecuritySessions Why attend: Ignite is the best place to learn about new Microsoft Entra capabilities for agentic AI, identity governance, and secure access. We will also share its vision for the future of identity and agent management. Security Forum (November 17): Kick off with an immersive, in‑person pre‑day focused on strategic security discussions and real‑world guidance from Microsoft leaders and industry experts. Select Security Forum during registration. Register for Microsoft Ignite >Join Merill Fernando and other guests for our Identity and Network Practitioner Webinar Series!
This October, we’re hosting a three-part webinar series led by expert Merill Fernando for Identity and Network Access practitioners. Join us as we journey from high-level strategy to hands-on implementation, unifying identity and network access every step of the way. Each session builds on the last, helping you move from understanding why a unified approach matters to what are the foundations to get started, and finally to how to configure in practice. The goal is to equip you with actionable skills, expert insights, and resources to secure your organization in a unified, Zero Trust way. Register below: Identity and Network Security Practitioner Webinar Series | Microsoft Community HubMicrosoft 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 hereShape the future of our communities! Take this survey to share your practitioner insights. 💡 ✏️ 🔓
This brief survey explores your experiences and preferences in professional identity and network security communities. Your feedback will help shape our team's approach to future community resources and engagement opportunities. Take the survey here! For any questions about this survey, please contact dansantos@microsoft.com. Privacy Statement: https://go.microsoft.com/fwlink/?LinkId=521839
Services I had no understanding of being used against me.
First of all, I want to apologize for the lack of technical knowledge, I was backed into a corner by a complete lockout of all my accounts and devices as a result of individuals using Azure resources and a Microsoft 365 admin account. They put the Azure services into play in early 2022 and were using an old Android to access my accounts and lock me out by changing passwords. This situation is unique because it was a homeless couple (Or so I thought) that I opened my home to in late 2021. When I had lost access to all my accounts that had been mine for over a decade I tried moving on and creating new accounts. I was creating a recovery email account for my new primary email and fell asleep before I finished. I woke to discover it had been completed, and the password was set. When unsuccessful with the .aspx recovery form I wrote it off because the account was new and I did not believe it was a danger. Maybe I finished setting it up as I drifted off and forgot. A few weeks later I was still having issues with unauthorized access to my new primary email, and when investigating noticed the email I never had access to had been assigned as admin over my Microsoft 365 apps. I tried for a month to address the issue and failed. I was fine with not being able to recover the account but if it was not mine it had no business being admin over my personal accounts. I had also discovered the people in my home running a scam on Azure using my credentials from another account, and I reported this to Microsoft. There are a lot of factors that go into this and in 2022 I had zero understanding of all of it. Only when I found myself completely locked out of everything with my personal accounts being used to request and receive an EIN from the IRS, and file a fraudulent business return, and more did I really begin troubleshooting to determine the best course of action. I was still not receiving the escalation I had requested in early 2022, and things had gone beyond too far so I created a business profile to gain an understanding of Azure services, roles and permissions, and more. Now granted when this began in September of 2024, I still had zero IT experience, admin experience or developer experience. I am still a novice at these at best in my opinion, but I have been combatting those with advanced system knowledge and developer skills the entire time. I found developer portals that had been set up using my credentials with anything associated to me. HP for my PCs, Microsoft, Google Cloud, Norton, and more. I would be directed to update drivers with HP to a site that must have been some developer's sandbox because eventually Norton flagged all HP sites as malicious. My passwords were being scraped out of my Norton Password Vault and more. This has all been quite an ordeal since 2022, and I still do not understand most of it, but I am doing my best. I already had the issue that it was my Microsoft account, and my problems crossed various platforms, and when I created my own business accounts to investigate I began having significant success seeing what was happening, but I cannot export the data in my head to a .csv about my personal accounts to share with 365 Business support or vice versa about my business accounts to personal support, so I am the only one that can see both sides. Cross platform communication on tickets is hard enough let alone crossing the business and personal threshold. I had just found myself in a position that it was my best investigative option. It has been successful on my end, however communicating what the criminals were doing has been a challenge. My lack of technical knowledge and the fact I am on a Microsoft Learn as I go system makes this quite demanding on my part. The logs and screenshots from my original investigation in 2022 exist in my photographic memory but nowhere else. And I can pick out details in logs and reports that will go unnoticed and flagged as "not me" by AI". But because of my attention to detail, I see the names associated with the activity and know that it is where the fraud began.
Fetch Email From Entra Joined Device Login User
Dear Team, We are working on retrieving email address of the user joined to Entra ID from Entra-joined Windows devices, specifically while running in a system context.The whoami /upn command successfully returns the joined user’s email address in a user context, but it does not work in a system context, particularly when using an elevated terminal via the psexec utility. We also tested the dsregcmd /status command; however, in a system context, the User Identity tab in the SSO State section only appears when there is an error in AzureAdPrt. Under normal, healthy operating conditions, this command does not provide the user identity or the full domain username. We would greatly appreciate guidance on how to retrieve the Entra ID joined user’s email address in a system context, especially from those with prior experience in this area. Thank you for your support.Global Secure Access - Deleted Appliction still applies (and cannot be recreated)
Hello everyone, we currently face an issue with Global Secure Access - Private Access - Enterprise applications. An admin has delete and tried to recreate an enterprise application. When he tried added the ip address and the port he got an error, that this rule is already within another app. The link led to an "empty" app. It was found that under "app registrations" the previously deleted applicaiton is still there and it was permanently deleted. However the problem stays. If we try a connection to the ip address and port which was specified in the deleted policy, we can see an error in the GSA Event Log on the Client: Could not authenticate using a cached token... Error: 9, Message: IncorrectConfiguration {"Description":"V2Error: invalid_resource AADSTS500011: The resource principal named <id of the deleted application> was not found in the tenant named <ourTenant>. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant. Unfortunatly, since the application is not permanently deleted, it cannot be restored. We tried to completly disable and reenable private access (in Entra!) but this did not fix the problem. For some reason the deleted policy is stuck in GSA and we have no idea how to get it out.Secure Linux Logins with Azure Entra ID: MFA, Hello, Device Compliance & SSO with Himmelblau
As organizations adopt Azure Entra ID and Intune to secure their fleets, Linux has often been left behind — especially for modern authentication requirements like MFA, Conditional Access, and device compliance. Traditional Linux frameworks (PAM, NSS) were never designed for cloud identity or Zero Trust. Himmelblau is an open-source project that bridges this gap by integrating Linux systems directly with Entra ID. With Himmelblau, you can: Join Linux machines to Azure Entra ID, creating a device object in Entra ID to establish device identity and enable Conditional Access checks tied to trusted devices. Enroll Linux systems into Microsoft Intune (currently in beta), so they participate fully in compliance policies alongside Windows. Enforce MFA at the Linux login prompt, using your existing Entra ID Conditional Access configurations. Offer secure Hello for Business PIN authentication on Linux, providing end-users with a familiar, strong second factor that’s backed by hardware-bound credentials. Integrate Linux with SSO in Firefox and Chrome, allowing seamless access to Entra-protected web apps once the user is logged in. Manage Linux users and groups via Entra ID, with robust caching for reliable offline operation. Leverage TPM-backed certificates and secure key storage, so device credentials remain protected even if the system is compromised. For many IT teams, this means finally bringing Linux endpoints under the same Zero Trust umbrella as Windows — without compromising user experience or compliance. Get started: https://himmelblau-idm.org https://himmelblau-idm.org/landing.html https://github.com/himmelblau-idm/himmelblau We’d love your feedback — especially from organizations managing hybrid fleets. What other Entra scenarios would you like to see better supported on Linux?
Recent Blogs
- 2 MIN READWe’re strengthening how Microsoft Entra Conditional Access is enforced for a narrow set of authentication flows to improve your security posture.Jan 28, 2026
- A new four‑part webinar series that helps you turn the 2026 identity strategy into actionable steps—with demos, templates, and guidance from Microsoft Entra.Jan 20, 2026
