SAML External Provider via Keycloak (Keycloak is IdP) - AADSTS50034 [govt cloud]

Question

Good morning,

I'm trying to get my SAML External Provider via Keycloak (Keycloak is IdP) up and running in govt cloud. I have configured Keycloak as an external provider following these instructions: https://learn.microsoft.com/en-us/entra/external-id/direct-federation

However, no matter what claims I send (or the NameID format I choose), I keep getting -

AADSTS50034: The user account [ENCRYPTED STRING] does not exist in the [tenantID] directory. To sign into this application, the account must be added to the directory.

Yes, the user is added as a guest to the tenant. I've also tried setting the username in Keycloak as the email registered in Azure as guest and the email in Keycloak set to the UPN from Azure - still no dice. What it seems like is happening is the initial handshakes are correct, but, the hand-off from guestconsent/set seems to be sending back garbage.

I have tried several SAML attributes (upn, objectidentifier, nameid, emailaddress) - none seem to really help me get across the finish line. Unchecking Signing Attributes and Signing Docs breaks the handshake, so one of them must be on (which one doesn't seem to affect).

Has anyone experience with setting up KeyCloak as IdP for Azure? Or, alternatively, can someone please confirm what SAML attributes I can set to force the user account to show up plaintext in order to complete the SSO sign-in?

Answer 1

It seems that you are encountering the AADSTS50034 error, which indicates that the user account does not exist in the Azure Active Directory (AAD) directory. Here are some key points to consider when configuring Keycloak as an IdP for Azure:

1. SAML Attributes: Ensure that the SAML attributes you are sending from Keycloak match the required attributes in Azure. Specifically, the NameID should be the same as the user's ImmutableID in Azure. The IDPEmail should be the User Principal Name (UPN) of the user in Azure.
2. Required Claims: According to the documentation, the following claims are necessary for the SAML 2.0 token issued by the IdP:
   • NameID Format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
   • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress: This should contain the user's email address.
3. Guest Accounts: Since you mentioned that the user is added as a guest, ensure that the identifier claims of the enterprise application are updated to use a consistent attribute for all guest users. You might want to check if the user.localuserprincipalname is being used instead of user.userprincipalname.
4. Debugging the Handshake: If the handshake appears correct but the user is not recognized, double-check the configurations in both Keycloak and Azure. Ensure that the certificates and endpoints are correctly set up and that any required signing is properly configured.
5. Testing with Different Claims: If you are still facing issues, try testing with different combinations of claims and ensure that the values being sent are in the expected format.

By ensuring that these configurations are correct, you should be able to resolve the issue with the SAML External Provider setup.

---

References:

• Federation with SAML/WS-Fed identity providers
• Troubleshoot SSO issues with Active Directory Federation Services (AD FS)
• Use a SAML 2.0 Identity Provider (IdP) for Single Sign On