Forum Widgets
Latest Discussions
Hybrid Join Lifecycle Model
Microsoft Entra hybrid join is still a common reality in enterprise environments. For many organizations, it remains necessary because legacy applications still rely on Active Directory machine authentication, Group Policy is still in use, and on-premises operational dependencies have not fully been retired. At the same time, the long-term direction for endpoint identity is increasingly cloud-native. That creates an important architectural question: Should hybrid join be treated as a permanent device state, or as a lifecycle stage in a broader modernization journey? In practice, hybrid join is often discussed as a binary condition: the device is either hybrid joined or it is not. But from an operational perspective, that view is too limited. In real enterprise environments, hybrid join behaves much more like a lifecycle. A device moves through provisioning, registration, trust establishment, management attachment, steady-state operation, recovery, retirement, and eventually transition. That distinction matters because most hybrid join issues do not fail loudly. They usually appear as stale objects, pending registrations, broken trust, inconsistent management ownership, and environments that remain temporarily hybrid far longer than intended. Why a lifecycle model is useful Treating hybrid join as a lifecycle helps explain why so many organizations struggle with it even when the initial implementation appears technically correct. The challenge is usually not the first successful join. The challenge is everything that happens around it: Provisioning quality Trust validation Management ownership Drift detection Stale object cleanup Exit criteria for transition to Entra join Without that lifecycle view, hybrid join often becomes a static design decision with no clear operational model behind it. The eight phases 1. Provisioning The lifecycle starts when the device is built, imaged, or provisioned. This stage is more important than it looks. If the device is provisioned from a contaminated image, or if cloning and snapshot practices are not handled carefully, later identity issues are often inherited rather than newly created. Provisioning should be treated as an identity-controlled event, not just an OS deployment task. 2. Registration The device becomes known to Microsoft Entra. This is where many environments confuse visibility with readiness. A device object may exist in the cloud, but that does not automatically mean the hybrid identity state is healthy or operationally usable. 3. Trust Establishment This is the point where hybrid join becomes real. A device should not be considered fully onboarded until both sides of trust are present and healthy. In operational terms, this means the device is not only registered, but also capable of supporting the expected sign-in and identity flows. 4. Management Attachment Once trust exists, governance becomes the next question. Many organizations still balance Group Policy, Configuration Manager, Intune, and legacy application dependencies at the same time. That is exactly why hybrid join often persists. But if management ownership is not clearly defined, organizations end up with overlapping policy planes, inconsistent control, and unclear accountability. 5. Operational Steady State Hybrid join does not stop at successful registration. The device must remain healthy over time, and that means monitoring trust health, registration state, token health, line-of-sight to required infrastructure, and management consistency. A device that was healthy once is not necessarily healthy now. 6. Recovery Every real environment eventually encounters drift. Pending states, broken trust, orphaned records, reimaged devices, and inconsistent registration scenarios should not be treated as unusual edge cases. They should be expected and handled with formal recovery playbooks. Recovery is not an exception to the lifecycle. It is part of the lifecycle. 7. Retirement Retirement is one of the weakest areas in many hybrid environments. Devices are replaced or decommissioned, but their identity records often remain behind. That leads to stale objects, inventory noise, and administrative confusion. A proper lifecycle model should include a controlled retirement sequence rather than ad hoc cleanup. 8. Transition This is the most important strategic phase. The key question is no longer whether a device can remain hybrid joined, but whether there is still a justified reason to keep it there. Hybrid join may still be necessary in many environments today, but in many cases it should be treated as transitional architecture rather than the target end state. Practical takeaway Looking at hybrid join as a lifecycle creates a more useful framework for architecture decisions, operational ownership, troubleshooting, directory hygiene, governance, and transition planning toward Microsoft Entra join. That is the real value of this model. It does not replace technical implementation guidance, but it helps organizations think more clearly about why hybrid join exists, how it should be operated, and when it should eventually be retired. Final thought Hybrid join is still relevant in many enterprise environments, but it should not automatically be treated as a default destination. In many cases, it works best when it is managed as a lifecycle-driven operating model with defined phases, controls, and exit criteria. That makes it easier to stabilize operations today, while also creating a clearer path toward a more cloud-native endpoint identity model tomorrow. Full article: https://www.modernendpoint.tech/hybrid-join-lifecycle-model
Understand Why a Service Principal Was Created in Your Entra Tenant
Are you a tenant admin or member of a security team in your organization and find yourself asking “Why was this service principal created in our tenant?” Historically, answering this required correlating audit logs with Microsoft Graph queries or going through long investigations. Microsoft Entra now introduces enhanced audit log properties that make it significantly easier to understand the origin and intent behind newly created service principals directly from tenant audit logs. These new improvements surface additional insights within the Add service principal activity under the ApplicationManagement category—helping administrators determine whether a service principal was provisioned automatically by Microsoft services, triggered by a purchased subscription, or explicitly created by user or application activity. What’s in it for me as an Admins or member of the Security Team When a service principal is created, new metadata is now captured within Microsoft Entra audit logs that enables faster root‑cause analysis. These properties help distinguish between Microsoft‑driven provisioning processes and tenant‑initiated actions, allowing teams to quickly assess whether an event is expected platform behavior or something requiring deeper investigation. For example, administrators can now: Identify provisioning initiated by Microsoft services versus internal users or automation. Determine which tenant subscription or service plan enabled just‑in‑time provisioning. Recognize provisioning linked to Azure resource onboarding or managed identities. Investigate service principal creation without relying on additional Graph lookups. By leveraging these enriched audit logs, security teams can streamline investigations into newly created enterprise applications and reduce manual dependency on downstream data sources. This ultimately improves visibility into application onboarding events and supports faster decision‑making when assessing potential risk or unexpected provisioning activity within the tenant. Learn more here- Understand why a service principal was created in your tenant - Microsoft Entra ID | Microsoft Learn
Introducing the Entra Helpdesk Portal: A Zero-Trust, Dockerized ITSM Interface for Tier 1 Support
Hello everyone, If you manage identity in Microsoft Entra ID at an enterprise scale, you know the struggle: delegating day-to-day operational tasks (like password resets, session revocations, and MFA management) to Tier 1 and Tier 2 support staff is inherently risky. The native Azure/Entra portal is incredibly powerful, but it’s complex and lacks mandatory ITSM enforcement. Giving a helpdesk technician the "Helpdesk Administrator" role grants them access to a portal where a single misclick can cause a major headache. To solve this, I’ve developed the Entra Helpdesk Portal (Community Edition)—an open-source, containerized application designed to act as an isolated "airlock" between your support team and your Entra ID tenant. Why This Adds Value to Your Tenant Instead of having technicians log into the Azure portal, they log into this clean, Material Design web interface. It leverages a backend Service Principal (using MSAL and the Graph API) to execute commands on their behalf. Strict Zero Trust: Logging in via Microsoft SSO isn’t enough. The app intercepts the token and checks the user’s UPN against a hardcoded ALLOWED_ADMINS whitelist in your Docker environment file. Mandatory ITSM Ticketing: You cannot enforce ticketing in the native Azure Portal. In this app, every write action prompts a modal requiring a valid ticket number (e.g., INC-123456). Local Audit Logging: All actions, along with the actor, timestamp, and ticket number, are written to an immutable local SQLite database (audit.db) inside the container volume. Performance: Heavy Graph API reads are cached in-memory with a Time-To-Live (TTL) and smart invalidation. Searching for users or loading Enterprise Apps takes milliseconds. What Can It Do? Identity Lifecycle: Create users, auto-generate secure 16-character passwords, revoke sign-in sessions, reset passwords, and delete specific MFA methods to force re-registration. Diagnostics: View a user's last 5 sign-in logs, translating Microsoft error codes into plain English. Group Management: Add/remove members to Security and M365 groups. App/SPN Management: Lazy-load raw requiredResourceAccess Graph API payloads to audit app permissions, and instantly rotate client secrets. Universal Restore: Paste the Object ID of any soft-deleted item into the Recycle Bin tab to instantly resurrect it. How Easy Is It to Setup? I wanted this to be universally deployable, so I compiled it as a multi-architecture Docker image (linux/amd64 and linux/arm64). It will run on a massive Windows Server or a simple Raspberry Pi. Setup takes less than 5 minutes: Create an App Registration in Entra ID and grant it the necessary Graph API Application Permissions (e.g., User.ReadWrite.All, AuditLog.Read.All). Create a docker-compose.yml file. Define your feature toggles. You can literally turn off features (like User Deletion) by setting an environment variable to false. version: '3.8' services: helpdesk-portal: image: jahmed22/entra-helpdesk:latest container_name: entra_helpdesk restart: unless-stopped ports: - "8000:8000" environment: # CORE IDENTITY - TENANT_ID=your_tenant_id_here - CLIENT_ID=your_client_id_here - CLIENT_SECRET=your_client_secret_here - BASE_URL=https://entradesk.jahmed.cloud - ALLOWED_ADMINS=email address removed for privacy reasons # CUSTOMIZATION & FEATURE FLAGS - APP_NAME=Entra Help Desk - ENABLE_PASSWORD_RESET=true - ENABLE_MFA_MANAGEMENT=true - ENABLE_USER_DELETION=false - ENABLE_GROUP_MANAGEMENT=true - ENABLE_APP_MANAGEMENT=true volumes: - entra_helpdesk_data:/app/static/uploads - entra_helpdesk_db:/app volumes: entra_helpdesk_data: entra_helpdesk_db: 4.Run docker compose up -d and you are done! I built this to give back to the community and help secure our Tier 1 operations. If you are interested in testing it out in your dev tenants or want to see the full architecture breakdown, you can read the complete documentation on my website here I’d love to hear your thoughts, feedback, or any feature requests you might have!
Challenges with custom data provided resource reviews
I was thrilled to see the ability to review disconnected applications in Entra, and even more thrilled to see that the permission and its description are available to the reviewer, which addresses a significant gap present in group-based reviews. However, the current decision-tracking approach does not adequately replicate the closed-loop remediation model typically found in traditional IGA access reviews for integrated applications. Requiring reviewers to upload confirmation that revocations have been completed is problematic. This approach does not mitigate the core risk: access may remain in place due to fulfillment errors or be incorrectly retained, and the reviewer may unknowingly validate an inaccurate state. This can lead to a compliance incident or audit finding. A more effective solution would allow reviewers to upload a current export of access data, enabling the review system to reconcile intended revocations against the actual state. Any discrepancies could then be flagged for remediation where revocations were missed or have failed, or for validation where access was revoked and immediately reinstated (e.g., due to reviewer misjudgement), ideally supported by corresponding ticketing or justification. There are currently a lot of gaps in Entra ID access reviews, and while this new feature arguably resolved the worst one, I think it's headed down the wrong path. I am curious about other people's thoughts.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 SinghOrphaned 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-40ab0f593c6cAADSTS50105 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.
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.
