Free, offline tool: see each user's real passkey policy in Entra ID and who SMS retirement blocks
Entra combines passkey profiles as a union (any profile that allows a passkey type wins), while Conditional Access works as an intersection. So a Global Admin in a strict "security keys only" profile who is also in an All Users profile can still register a synced iCloud or Google passkey, and the portal never shows you that per user. I built EffectivePasskey to answer three questions for every user and admin: 1. What passkey can this person actually register? 2. What can this admin actually sign in with after Conditional Access? 3. Who gets blocked when SMS and voice MFA retire (1 Feb 2027, and 1 Jul 2027 for Global Admins)? It runs entirely on your machine from read-only JSON exports. It never signs in to your tenant and never changes anything. No telemetry. MIT licensed and completely free. Try it with the included demo tenants: pip install effective-passkey GitHub: https://github.com/xsignon-secure/EffectivePasskey Feedback and issues are very welcome, especially from anyone mid-rollout.
Passkey/FIDO2 for users in mainland China – recommended approach?
Hi, We are currently evaluating the adoption of Passkey/FIDO2 in Microsoft Entra ID as part of our strategy to move users away from traditional authentication methods such as SMS and voice and towards phishing-resistant authentication. Our Microsoft Entra ID tenant is a global tenant (not Azure China operated by 21Vianet), but we have a group of users who are physically located in mainland China. For users in other regions, we are evaluating Passkeys in Microsoft Authenticator and FIDO2 security keys. However, before defining the approach for our users in China, we would like to better understand the supported and recommended architecture for this particular scenario. We have reviewed the Microsoft documentation and understand that: Passkeys are not available for Microsoft Azure operated by 21Vianet. On iOS, Microsoft Authenticator Passkeys can be used to sign in to global organizations while the user is in China. On Android, Passkey authentication has dependencies such as Google Play Services, which raises questions for devices operating in mainland China. Our main questions are: For users physically located in mainland China but authenticating against a global Microsoft Entra ID tenant, what is Microsoft's recommended approach for deploying phishing-resistant authentication with Passkey/FIDO2? Is Microsoft Authenticator Passkey on iOS considered a fully supported option for users permanently located in mainland China, rather than only users temporarily traveling there? For Android users in mainland China, what is the recommended approach considering the dependency on Google Play Services? Is Passkey in Microsoft Authenticator a realistic supported option in this scenario? Would physical FIDO2 security keys be the preferred or more consistent alternative for users in China when mobile Passkeys cannot be reliably used? Are there any other Microsoft-supported Passkey providers or authentication approaches that should be considered specifically for mainland China? From an enrollment perspective, what would be the recommended bootstrap process for these users? For example, would Temporary Access Pass (TAP) be the recommended method to allow users to register their Passkey/FIDO2 credential before SMS/Voice is removed? Are there any additional regional, connectivity, mobile OS, or application compatibility considerations that should be taken into account before enforcing a phishing-resistant Authentication Strength through Conditional Access? Our objective is not simply to enable Passkey in the tenant, but to define a supported and sustainable authentication model for users located in mainland China before starting a broader rollout. Any experience, Microsoft guidance, or recommended architecture for this type of scenario would be greatly appreciated. Thanks in advance.Synced iCloud Keychain passkey registration succeeds despite Device-Bound-only passkey profile
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } We have Microsoft Entra passkeys enabled only for a pilot group. The assigned Default Passkey Profile is configured as: Passkey Type = Device-bound Key Restrictions enabled Microsoft Authenticator iOS and Android AAGUIDs only Despite this, a pilot account successfully registered a synced iCloud Keychain passkey. The Security Info page explicitly shows: "Passkey (Synced) - iCloud Keychain" The tenant also displays a warning banner stating: "All users enabled for SMS or voice authentication are in scope for passkey auto-enablement and will be assigned to a system-managed passkey profile that allows all passkey types without restrictions." Can Microsoft explain how tenant-managed passkey profiles interact with the system-managed passkey auto-enablement profile? Is the system-managed profile overriding or supplementing tenant-defined passkey restrictions?
Entra ID 53003: How to identify primary authentication when Authentication Details are empty?
We are investigating repeated interactive Microsoft Entra ID sign-ins with the following pattern: - ErrorCode: 53003 (BlockedByConditionalAccess) - isInteractive: true - AppDisplayName: OfficeHome - Authentication requirement: Multifactor authentication Conditional Access correctly blocks these requests because they originate outside our trusted locations. We have already confirmed through controlled testing that the authentication flow can reach 53003 after the correct credentials are provided. Our current problem is different: We need to determine what mechanism satisfied the primary/first authentication factor for the observed 53003 events. For these events, Authentication Details are empty: - Authentication method: empty - Authentication method detail: empty - Result detail: empty Therefore, we cannot determine whether primary authentication was performed using a password, an existing token/session claim, PHS, PTA, federation, Seamless SSO, or another mechanism. Our questions are: 1. Is there any tenant-visible telemetry that can identify the primary authentication mechanism when AuthenticationDetails is empty? 2. Can fields such as AuthenticationProcessingDetails, AuthenticationProtocol, IncomingTokenType, OriginalTransferMethod, or AuthenticationMethodsUsed reliably distinguish between password validation and reuse of an existing authentication/token? 3. If additional authentication infrastructure is used: - can PTA Authentication Agent logs be correlated using RequestId or CorrelationId? - should Seamless SSO generate a corresponding Kerberos 4769 event for AZUREADSSOACC$? - should federated authentication be traceable in AD FS logs? 4. For Password Hash Synchronization, is there any tenant-visible telemetry confirming that Entra ID actually validated the password for a specific sign-in request? 5. If this information is not exposed to the tenant, can Microsoft Support retrieve backend authentication telemetry for a specific Sign-in ID / RequestId / CorrelationId and determine how primary authentication was satisfied? Our goal is not to determine why Conditional Access generated 53003 — that part is already understood. We specifically need to identify what satisfied primary authentication before the Conditional Access evaluation.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!
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!
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!MFA catch-22 during onboarding due to registration policy
Hi, We are experiencing a catch-22 scenario during user onboarding related to MFA. New users are required to install the Microsoft Authenticator app via our Company Portal. However, they are prompted to complete MFA registration before they can access or download anything from the Company Portal. Since they do not yet have the Authenticator app installed, they are effectively blocked from completing the MFA setup. From our investigation, it appears that the Multi-Factor Authentication registration policy is enforcing MFA registration for new users. In our scenario, this creates a circular dependency. We have attempted to exclude our office network from MFA using Conditional Access, but this does not resolve the issue because the MFA registration policy is triggered before Conditional Access policies are evaluated. Our questions: Is there a recommended way to handle MFA onboarding in this type of scenario? Can Conditional Access policies be used instead of the MFA registration policy for initial MFA enrollment?
NPS Extension for azure MFA and multiple tenants?
Hi, is it possible to setup one NPS server with the Extension for Azure MFA to authenticate against multiple tenants? The onprem AD has azure ad connector for each domain and the users are in sync with there tenants. Its a RDS setup with one RD Gateway and one NPS server and multiple RD servers. I need email address removed for privacy reasons and email address removed for privacy reasons etc. to authenticate with MFA, but i can only get the users on the tenant thats linked in the NPS Extension for Azure MFA to work. I dont think its possible to setup more than one tenant in one NPS server (Extension for azure MFA). I get this error in the NPS log NPS Extension for Azure MFA: CID:xxxxxxxxxxxxxxx : Access Rejected for user email address removed for privacy reasons with Azure MFA response: AccessDenied and message: Caller tenant:'xxxxxxxxxxxxxxxxxxxxxxx' does not have access permissions to do authentication for the user in tenant:'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',,,xxxxxxxxxxxxxxxxxxxxxx The ID in the Caller tenant and the user tenant in the error is correct, so something have to work? I cat find a way to allow the Caller tenant to access users in the user tenant.
Disabling PIN-based login on Entra-joined PCs
Hi guys. Yesterday I took two machines off the domain and Entra joined them. The goal was 1) remove their access to domain resources 2) have tenant users login to the machine and get enriched tokens every time. this works as desired. The problem is every user gets prompted to set a pin. these are both shared secondary/tertiary PC's - there is no point to having a 6 digit PIN on them. I thought the new Authentication Methods tools had controls for this, but apparently not. A script was run to change certain related Reg Keys (by my onsite tech) but this had no change on reboot. textreg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork" /v Enabled /t REG_DWORD /d 0 /freg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork" /v DisablePostLogonProvisioning /t REG_DWORD /d 1 /f HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork Enabled key was set to 0, and DisablePostLogonProvisioning was set to 1. These are from various help threads I found here and other resources. Unfortunately, they do not work. Not sure what to do here. I've read there are InTune controls for this - but I don't really have the time to work out WindowsPC ennrollment profiles for 2 machines. The site has InTune, but only for iOS mobile management. Thoughts?
