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
Need hands-on help with Dayforce?
Talk to our team →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
Struggling with Dayforce Consulting?
Harmon & Co specializes in Dayforce consulting for mid-market companies. We fix it the first time — no endless ticket queue, no generic advice.
