Recent Discussions
Looking for an on-prem MFA solution for Active Directory and RDP
Hi everyone, We're reviewing options for adding MFA to our on-premises Active Directory environment. Most of our users authenticate with Active Directory, while administrators also use RDP for managing Windows servers. Because part of our infrastructure is isolated from the Internet, we'd prefer an on-premises MFA solution instead of relying on a cloud-only service. Has anyone implemented something similar recently? I'm interested in hearing: Which solution did you choose? How difficult was the deployment? Did you run into any compatibility or performance issues? Is there anything you'd do differently if you were deploying it again? Any real-world experience or recommendations would be greatly appreciated. Thanks!
Am trying to create group with dynamic user membership using attribute "Employee Type"
Am trying to create group with dynamic user membership using attribute "Employee Type", tried to get details from Extension attribute but didn't find any option, Did anyone tried this and able to do ? I found a posting where it said to create a custom attribute that would be populated by the 'employee Type' field. That just seems a little strange to me to to create an attribute to be exactly like the one that is already there.
Can the built-in "No account? Create one" link redirect to a custom sign-up page?
I'm using Microsoft Entra External ID with a built-in sign-in/sign-up user flow. On the Microsoft-hosted sign-in page, the "No account? Create one" link always redirects users to the default Entra sign-up page. I already have a custom registration page and would like this built-in link to redirect to my custom URL instead. Is there any supported way to customize the destination of this link in a built-in user flow? If not, could someone confirm whether this behavior is fixed by design? Thanks!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
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 applicationPriority 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.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.
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.
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.Request 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.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-40ab0f593c6cUsing Cloud sync to sync AD to existing Entra Accounts
I want to sync in premise AD accounts with existing Entra accounts. The email on both accounts is the same, and I added the Entra/o365 suffix to the domain and set the UPN to that suffix, making both UPN(s) the same. It did not sync. It created a NEW Entra account. I thought I covered all my bases. How can I get on premise AD and existing Entra accounts to sync? thank youGroup-Based Licensing (E3 → Business Premium): MutuallyExclusiveViolation – Months Unresolved
We operate a Microsoft 365 environment with Entra ID, Intune, and Exchange Online. For months, we have been dealing with a critical issue that remains unresolved to this day — despite an active Microsoft Support ticket. The Technical Problem: During the migration of approximately 87 user accounts from Microsoft 365 E3 to Business Premium (SPB) via group-based licensing in Entra ID, all affected accounts receive a MutuallyExclusiveViolation error. Microsoft's backend treats E3 and Business Premium as mutually exclusive, blocking the SPB assignment — despite sufficient licenses being available. A sequential approach (removing E3 first, then assigning Business Premium) is not an acceptable solution: a test run proved that this causes a complete loss of Exchange Online access. For a rollout across 87 productive user accounts, this is not viable. What is required is a seamless, atomic license swap at the backend level — exclusively via group-based licensing. The Support Problem: Two support engineers assigned — zero technical progress. Instead of a substantive solution, we received standard documentation steps that do not address the actual problem. A false resolution notice was issued — the issue had demonstrably not been resolved. Our own PowerShell tests (Get-MgUser, Get-MgSubscribedSku) and CSV exports from the Entra ID portal disproved this conclusively. Committed updates from the Engineering Team were not delivered. Instead, automatically generated follow-up emails were sent with no substantive relation to the ongoing case. An additional unexplained behavior: a test user appears in the error report of a license group they were never added to — a further backend inconsistency that has not been investigated. Current Status: The ticket has been open for months. 87 user accounts cannot be migrated to Business Premium. An escalation to the Team Manager has been initiated. No resolution is in sight. My Question to the Community: Has anyone experienced a similar issue with MutuallyExclusiveViolation in group-based licensing (E3 → Business Premium)? Is there a known workaround or an official Microsoft statement on this? Ticket Reference: #2604241410000669PHS 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?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!
"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.
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.Made a self-hosted Entra ID governance portal for app/identity sprawl (open source)
Our tenant ended up with hundreds of app registrations and enterprise apps, and the native portal makes you dig through a separate blade for every basic question. Who owns this app? Which secrets die next month? What hasn't been signed into in a year? Which ones have scary Graph permissions? There's no single view for any of it, and half the ownership info was missing anyway. Entra ID Governance, access reviews, PIM all exist, but they felt heavy (and licensed) for what I actually wanted, which was just a fast list I could scan for routine cleanup. So I built one. Lightweight portal that runs entirely in your own subscription: One grid for App Registrations, Enterprise Apps, Managed Identities and Privileged Users Risk flags per identity: expiring/expired creds, high-risk permissions, no owner, stale sign-in, no CA coverage Ownership tracking, review and owner-change workflow, CSV export Tenant health score and a consent posture dashboard Optional expiry email notifications (needs a SendGrid key) Reads Graph through a managed identity, so no app secrets for data access and nothing leaves your tenant Runs about $26-30/month (one B2 App Service plan). B1 is also supported, but it's noticeably slower. It's not a replacement for Entra ID Governance or PIM, more of a cheap everyday hygiene thing. Full disclosure, I used AI building this and writing this up. I designed the architecture and functionality, tested it and ran it against my own tenant. It's open source and deployable with Azure DevOps or an Azure CLI script. Data never leaves your own tenant. Repo (screenshots + setup): https://github.com/nicolaibaralmueller/entra-identity-governance-portal Would love feedback, especially what you'd want it to flag that it doesn't, or where the risk scoring feels off. Been building it on and off for a few months with a lot of iteration. Hopefully this could be useful for others as well.
Recent Blogs
- AI agents are multiplying fast. See what 150 identity pros said about sprawl, shadow AI, and governance at Identiverse 2026.Jul 15, 2026
- Use Microsoft Entra Agent ID to assign accountable identities, control agent access, and automate sponsor lifecycle management at scale.Jul 07, 2026
