If your district uses LDAP / Active Directory to authenticate Edlio CMS users, this article explains how the integration behaves day-to-day and what to do when issues come up. Setting up or changing your LDAP configuration is handled by Edlio Support — see Restrict CMS Sign-In to an Organizational Unit (Google SSO or Microsoft SSO) for the request flow if you also need OU-based sign-in restriction for your SSO providers.
How LDAP integration works
Once Edlio Support has connected your district's LDAP/AD to your Edlio CMS, users in your directory who are members of the configured groups can sign in to the CMS with the same credentials they use elsewhere. Their account information (name, email, group membership) is read from your directory.
A user does not need to appear in Edlio User Management to be able to sign in. As long as they're in one of the groups configured in Settings → Security, an Edlio CMS account is created for them automatically the first time they sign in.
Sync cadence
Most districts run on a nightly sync — changes you make in Active Directory (a new staff member added to an allowed group, a user moved out of an allowed group, etc.) propagate to Edlio overnight.
Some districts choose to leave the nightly sync off and rely on manual syncs instead, requested through Edlio Support when needed. If your district is on manual-sync, plan around a 48–72 hour response time for support tickets.
If a recent change in AD hasn't appeared in Edlio yet and you're on the nightly sync, give it overnight. If it still hasn't propagated, submit a ticket through Eddy.
Where to view your LDAP configuration
You can view (but not edit) your LDAP configuration in the Settings → Security module of your CMS admin dashboard, including which user groups in Active Directory are allowed to sign in.
Changes go through Edlio Support. The fields shown here are read-only from the admin dashboard. To update your LDAP configuration — change the search base, update bind credentials, switch IPs, change which groups are allowed, or anything else — submit a ticket via Eddy.
A user can't sign in — quick checklist
Before submitting a ticket, run through these:
Is the user in your AD/LDAP directory? And are they in a group that's currently configured to allow CMS sign-in (visible in Settings → Security)? If they were just added or moved, allow time for the nightly sync — or request a manual sync.
Is the user's account active in AD? Disabled or locked AD accounts can't authenticate to Edlio.
Has the user attempted to sign in too many times with the wrong password? Edlio's system can lock the account after repeated failed attempts. If so, an admin will need to submit a support ticket via Eddy to restore access (see "Recovering a locked account" below).
Did anything just change? A directory restructure, a moved group, an IP change at your firewall — any of these can break sign-in until the configuration on Edlio's side is updated.
If the checklist doesn't surface the issue, submit a ticket via Eddy with the user's email, the time of the failed sign-in attempt, and any error message they saw.
Important: don't use the CMS password-reset flow for LDAP-managed users
For LDAP-synced accounts, never use the website's password-reset flow. Doing so locks the user's Edlio account and breaks the link to your directory. Even if the user then resets their password in your AD, that change won't restore their Edlio access — the account stays locked.
If a user has forgotten their password, they should reset it in your district's directory (AD), not in the Edlio CMS.
Recovering a locked account
If an LDAP-synced account has been locked — either by an accidental password-reset attempt on the CMS website, or by too many failed sign-in attempts — an admin will need to submit a support ticket via Eddy. Edlio Support will restore the user's access. Include in the ticket:
The affected user's email address
Your district name and website URL
A brief description of what happened (so Support knows whether it's a password-reset lock or a failed-attempt lock)
Plan around 48–72 hours for ticket response.
Common requests handled by Edlio Support
All of the following are submitted as support tickets through Eddy in your CMS admin dashboard. Plan around 48–72 hours for ticket response. Include what's listed under each:
Run a manual sync — your district name, your website URL, and what change in AD you're waiting to see reflected.
Restore access to a locked LDAP-synced account — see "Recovering a locked account" above for what to send.
Remove a user from LDAP authentication (e.g., user leaves district, switches roles, needs a local-only account) — the user's email, district name, website URL, and whether to keep the Edlio account (as a local account) or delete it entirely.
Change which AD groups can sign in to the CMS — your district name, your website URL, and the new list of group names (CN) that should be allowed.
AD restructure or LDAP server IP change — describe what's changing on your side, when, and whether sign-ins are currently affected.
Set up LDAP for a new site — district name, website URL, contact for your AD admin.
You don't need to send Edlio your LDAP/LDAPS certificate. Edlio handles cert setup server-side as part of your LDAP configuration — there's no cert upload step on your end and no cert field to populate in your CMS. Firewall and network configuration on your district's side (opening ports, allowing outbound connections from your AD server, etc.) is handled entirely by your district's IT team — Edlio doesn't manage that side of the connection.
Related
Restrict CMS Sign-In to an Organizational Unit (Google SSO or Microsoft SSO) — for OU-based sign-in restriction on Google SSO or Microsoft SSO