Microsoft Entra provisioning Agent Error
Hello, I have deployed the Microsoft Entra provisioning agent in my organization, with synchronization configured from AD to Microsoft Entra ID. I am encountering an issue on the server where the Cloud Sync agent is installed: when connecting to Microsoft endpoints via a Squid proxy, I receive the error shown in the screenshot. The synchronization itself works perfectly, and the configuration status in the cloud is "Healthy." I frequently see the error shown in the screenshot (error code 12015), and I also occasionally encounter error code 12011. Has anyone experienced a similar issue? Could you please advise on how to resolve it? Thanks.
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.Bulk Enrollment suddently stopped working?
We've been generating BPRT tokens for Entra ID enrollment via provisioning package (WCD) for a long time. This started out of the blue, tried from three different tenants, these two error messages: AADSTS90202: A transient error has occurred. Please try again. AADSTS240001: User is not authorized to register devices in Azure AD I know its not authorization because the same user was working the day before and because I even tired removing the enrollment restriction from the tenant altogether.
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.Entra-issued agent identities, verified offline by a party with no Microsoft credential
I am Toshikatsu Oga, representative director of The HORIZONs Co., Ltd. in Tokyo. We build NENRIN, an open record format and verifier for what AI agents authorize and execute, built so that a third party can recheck the records without trusting us and without access to the systems that produced them. On 2026-10-15 we ran this against a real Microsoft Entra ID tenant: Two agent app registrations obtained v2.0 access tokens with the client credentials flow (RS256). Each agent bound its own signing key to its token, inside the token's lifetime (record format idp-bind-v0). Agent A signed a grant authorizing one action. Agent B signed a receipt for executing exactly that action, committing to the grant by hash. A reader holding only four files (the two bindings, the tenant's JWKS pinned by SHA-256, and the grant and receipt), with no network access and no Microsoft credential, verified all four records in two independent runtimes (JavaScript and Python). It printed which Entra subject authorized what, and which one executed it. We ran the same thing with Google service-account ID tokens the same day, with the same reader. Since 2026-10-16 we also record the Entra and Google signing keys every day and anchor them to Bitcoin, so a reader can check later that a pinned JWKS is the one the issuer was serving at the time. Code and records (MIT): github.com/ogasurfproject-jpg/horizon-shield (folder workers/hs-ledger/nenrin/idp-bind-v0/real-issuers) (run node check.mjs). For the Entra run, the grant, receipt and JWKS are public. The two bindings are pinned by SHA-256 but withheld, because GitHub push protection treats Entra access tokens as secrets even after expiry. They are available to the Entra team on request. What this does not establish: that the action happened in the world (a signature proves who asserted it), or possession of the identity beyond holding a live token, because the tokens carry no cnf claim (RFC 7800). The verifier already supports a cnf claim naming the agent's key, which would upgrade the result from bearer_only to cnf_bound. Two questions for the Entra Agent ID team: Is there a supported way to obtain a proof-of-possession (cnf) token for an agent identity, so the binding can be possession-proven rather than bearer? Would an offline-verifiable record of what agent identities authorized and executed be useful to your customers? It is meant for auditors, counterparties or regulators who cannot sign in to the tenant. Toshikatsu Oga, The HORIZONs Co., Ltd. (email address removed for privacy reasons, ORCID 0009-0000-9180-903X)
Sole Global Administrator locked out — no working MFA method — need account recovery
I'm the sole Global Administrator of my Microsoft Entra ID tenant and I'm completely locked out due to losing access to my MFA device, with no other admin and no working alternate verification method. Account details: - User (UPN): email address removed for privacy reasons - Custom verified domain: apip.dk - Tenant ID: can be provided - Azure Subscription ID: can be provided What happened: My phone (with Microsoft Authenticator installed — my only registered MFA method) was destroyed. I know my password and secondary email, but: - Phone-call verification during sign-in does not connect. - I have a FIDO2 security key, but it is not currently enabled/registered as a sign-in method on this account. - There is no other Global Administrator in this tenant and no other active session I can use to self-recover. What I need: An MFA/authentication-method reset on my account so I can sign back in and register a new MFA method, or guidance on an alternative recovery path. Proof of ownership I can provide: - I own the custom domain apip.dk and can add/modify a DNS TXT (or CNAME) record to verify tenant ownership. - I can provide billing details for the subscription (card on file, recent invoice amounts, billing address) if needed for verification. Additional context: I recently updated the payment method on this subscription, so I'm concerned about a billing failure at the next payment date while this recovery is pending — I'd appreciate the account being flagged so it isn't suspended during this process. Please let me know what verification steps you need from me to proceed. Thank you, AndreasSynced 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?Feature Request: Extend Security Copilot inclusion (M365 E5) to M365 A5 Education tenants
Background At Ignite 2025, Microsoft announced that Security Copilot is included for all Microsoft 365 E5 customers, with a phased rollout starting November 18, 2025. This is a significant step forward for security operations. The gap Microsoft 365 A5 for Education is the academic equivalent of E5 — it includes the same core security stack: Microsoft Defender, Entra, Intune, and Purview. However, the Security Copilot inclusion explicitly covers only commercial E5 customers. There is no public roadmap or timeline for extending this benefit to A5 education tenants. Why this matters Education institutions face the same cybersecurity threats as commercial organizations — often with fewer dedicated security resources. The A5 license was positioned as the premium security offering for education. Excluding it from Security Copilot inclusion creates an inequity between commercial and education customers holding functionally equivalent license tiers. Request We would like Microsoft to: Confirm whether Security Copilot inclusion will be extended to M365 A5 Education tenants If yes, provide an indicative timeline If no, clarify the rationale and what alternative paths exist for education customers Are other EDU admins in the same situation? Would appreciate any upvotes or comments to help raise visibility with the product team.
From “No” to “Now”: A 7-Layer Strategy for Enterprise AI Safety
The “block” posture on Generative AI has failed. In a global enterprise, banning these tools doesn't stop usage; it simply pushes intellectual property into unmanaged channels and creates a massive visibility gap in corporate telemetry. The priority has now shifted from stopping AI to hardening the environment so that innovation can run at velocity without compromising data sovereignty. Traditional security perimeters are ineffective against the “slow bleed” of AI leakage - where data moves through prompts, clipboards, and autonomous agents rather than bulk file transfers. To secure this environment, a 7-layer defense-in-depth model is required to treat the conversation itself as the new perimeter. 1. Identity: The Only Verifiable Perimeter Identity is the primary control plane. Access to AI services must be treated with the same rigor as administrative access to core infrastructure. The strategy centers on enforcing device-bound Conditional Access, where access is strictly contingent on device health. To solve the "Account Leak" problem, the deployment of Tenant Restrictions v2 (TRv2) is essential to prevent users from signing into personal tenants using corporate-managed devices. For enhanced coverage, Universal Tenant Restrictions (UTR) via Global Secure Access (GSA) allows for consistent enforcement at the cloud edge. While TRv2 authentication-plane is GA, data-plane protection is GA for the Microsoft 365 admin center and remains in preview for other workloads such as SharePoint and Teams. 2. Eliminating the Visibility Gap (Shadow AI) You can’t secure what you can't see. Microsoft Defender for Cloud Apps (MDCA) serves to discover and govern the enterprise AI footprint, while Purview DSPM for AI (formerly AI Hub) monitors Copilot and third-party interactions. By categorizing tools using MDCA risk scores and compliance attributes, organizations can apply automated sanctioning decisions and enforce session controls for high-risk endpoints. 3. Data Hygiene: Hardening the “Work IQ” AI acts as a mirror of internal permissions. In a "flat" environment, AI acts like a search engine for your over-shared data. Hardening the foundation requires automated sensitivity labeling in Purview Information Protection. Identifying PII and proprietary code before assigning AI licenses ensures that labels travel with the data, preventing labeled content from being exfiltrated via prompts or unauthorized sharing. 4. Session Governance: Solving the “Clipboard Leak” The most common leak in 2025 is not a file upload; it’s a simple copy-paste action or a USB transfer. Deploying Conditional Access App Control (CAAC) via MDCA session policies allows sanctioned apps to function while specifically blocking cut/copy/paste. This is complemented by Endpoint DLP, which extends governance to the physical device level, preventing sensitive data from being moved to unmanaged USB storage or printers during an AI-assisted workflow. Purview Information Protection with IRM rounds this out by enforcing encryption and usage rights on the files themselves. When a user tries to print a "Do Not Print" document, Purview triggers an alert that flows into Microsoft Sentinel. This gives the SOC visibility into actual policy violations instead of them having to hunt through generic activity logs. 5. The “Agentic” Era: Agent 365 & Sharing Controls Now that we're moving from "Chat" to "Agents", Agent 365 and Entra Agent ID provide the necessary identity and control plane for autonomous entities. A quick tip: in large-scale tenants, default settings often present a governance risk. A critical first step is navigating to the Microsoft 365 admin center (Copilot > Agents) to disable the default “Anyone in organization” sharing option. Restricting agent creation and sharing to a validated security group is essential to prevent unvetted agent sprawl and ensure that only compliant agents are discoverable. 6. The Human Layer: “Safe Harbors” over Bans Security fails when it creates more friction than the risk it seeks to mitigate. Instead of an outright ban, investment in AI skilling-teaching users context minimization (redacting specifics before interacting with a model) - is the better path. Providing a sanctioned, enterprise-grade "Safe Harbor" like M365 Copilot offers a superior tool that naturally cuts down the use of Shadow AI. 7. Continuous Ops: Monitoring & Regulatory Audit Security is not a “set and forget” project, particularly with the EU AI Act on the horizon. Correlating AI interactions and DLP alerts in Microsoft Sentinel using Purview Audit (specifically the CopilotInteraction logs) data allows for real-time responses. Automated SOAR playbooks can then trigger protective actions - such as revoking an Agent ID - if an entity attempts to access sensitive HR or financial data. Final Thoughts Securing AI at scale is an architectural shift. By layering Identity, Session Governance, and Agentic Identity, AI moves from being a fragmented risk to a governed tool that actually works for the modern workplace.
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.
