Forum Discussion
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?
2 Replies
alejlw I did some repro testing on this and wanted to sanity‑check a few things with you.
In my tenant, Certificate issuer scoping (Preview) works as expected when group evaluation succeeds:
- User not in target group → blocked with AADSTS500189 (not authorized by CA scoping rules)
- User added to target group → sign‑in succeeds immediately
- Repeated add/remove cycles and even changing target groups behaved consistently
I was only able to briefly surface AADSTS500191 during a narrow window after removing/re‑adding a user when the CA was registered in the legacy Certificate authorities (classic) store, and deleting/recreating the scoping policy cleared it. After further testing, that state stopped reproducing reliably.
A couple of questions that might help narrow this down on your side:
- Do you ever see AADSTS500189, or does it jump straight to AADSTS500191 every time?
- Which CA store is your issuing CA registered in — Public key infrastructure (PKI-based) or Certificate authorities (classic)?
- Is CBA method availability scoped the same way as issuer scoping, or is one tenant‑wide and the other group‑scoped?
Since GA tenant‑wide trust works for you, I agree the PKI and bindings look solid — this feels like an edge case in how the Preview engine is resolving the issuer during early evaluation. Curious what you’re seeing on those points.
Hi — great job isolating this. Your control test (GA tenant-wide trust works immediately, Preview issuer scoping group targeting fails with AADSTS500191) strongly suggests the certificates/CRL/bindings are fine and the issue is isolated to the Preview group-targeting path in “Certificate issuer scoping policy (Preview)”.
I can’t claim I’ve reproduced this exact Preview behavior yet, but the symptoms line up with a fail-closed evaluation issue early in the CBA flow.
A GA alternative that preserves your objective (tight scope without depending on Preview group scoping):
- Keep the CA trust tenant-wide (GA), but enforce “only this cert can authenticate this user” using high-affinity/strong binding (SKI / public key hash → CertificateUserIDs), which prevents certificate reuse across accounts.
- Further scope where that cert can be used via Conditional Access Authentication Strength using advanced CBA options (restrict by certificate Issuer and/or Policy OID) per app/resource.
This keeps the architecture cloud-native and outage-safe (no Intune/MDM dependency) while avoiding Preview issuer scoping group evaluation.
References (for the GA pattern and controls):
- CBA overview: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication
- How to configure CBA: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-certificate-based-authentication
- CBA technical deep dive: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive
- CBA enhancements (mentions affinity/high-affinity bindings + advanced CA options): Enhancements to Microsoft Entra certificate-based authentication | Microsoft Community Hub
- Advanced CBA options in Conditional Access / Authentication Strength (Issuer / Policy OID): Introducing more granular certificate-based authentication configuration in Conditional Access | Microsoft Community Hub
- Community deep-dive on affinity binding (helpful practical notes): Achieve higher security with certificate bindings - How it works! | Microsoft Community Hub
If you’re able to share sanitized sign-in log details around the failure (Correlation ID + timestamp + client/platform), that can help confirm whether the Preview scoping engine is failing before user/group resolution completes. Of course, perhaps opening a Microsoft support case for further assistance? I'd be keen to hear their thoughts 😉
