Recent Discussions
Registering user becomes local admin on Joined Devices
This setting works exactly as named, but the confusion is understandable because the privilege is invisible in the places people normally look. Per Microsoft's official docs (assign-local-admin): at the moment of Microsoft Entra join, two principals get added to the local administrators group — the Microsoft Entra Joined Device Local Administrator role and the user performing the join. This happens only during the join operation itself. It's not a directory role assignment, so it won't show up in role assignments, audit logs, or under "Device Administrators" — that's by design. Critically: users aren't directly listed in the local admin group; the privilege is delivered through the Primary Refresh Token (PRT) at sign-in. So: To validate on the device itself, sign in as the user and run whoami /groups — you should see the device-local Administrators SID. If you just changed the setting and want to force re-evaluation, run dsregcmd /refreshprt, then sign out and back in (lock/unlock won't trigger it — you need a fresh PRT, which can take up to ~4 hours to propagate otherwise). This setting only applies to joined devices, not registered (workplace-joined) ones — so your distinction there is correct. The "Manage Additional local administrators on all Microsoft Entra joined devices" link is a separate, tenant-wide mechanism (the same Device Administrator role) — it can't be scoped to specific devices, which is also worth knowing if you're trying to limit blast radius. If you want to stop this going forward for new joins without ripping out existing admins, set "Registering user is added as local administrator" to None, and consider a Windows Autopilot profile or Intune Local Users and Groups policy to manage membership going forward — existing devices won't be retroactively changed.
PHS staged rollout works for existing users but not new synced users
We are troubleshooting an Entra ID PHS staged rollout issue with a federated domain using a third-party WS-Fed IdP. The intended behavior is that normal federated users redirect to the IdP, while users in the PHS staged rollout group receive the Microsoft/Entra password prompt instead. Existing users in the staged rollout group continue to work correctly. They enter their UPN and receive the Microsoft password prompt. One known-good test user is not provisioned in the third-party IdP and still signs in successfully through the Entra password prompt, so the working path does not require the user to exist in the IdP. The issue is only with newly created AD-synced users. Newly synced users in the same staged rollout group are still being routed to the federated IdP at HRD instead of receiving the Entra password prompt. We’ve verified the staged rollout policy and group membership from Graph, confirmed the affected users are properly AD-synced with clean immutableID/sourceAnchor, and confirmed PHS is working. Federation metadata and HRD policies also look clean. Seamless SSO/AZUREADSSOACC was checked and remediated, but the behavior did not change. For failed attempts, there is no Entra sign-in log entry, including tenant-wide interactive and non-interactive logs. However, the federated IdP logs show a WS-Fed inbound request from login.microsoftonline.com for the affected user. That makes it look like Entra HRD is routing the user to federation before sign-in logging or token issuance. The issue started around an Entra Connect AD connector/DC-path change. We have since reverted the connector to the previous known-good configuration. After reverting, we created a clean-room test user with the correct UPN set before first sync, confirmed sync/PHS/sourceAnchor, added the user directly to the staged rollout group, and waited 60+ minutes. The clean-room user still redirected to the federated IdP instead of getting the Entra password prompt. So the current behavior is that established staged-rollout users still get the Entra password prompt, but newly created synced staged-rollout users are sent to the federated IdP by HRD. Has anyone seen staged rollout get into this state, where existing users work but new synced users remain on the federated HRD path despite valid rollout policy, group membership, synced password hash, and clean immutableID/sourceAnchor? Is there any known backend cache/state reset or escalation path for HRD/staged rollout routing?
mysignins.microsoft.com failing to save passkeys
Morning. Trying to add passkeys to accounts via mysignins.microsoft.com, it almost universally fails. The failing step is when I go to name it - it just never completes. Same result using BitWarden, Yubikeys, etc. Doing this in Edge, because in Firefox - my existing security methods don't even show up. If I check the audit logs, it will give me two entries - one stating that I failed to register security info, and another about a group management query. NO idea what this is, the only identifier within the logs is my own object ID. Possibly it's related to the group I have assigned to the Passkeys Authentication Methods policy. (which doesn't have any restrictions, but does enforce attestation) CoPilot suggested it may be that the token is expiring, or something with my Edge profile - and to try in private browsing. No change. Doing a review of our conditional access policies to see if Registering Security info is locked down - it WAS locked down to only my region (Canada). This has since been made Report-Only, just in case. Looking at the audit log entry for the failure, there's a correlation ID 9c269291-737f-4c17-b178-b1040834fb3f and performedBy {"AppId":"19db86c3-b2b9-44cc-b339-36da233a3be2","AgentType":0,"BlueprintId":null}. If I try to filter non-int sign-ins based on that Correlation ID, I get nothing. If I use AppId as the RESOURCEId, I get a FAILURE entry with the following error - yet no conditional access policies are applied. The authentication details shows this, which is weird - per=user MFA shouldn't be applied. We don't use this. But there are sign-ins at the exact same moment to the same resource, WITH MFA successful. I can register other methods wiithout issue. I tried creating an explicit CA policy GRANTING access to register sec info, with a TAP. That is the above sign-in. TAP worked.. just NOT for passkey registration. Other weird behaviours: 1. This portal times out so quick. Like... constantly. I have not configured anything to do this, as far as I know. 2. Opening the same portal in Firefox returns no MFA methods. None. No error, of course - it's just blank.
TAP requires step-up MFA when user already has a passkey registered — expected behavior?
Environment Microsoft 365 Business Premium (Entra ID P1) Cloud-only tenant Authentication methods enabled: FIDO2/Passkey only + TAP All other methods disabled (no Authenticator push, no TOTP, no SMS) CA Policy configuration CA001 — Protect Security Info Registration Target: User action — Register security information Grant: Custom authentication strength "Bootstrap and Recovery" (TAP one-time + TAP multi-use + Passkey/FIDO2 + WHfB/Platform credential) Status: On CA002 — Require Phishing-Resistant Authentication Target: All cloud apps (excluding Azure Credential Configuration Endpoint and tested also excluding Microsoft App Access Panel) Grant: Built-in Phishing-resistant MFA Status: On What was tested Scenario 1 — User with no registered methods (only with Platform credential): Admin issues TAP (multi-use, 4 hours) User navigates to aka.ms/mysecurityinfo User authenticates with TAP Result: Access granted — user can register passkey without any step-up, even in a flow authenticating directly to a resource (such as Microsoft Teams in browser) Scenario 2 — User with an existing portable passkey already registered (in MS Authenticator): Admin issues TAP (multi-use, 4 hours) User navigates to aka.ms/mysecurityinfo User authenticates with TAP Result: Entra requests a second factor — specifically the existing passkey — before allowing access to My Security Info. Seems the system enforces CA002 or a platform-level step-up requirement. The TAP is accepted as a first factor, but the platform then requires the existing passkey as a second factor before proceeding. Sign-in log analysis: The behavior does not appear in the Conditional Access tab of the sign-in logs as a CA policy failure — it appears to be enforced at the platform level, not by any configured CA policy. Questions Is it by design that when a user already has a registered MFA-capable method (passkey), the platform enforces step-up authentication before allowing access to My Security Info — even when the user authenticates with a valid TAP? If so, does the correct recovery procedure require the admin to first remove all existing authentication methods before issuing a TAP — so the user has no registered methods and the TAP is accepted without step-up? Is there any way to allow TAP to bypass this step-up requirement for recovery scenarios, without removing existing methods first? Any pointers to official documentation or confirmed behavior would be appreciated.
Entra ID Governance vs Saviynt for SAP IGA Use Cases
Hi everyone, We are currently evaluating Microsoft Entra ID Governance as a potential replacement for Saviynt for SAP-focused IGA requirements across a mixed SAP landscape, including: SAP SuccessFactors SAP Concur SAP S/4HANA Private Cloud Other SAP SaaS and enterprise applications I wanted to get insights from anyone who has implemented or worked extensively with Entra Governance in SAP-centric environments, specifically around the following areas: 1. Birthright RBAC Provisioning Can Entra Governance provision a single composite/business role (similar to Saviynt Enterprise Roles) through HR-driven JML events? For example: HR event triggers provisioning User automatically receives bundled SAP access/business roles Role assignment follows birthright/access package logic How mature/scalable is this approach in Entra compared to Saviynt? 2. SoD (Segregation of Duties) Capabilities Saviynt supports preventative SoD checks directly during request submission, including SAP-specific SoD analysis. Questions: Does Entra Governance support preventative SoD evaluation at request time? Can conflicts be surfaced before approval/provisioning? Is there native SAP SoD support or dependency on external tooling (for example SAP GRC/IAG)? Additionally, Saviynt supports granular SAP authorization object analysis down to field-level min/max values within SAP Private Cloud environments. Does Entra provide similar depth for SAP authorization analysis? 3. SAP Integrations / Connectors While Entra provides OOTB Enterprise Applications and provisioning connectors for SAP applications: What differences or limitations have you observed compared to Saviynt’s SAP connectors? How well does Entra handle SAP role imports, entitlement hierarchy, and provisioning workflows? Any known gaps for SAP Private Cloud integrations? Would appreciate any implementation experiences, architecture guidance, lessons learned, or recommendations from teams who have evaluated or deployed Entra Governance in SAP-heavy environments. Thanks in advance.
ssoSilent() not working across Next.js apps — timed_out or account picker on localhost
Hi everyone, I've been stuck on this for a few days and would really appreciate some guidance from anyone who has dealt with cross-app silent SSO using MSAL.js v5. Here's the setup. We have 3 separate Next.js applications all belonging to the same organisation, all registered under a single Azure Entra ID App Registration with the same clientId and tenantId. In production they all live under the same parent domain — app1.contoso.com, app2.contoso.com, app3.contoso.com — so localStorage is shared between them. On localhost we run them on ports 3000, 3001, and 3002. The goal is simple: if a user is already signed into App 1, opening App 2 in a new tab should silently authenticate them without any popup, redirect, or account picker. Just seamless SSO. Here is how I've set up the msalConfig: export const msalConfig: Configuration = { auth: { clientId: 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', authority: 'https://login.microsoftonline.com/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy', redirectUri: 'http://localhost:3001/', postLogoutRedirectUri: '/login', }, cache: { cacheLocation: 'localStorage', storeAuthStateInCookie: true, }, }; export const loginRequest = { scopes: ['openid', 'profile', 'email', 'User.Read'], }; Inside a component called SsoInitializer that sits inside MsalProvider, I scan localStorage for a sibling app's MSAL account on mount. I check both msal.2.account.keys (MSAL v5 format) and msal.account.keys (older format), extract the username/email as a loginHint, and then call ssoSilent(). If no loginHint is found — which is always the case on localhost since different ports are different origins — I still call ssoSilent() without a hint, expecting it to fall back to the Entra session cookie that was set when the user logged into port 3000. instance.ssoSilent({ ...loginRequest, ...(loginHint ? { loginHint } : {}), redirectUri: `${window.location.origin}/silent-callback.html`, }) The silent-callback.html in /public is just a blank HTML page with no scripts, which I believe is the correct approach based on the docs since MSAL v5 uses postMessage to communicate with the iframe. The Azure app registration has the SPA platform selected, all redirect URIs including the /silent-callback.html variants are registered for all three localhost ports, ID tokens are enabled, and User.Read has admin consent. Now here is the problem. When App 1 is logged in on localhost:3000 and I open App 2 on localhost:3001, ssoSilent() fires but one of two things happens: The first failure is a timed_out error — BrowserAuthError: timed_out from BrowserUtils.ts. The server-telemetry key in localStorage shows redirect_bridge_timeout repeated multiple times with cacheHits of 0. This started happening when I had a CDN import of MSAL inside silent-callback.html trying to call handleRedirectPromise(). The CDN download was too slow for the iframe timeout window, so I removed it. The second failure happens after switching to the blank HTML silent-callback page. The timed_out goes away but now ssoSilent() seems to fall through entirely and the Microsoft "Pick an account" full-page redirect opens — which completely defeats the purpose. I've also tried passing prompt: 'none' explicitly in the ssoSilent request. No change. One important observation from DevTools: the Entra session cookie IS present in the browser. The user is fully signed in on port 3000. Based on my understanding of the docs, ssoSilent() without a loginHint should detect this session cookie and authenticate silently. But it's either timing out or showing the account picker. I have a few specific questions I'm hoping someone can help with: First, is ssoSilent() actually supposed to work without a loginHint using only the Entra session cookie? Or does it require a hint and will always show the account picker if multiple accounts are signed in to the browser? Second, what is the correct content of silent-callback.html for MSAL v5 specifically? The blank page causes redirect_bridge_timeout, but adding MSAL scripts causes a different timeout because they load too slowly. Has the iframe handshake mechanism changed between v1/v2 and v5? Third, is there an officially recommended pattern for cross-app silent SSO when developing on localhost with different ports? In production the same-domain setup handles localStorage sharing fine, but on localhost the browser's same-origin policy makes each port completely isolated, so the sibling token scan always returns null. Fourth, does the redirectUri passed to ssoSilent() need to point to a page that actively runs MSAL code, or is a blank page genuinely sufficient for the iframe to complete its handshake in v5? Using azure/msal-browser 5.6.1, azure/msal-react 3.0.20, Next.js 14 App Router, Chrome on Windows 11, single tenant. Any help or a working example from someone who has done this in MSAL v5 would be hugely appreciated. Thanks in advance."Access package assignment manager" role with "Restricted access to Microsoft Entra admin center"
Hi, How can I allow a user with the "Access package assignment manager" role assigned only to a single catalog to manage access package assignments when "Restricted access to Microsoft Entra admin center" is set to Yes? I do not see any option to manage assignments through the MyAccess portal, so it seems this must be done through the Entra Admin Center. However, the user cannot access the Entra Admin Center because they do not have any Entra administrative roles. I do not have an Entra ID Governance license, so the option to use on-behalf-of access package assignment requests is not available. How can this scenario be solved? Thanks.'Registering user becomes local admin on Joined Devices' - WHAT
Stumbled on a tenant with 'JOIN' available for all users. Haven't worked with this much - most tenants I see only have registration. But then I noticed the horrifying 'Registering user is added as local administrator on the device during Microsoft Entra join' option was ALSO set to ALL. This is a tenant we just took on, but I've never seen that control before. This is terrifying, considering AFAIK, there is no real way for a registering user to know if they're registering or joining. Beneath it is an option to 'Manage Additional local administrators on all Microsoft Entra joined devices', which leads to the Role page for Device Administrators, which is empty. Under Description, this describes what APPEARS to be to be the same thing mentioned in the previous control - 'Users with this role become local machine administrators on all Windows 10 devices that are joined to Microsoft Entra'. But no one is assigned this. Conveniently, on my own tenant, I happened to let someone JOIN yesterday. We have this limited to 2 (now 3) people - most just register... But this user Joined, and the 'Joining user becomes local admin' option was on ALL. But I can't validate that the user ever become local admin. They don't have the role, their device shows as joined, but there's no additional roles. The audit logs don't look weird. They're not in that 'Device Administrators' group, which describes itself as 'Users with this role become local machine administrators on all Windows 10 devices that are joined to Microsoft Entra'. Thoughts? Freaking out, honestly. We have a mix of DC and Cloud users. I've inherited them all, and had the understanding that Join was essentially registration but with Org ownership. I've tried to get some input from Copilot, but he has basically waffled between 'No, this setting is just badly named' and 'no, actually it's this other setting' and 'no, you know what, it all makes sense somehow'. 1. Does that option actually set the joining user as global admin? Is that really the default setting? 2. can you validate this ANYWHERE in Entra? Or does it just disappear? 3. what is that Device Admin group? A separate group, independent of these two settings, that gives local admin? 4. Is there a graph endpoint that can be used to set this? Thanks
MFA Options for Employees without Phones
Hello everbody, we're currently trying to implement MFA in our company, but approximately 1/10 of our employees have a workphone and are not allowed to use their personal phone. Since we also recently introduced Intune, the idea was to just use Windows Hello for Business, but when trying to provision it, we realized that you need to have MFA active for an account to be able to even activate it? Which kinda defeats the purpose. So my question is, is there some way to circumvent the MFA requirement for WHfB? Or what other options do we realistically have? Thanks in Advance!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-modelAdvice required for temp / agency staff
Hi All I hope you are well. Anyway, I'm hoping someone can point me in the right direction. We have Android devices in Entra Shared Device Mode (Multi App) which any of our employees with a valid UPN can logon to. All good there. What we need is a solution for temporary or agency staff. This would be staff that could be called on at very short notice and may not stay around for long. For security and audit reasons, we'd rather not create "userless" accounts. Is there anything in Entra / Entra Shared Device Mode that can achieve this? Info greatly appreciated. SK
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
Entra CBA Preview Bug: Issuer Scoping Policy fails group claim (AADSTS500191)
I am deploying a zero-trust, cloud-native Certificate-Based Authentication (CBA) architecture for a break-glass emergency access account in Microsoft Entra ID. I am intentionally bypassing Intune/MDM to prevent circular dependencies during an outage. The PKI is generated via OpenSSL (Offline Root CA -> Client Cert). The cryptography is flawless: - The OpenSSL chain verifies perfectly (openssl verify -CAfile...). - The Root SKI and Client AKI are a perfect 1:1 hex match. - The client cert EKU includes TLS Web Client Authentication. - The client cert SAN includes othername: UPN::[break-glass-UPN]. - The Root CA and CRL are uploaded to Entra and publicly accessible via Azure Blob Storage. The Issue: When I attempt to restrict the Root CA using the "Certificate issuer scoping policy (Preview)" targeted to a specific Security Group (e.g., sg_cba), the TLS handshake drops and Entra throws: Error: AADSTS500191: The certificate authority that issued your certificate has not been set up in the tenant. Troubleshooting Performed: 1. Group Architecture: Verified via Microsoft Graph that the user is a direct, static member of sg_cba (Security Enabled, non-dynamic, not nested). 2. Micro-Group Bypass: Created a brand-new cloud-only micro-group with only the break-glass user. Waited for replication. Same 500191 error. 3. The Control Test (Success): If I completely remove the Preview scoping policy and move the targeting to the Generally Available (GA) tenant-wide trust ("All Users"), the login succeeds immediately. (I am securing this via High-Affinity binding matching the SKI to CertificateUserIDs). The Ask: Because the tenant-wide GA policy works perfectly, it mathematically proves the certificates, CRL, and bindings are correct. The failure is entirely isolated to the Preview scoping engine failing to correlate the incoming certificate to the Security Group claim fast enough. - Has anyone successfully deployed the "Certificate issuer scoping policy (Preview)" using a targeted security group without it dropping the trust? - Are there undocumented constraints on group evaluation during the CBA TLS handshake that cause this Preview feature to fail closed?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!
Entra ID Private Access - data flow
Hello, I am successfully testing Entra Private Access. From outside, I can easily access my shared permissions. However, I have one more question. What happens if I my device on the internal network? If I access the shares directly, I get about 1GB/s. What happens if the "Global Secure Access" client is active? Do all the data go through the Entra portal, or just the authentication? If all the data go through the Entra portal, there could be challenges with the internet connection (all data in and out). Thank you for your support StefanChallenges 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.Entra ID Object Drift – Are We Measuring Tenant Health Correctly?
In many enterprise environments: Secure Score is green. Compliance dashboards look healthy. Yet directory object inconsistency silently accumulates. Stale devices. Hybrid join remnants. Intune orphan records. Over time, this becomes governance debt. In large tenants this often leads to inaccurate compliance reporting and Conditional Access targeting issues. I recently wrote a breakdown of: • Entra ID drift patterns • Hybrid join inconsistencies • Intune orphan objects • Lifecycle-based cleanup architecture Curious how others approach object hygiene at scale. Full article: https://www.modernendpoint.tech/entra-id-cleanup-patterns/?utm_source=techcommunity&utm_medium=social&utm_campaign=entra_cleanup_launch&utm_content=discussion One pattern I keep seeing is duplicate device identities after re-enrollment or Autopilot reset. Curious how others handle lifecycle cleanup in large Entra ID environments.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.PIM
Hello, everyone. I need some help. We already use PIM for Just-in-Time activation of administrative functions in Entra ID, but we would like something more granular. For example, we want certain administrative actions in Microsoft 365, such as accessing sensitive data or performing critical tasks, to only be possible upon specific request and approval, even if the user has already activated the function in PIM. Is this only possible with PIM, or is there another feature in Microsoft 365 for this type of control?PIM
Hello, everyone. I need some help. We already use PIM for Just-in-Time activation of administrative functions in Entra ID, but we would like something more granular. For example, we want certain administrative actions in Microsoft 365, such as accessing sensitive data or performing critical tasks, to only be possible upon specific request and approval, even if the user has already activated the function in PIM. Is this only possible with PIM, or is there another feature in Microsoft 365 for this type of control?
Recent Blogs
- Learn how to protect data, govern access, and reduce risk across AI apps, agents, browsers, and networks with Microsoft Entra and Microsoft Purview.Jun 25, 2026
- See how Microsoft unifies identity and security signals to help teams prevent, detect, and respond to AI-accelerated attacks faster.Jun 17, 2026
