How to Set Up Dayforce SSO with Azure Active Directory

Setting up Dayforce single sign on with Azure Active Directory requires SAML 2.0 configuration across two systems — Azure AD and Dayforce HCM — with claim mapping that must be precisely correct. One wrong attribute, one misplaced identifier, and Dayforce login silently fails without a useful error message. This guide covers the complete setup, including the configuration errors we see most frequently that cause Dayforce error 500 screens or silent redirects back to the login prompt.

If you're hitting a Dayforce error 500 after configuring SSO, the issue is likely in your claim rule configuration or the SAML assertion attributes — not in the Dayforce SSO setup itself. If you're seeing token validation failures at the Dayforce login page, see our troubleshooting guide for Dayforce API webhook 401 unauthorized errors, which covers authentication failures in a different context. And if you're debugging mobile authentication issues, our guide to Dayforce Face ID login loops covers a separate failure path for the mobile app.

Prerequisites before starting the SSO configuration

Before touching the Azure portal or Dayforce SSO settings, confirm these prerequisites are in place:

• Dayforce HCM tenant with admin SSO access. You need an account with System Administrator permissions to access the SSO configuration module in Dayforce HCM.
• Azure AD tenant with admin rights. You need Azure AD Global Administrator or Application Administrator rights to register the enterprise application and configure the SAML settings.
• Known Dayforce metadata URL. Dayforce provides a metadata XML endpoint that contains the SSO configuration values you'll need to enter in Azure AD. You can find this in Dayforce HCM → System Administration → SSO Configuration → Download Metadata.
• Users provisioned in both systems. SSO doesn't provision users — it authenticates users who already exist in both Dayforce and your identity provider. Confirm that employees who need Dayforce access have accounts in both systems before starting.

If you don't have SSO configuration access in Dayforce HCM, you may need Ceridian to enable the SSO module for your tenant before Azure AD configuration can do anything useful.

Step 1: Register Dayforce as an enterprise application in Azure AD

Go to the Azure portal → Azure Active Directory → Enterprise applications → New application → Create your own application. Select Non-gallery application (Dayforce is often not in the gallery yet). Name it something recognizable like Dayforce HCM.

After creation, go to Single sign-on → SAML. This is where the SAML configuration lives. You'll see a four-step SAML configuration wizard. Most of the work is in Step 1 (Basic SAML Configuration) and Step 3 (SAML Certificates and Attributes).

In Basic SAML Configuration, enter the following:

• Identifier (Entity ID): This must match exactly what Dayforce expects. The format is typically https://[your-tenant-name].ceridiandayforce.com/Dayforce/ — not the app URL, the tenant identifier. Get this from the Dayforce metadata XML.
• Reply URL (Assertion Consumer Service URL): From the Dayforce metadata, this is the ACS URL where Azure AD sends the SAML response. Must match exactly — including trailing slashes if Dayforce's metadata shows one.
• Sign on URL: Set to your Dayforce tenant URL — e.g., https://[your-tenant-name].ceridiandayforce.com/Dayforce/

The identifier and reply URL are the most common sources of SSO configuration failures. If either is even slightly wrong — wrong subdomain, missing trailing slash, case mismatch — Dayforce will reject the SAML assertion with no meaningful error surfaced to the user.

Step 2: Configure the SAML claim mappings

Claim mapping is where the SSO configuration most frequently breaks. Azure AD sends a SAML assertion to Dayforce containing specific attributes about the user. Dayforce expects those attributes in a defined format. If the attribute names or values don't match Dayforce's expectations, authentication fails.

In the SAML configuration screen, go to Step 3: User Attributes & Claims → Edit. The required claims for Dayforce are:

• NameID (Required) — Must map to user.userprincipalname or user.mail. This is the unique identifier Dayforce uses to match the authenticated user to their Dayforce account. Choose the attribute that matches how your users are identified in Dayforce — not necessarily their email address, but the identifier that Dayforce stores as the user's SSO identifier.
• Email / Mail — Some Dayforce configurations use this as a secondary identifier. Map it to user.mail.
• First name and Last name — Map to user.givenname and user.surname. Dayforce uses these to populate the user's display name in the portal.

Additional claim mappings that matter:

• Employee ID — If Dayforce uses employee ID as part of its identity mapping, add a claim for employeeid and map it to the appropriate Azure AD attribute. Employee ID is stored in Azure AD as an extension attribute on the user object, not as a standard attribute — you may need to use the format user.extension_[app-id]_EmployeeID where [app-id] is the Azure AD application (client) ID for the Dayforce enterprise app registration.
• Department — Some Dayforce configurations route users to specific portals or permission sets based on department. If your configuration uses this, add a department claim mapping.

After configuring the claims, download the SAML signing certificate from Step 3. You'll need this in Dayforce's SSO configuration module.

Step 3: Configure the identity provider metadata in Dayforce

Go to Dayforce HCM → System Administration → SSO Configuration → Identity Provider Settings. Upload the SAML metadata XML you downloaded from Azure AD (or enter the values manually if you're configuring manually rather than using the metadata import).

The key values to confirm from the Azure metadata:

• SSO URL (SAML Assertion Consumer Service URL) — Must match exactly what you entered in Azure AD
• Entity ID / Issuer URL — Must match the Azure AD tenant's issuer URI, typically https://sts.windows.net/[your-tenant-id]/
• NameID Format — Should be urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress or unspecified, depending on your Dayforce configuration
• Certificate — Upload the signing certificate you downloaded from Azure AD. If the certificate is expired or wrong, Dayforce will reject the assertion

After saving, test the SSO configuration using Dayforce's built-in SSO test tool if one is available in your tenant version. If not, test with a real user account — ideally a test account that has the same permission level as a standard employee.

Common pitfalls that cause Dayforce SSO failures

NameID format mismatch

Azure AD defaults to a NameID format that Dayforce doesn't recognize. The Azure AD default for new enterprise applications is often emailAddress format, but some Dayforce tenants expect unspecified. If the format doesn't match, Dayforce can't match the SAML assertion to a user account and authentication fails silently — the user sees a blank screen or is redirected back to login.

Fix: In Azure AD's SAML configuration under User Attributes & Claims → Advanced options, explicitly set the NameID format to match what Dayforce expects. If you're unsure, try unspecified first.

User not provisioned in Dayforce before SSO is enabled

This catches teams every time. SSO is enabled in Dayforce, Azure AD is configured correctly, and a user attempts to log in — only to see a Dayforce error 500 or a blank screen. The SAML authentication succeeds (Azure AD knows who the user is), but Dayforce doesn't have a matching account for that user identifier.

Fix: SSO provisioning and Dayforce account provisioning are separate processes. All users who need Dayforce access must have accounts in Dayforce before SSO is enabled — SSO maps authenticated users to existing Dayforce accounts, it doesn't create them.

Certificate expiration

Azure AD SAML signing certificates expire after a defined period (typically 1 or 3 years depending on your Azure configuration). When the certificate expires, Dayforce rejects the SAML assertion. Users suddenly can't log in, and it's not obvious why until someone checks the certificate dates.

Fix: Monitor certificate expiration in Azure AD. Azure will send expiration notifications, but they're easy to miss. Set a calendar reminder 60 days before expiration. When you renew the certificate in Azure AD, update it in Dayforce's SSO configuration — the process takes 10 minutes but only if you remember to do it.

Conditional Access policies blocking the Dayforce application

Azure AD Conditional Access policies can be applied to the Dayforce enterprise app. If a policy requires device compliance, specific location, or certain user groups — and a user doesn't meet those conditions — Azure AD will either block the authentication or send a SAML response that Dayforce doesn't understand. The result is a silent failure or a Dayforce error 500.

Fix: In Azure AD, go to the Dayforce enterprise app and check Conditional Access → Policies. Verify that the policies applied to the app allow the users who need to authenticate. If you have a policy that requires managed devices and most of your workforce is Bring Your Own Device, you need an exception or a policy that accounts for unmanaged device scenarios.

Enabling and testing SSO in production

Once Azure AD and Dayforce are both configured, enable SSO for your tenant in Dayforce HCM under System Administration → SSO Configuration → Enable SSO. Before enabling for all users:

1. Test with a pilot group. Enable SSO for a small group of users (5–10) who can provide immediate feedback on login success or failure.
2. Test from multiple locations and devices. SSO behavior can differ between office and remote, managed and BYOD, desktop and mobile.
3. Keep password authentication available as a fallback. During the pilot phase, don't disable the password login option in Dayforce until you've confirmed SSO is working reliably. Once SSO is proven, disable password authentication to enforce SSO-only access.

If the pilot reveals authentication failures, check the Azure AD sign-in logs first — they contain detailed SAML assertion data that tells you exactly which claim is failing and why. Dayforce's error responses are less informative, so use Azure AD logs as your primary diagnostic source.

If you've worked through the configuration and are still hitting authentication failures, a structured diagnostic engagement typically finds the issue within the first hour — usually a claim format mismatch or an Azure Conditional Access policy that's blocking the authentication.