SAML Single Sign-On with Microsoft Entra ID (Azure AD)

Who this guide is for: The IT administrator who manages your organization’s Microsoft Entra ID tenant (formerly Azure Active Directory). You will need Global Administrator or Application Administrator access. See also: SAML SSO Admin Guide for the EmbayLMS side.

Overview

This guide walks through registering EmbayLMS as an Enterprise Application in Microsoft Entra ID and configuring SAML 2.0 SP-initiated SSO.

Protocol: SAML 2.0, SP-initiated, HTTP-POST binding

Prerequisites

• Microsoft Entra ID tenant with Global Administrator or Application Administrator role
• EmbayLMS admin access
• EmbayLMS tenant slug (e.g., acme for acme.embaylms.com)

Step 1 — Get SP values from EmbayLMS

In EmbayLMS: Settings → User Management → SSO / Identity → View SP Metadata.

Note these values (replace {slug} with your actual tenant slug):

Step 2 — Create an Enterprise Application

1. In the Azure portal, navigate to Microsoft Entra ID → Enterprise applications → New application.
2. Click Create your own application.
3. Name it (e.g., EmbayLMS) and select Integrate any other application you don’t find in the gallery (Non-gallery).
4. Click Create.

Step 3 — Configure single sign-on

1. On the application overview page, click Single sign-on.
2. Select SAML as the sign-on method.
3. Click the edit pencil on Basic SAML Configuration:

Click Save.

Step 4 — Configure attributes and claims

Click the edit pencil on Attributes & Claims.

Entra ID sends a default set of claims. Ensure the following are present:

To set the NameID format to Email:

1. Click Unique User Identifier (Name ID).
2. Set Name identifier format to Email address.
3. Set Source attribute to user.mail.
4. Click Save.

Step 5 — Get IdP values from Entra ID

On the SAML-based Sign-on page, scroll to SAML Certificates and Set up EmbayLMS sections.

Collect:

⚠️ Use the App Federation Metadata Url, not the Certificate (Base64) download.

The Certificate (Base64) button can hand you Entra’s tenant-wide signing certificate instead of the one your application signs assertions with. They look identical — both are valid PEM files with the same file size — and using the wrong one produces a login that fails with a generic “SSO authentication failed”, because the signature check is comparing against the wrong public key.

Tell them apart by the subject line:

Certificate	Subject	Correct?
Application signing certificate	CN=Microsoft Azure Federated SSO Certificate	✅ use this one
Tenant-wide signing certificate	CN=accounts.accesscontrol.windows.net	❌ will not work

The reliable route: copy the App Federation Metadata Url from the SAML Certificates section (it ends in ?appid=<guid>), open it in a browser, and copy the value inside the <X509Certificate> element. That document is scoped to your application, so it can only contain the correct certificate.

To verify what you have, compare the SHA-1 fingerprint against the Thumbprint shown in the SAML Certificates section:

openssl x509 -in downloaded.cer -noout -subject -fingerprint -sha1

Wrap the certificate contents in -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- lines before pasting into EmbayLMS if they aren’t already present.

Step 6 — Enter IdP values in EmbayLMS

1. In EmbayLMS: Settings → User Management → SSO / Identity → Add Identity Provider.
2. Select SAML 2.0.
3. Enter the values from Step 5:

4. Under JIT Provisioning, confirm:
   • Enabled: ON (recommended)
   • Default role: learner
5. Click Save and enable the configuration.

Step 7 — Assign users or groups

1. In Entra ID, go to Enterprise applications → EmbayLMS → Users and groups.
2. Click Add user/group.
3. Search for and select the users or groups who should have access to EmbayLMS.
4. Click Assign.

Only assigned users or group members can sign in via SSO.

Step 8 — Test

1. Open a private / InPrivate browser window.
2. Navigate to https://{slug}.embaylms.com/login.
3. Click Sign in with SSO.
4. You should be redirected to Microsoft’s login page.
5. Sign in with a test user who is assigned to the application.
6. You should land on the EmbayLMS dashboard.

Troubleshooting

”AADSTS50105: The signed-in user … is not assigned to a role for the application”

The user is not assigned to the Entra ID enterprise application. Go to Entra ID → Enterprise applications → EmbayLMS → Users and groups and add the user.

”SSO authentication failed. Please try again.” (in EmbayLMS)

Most often the stored certificate is not the one Entra ID signed the assertion with. By far the most common cause is having used Entra’s tenant-wide certificate (CN=accounts.accesscontrol.windows.net) rather than the application’s certificate (CN=Microsoft Azure Federated SSO Certificate) — see the warning in Step 5. Re-take the certificate from the App Federation Metadata Url and update it in EmbayLMS.

Two other causes worth ruling out:

• Identifier mismatch — the Identifier (Entity ID) in Entra ID must match EmbayLMS’s SP entity ID exactly, including the trailing path. Compare it against https://<your-subdomain>.embaylms.com/api/auth/saml/<your-subdomain>/metadata.
• Expired certificate — Entra application certificates are valid for three years by default and are rotated independently of EmbayLMS. Check the expiry in the SAML Certificates section.

NameID is not an email address

Ensure the Name ID claim in Entra ID is set to user.mail with format Email address (Step 4). If user.mail is empty for guest users, use user.userprincipalname instead.

”Your account was not found” (in EmbayLMS)

JIT provisioning is disabled. Enable it in EmbayLMS or pre-create the user account.

Related guides

• SAML SSO Admin Guide
• Okta SAML setup
• SCIM Provisioning