Identity and directory integration: where Entra ID, LDAP and SSO begin and end

An intranet's quietest failure lives in its user list. A spreadsheet from HR is imported at launch and everyone is happy for a month; six months later three people who have left are still listed, five who joined are missing, and nobody trusts the org chart any more. That is not a content problem but a source-of-truth problem: the real headcount lives in another system.

Connecting to the corporate directory fixes it. But "directory integration" is not one thing — it is two jobs that are routinely confused.

SSO authenticates, the directory supplies

Drawing this line early makes every later decision easier.

SSO (SAML or OIDC) is an authentication job. People sign in with their company account, keep no separate intranet password, and lose access the moment that company account is closed. The question SSO answers is: "Is this person really who they claim to be?"

Directory matching is a data supply job. It reads who is employed, in which department, with what job title, and writes that onto intranet profiles. Its question is different: "Who makes up the headcount today?"

Neither replaces the other. Deploy only SSO and sign-in improves while the directory keeps ageing — because an employee who has never logged in never appears at all. Deploy only directory matching and the listing stays current while everyone still carries a separate password. Mature installations run both.

The Entra ID side

On the Microsoft Entra ID (formerly Azure AD) side, setup starts with an app registration. The intranet connects to the directory under its own identity through that registration; nobody's personal account is used.

Three values are needed: the directory (tenant) ID, the application (client) ID and a client secret. Plus one permission: to read the headcount the application is granted User.Read.All, and that grant goes through administrator consent. When the consent step is forgotten, the connection test acquires a token but the user list comes back empty — which is why a sound connection test should not stop at the token; it should actually probe the users endpoint.

Note too that the client secret expires. When it does, the integration stops silently; a calendar reminder is cheaper than debugging "why did sync stop" six months later.

The LDAP / Active Directory side

Where a classic on-premises Active Directory exists, the connection runs over LDAP. Different things are required here: the server address, an account with read rights (bind DN) and the point where the search starts (base DN).

Two details decide most deployments. The first is an encrypted connection: without LDAPS or StartTLS, corporate credentials travel the network in the clear. The second is filtering out disabled accounts: in Active Directory, records for departed employees are usually not deleted but disabled. That state sits as a bit in the userAccountControl attribute; leave it out of your filter and every leaver flows into the intranet as an "active employee" — reproducing the exact problem you set out to solve, only now automatically.

Preview, then apply

The scenario most feared in directory integrations is a misconfiguration corrupting the headcount wholesale. The answer is a simple discipline: the difference is shown first, applying it takes a separate approval.

In practice the flow is: the connection test passes, the system compares directory records with intranet profiles and produces a diff — how many matched, whose department changed, who is no longer in the directory. An administrator reads that list, then applies it.

Know the limits up front as well. In Wepilot, directory matching creates no accounts and no departments; it updates existing profiles. The reason is caution: hundreds of accounts created because of a bad filter are far harder to undo than profile fields written by the same mistake. Fully automated account lifecycle — joiner-mover-leaver via SCIM — is a separate subject and outside the scope of this integration.

Where do the secrets live?

What this integration carries is not an ordinary setting but access to your directory. The client secret and the LDAP password must never reach the browser.

The right pattern is to hold those records in a table with no read policy at all, and to return only "is a secret defined or not" to the admin screen. An administrator can fill the field in but cannot read back what they previously wrote. This differs from hiding a field in the interface: the constraint sits at the database level, and no request from a browser can get past it. We described other places the same principle applies in the data protection article.

Where to start

Our recommended order is clear: set up directory matching first, then move to SSO. The reason is practical — an accurate directory produces a benefit everyone sees on day one, whereas SSO needs coordination with the identity team and a testing window.

It is easy to measure, too: the number of unmatched records, the number of people in the directory but not in the intranet, and the time since the last successful sync. If those three are not trending towards zero, the integration has been installed but is not being operated. We cover that kind of process ownership in the operations article.