Is Wiring AD Into Your ERP and CRM Worth It?

A new starter arrives on Monday. By Wednesday they have a domain login, a mailbox, an ERP account, a CRM account, a login to the warehouse system, one for the payroll portal, one for the supplier site and a shared password for the machine in dispatch. Eight of those were created by hand, by four different people, with no record that any of it happened. Two years later the same person resigns, and exactly one of those eight gets switched off reliably: the domain login.

Single sign-on is usually sold as convenience. Its real value is the opposite end of the story: when identity lives in one place, revoking it once removes access everywhere, and the leaver stops being a security problem you discover by accident.

So is it worth connecting Active Directory — or Entra ID, its cloud successor — to your ERP, your CRM and the rest? Often yes, sometimes no, and the difference is usually not technical. Here is what the work actually involves, what it costs, and how to tell which side of the line you are on.

"Integrating AD" is three different projects

People say single sign-on and mean anything from "one password" to "a fully governed identity lifecycle". Separating the three makes the conversation far easier, because they have different costs and very different payoffs.

• Authentication — who are you? The system stops holding its own password and asks your identity provider instead. This is what most people mean by SSO. It gets you one password, and it gets you multi-factor authentication on every connected system at once, without configuring MFA in each of them.
• Authorisation — what may you do? Group membership in AD drives the role inside the application. Move someone from the "Sales" group to "Dispatch" and their permissions in the ERP change with them. This is where most of the ongoing administrative saving lives.
• Provisioning — do you exist here at all? Accounts are created, updated and deactivated in the target system automatically, driven by AD. This is the piece that actually closes the leaver gap, and it is the piece most often left out.

Single sign-on without provisioning solves the password problem and leaves the leaver problem exactly where it was. The account still exists in the ERP; it has simply stopped being reachable through the front door.

That last point deserves emphasis, because it is where most disappointment comes from. If a system supports SSO but keeps its own local accounts alongside, disabling someone in AD blocks the SSO route while the local login they set up during the pilot still works. Turning off local authentication entirely, or provisioning properly, is what makes the promise true.

The mechanics, briefly

You will meet four acronyms and they map cleanly onto the three jobs above.

• LDAP. The old way: the application asks your domain controller to check a username and password directly. Widely supported by on-premise ERP systems, simple to set up, and weak — it usually means the application still sees the password, and it does not carry multi-factor authentication.
• SAML 2.0. The browser-redirect standard that most business applications support. The application never sees the password; it receives a signed assertion saying who the user is and which groups they belong to. This is the workhorse.
• OIDC / OAuth 2.0. The modern equivalent, built for APIs and mobile apps as well as browsers. If a vendor offers both, prefer this one.
• SCIM. The provisioning standard. Your identity provider pushes creates, updates and deactivations into the application. If a vendor supports SAML but not SCIM, you get sign-on but you keep doing joiner-mover-leaver by hand.

One practical note on the estate itself: if you run on-premise Active Directory and Microsoft 365, you almost certainly already have the sync between them. That means your cloud identity provider is live, most of your staff already sign in through it daily, and the incremental work is per-application rather than foundational. That changes the cost picture substantially, and it is worth checking before anyone quotes you for a new identity platform.

What you actually get

1. One switch on the last day. Disable the account, and every connected system closes with it. This is the whole argument, and it is a strong one — it converts offboarding from an archaeology project into a single action.
2. MFA everywhere, configured once. Conditional access rules — block sign-in from outside the country, require a second factor off the office network — apply to every integrated application without touching any of them.
3. Onboarding in minutes. Put the new starter in the right groups and their access appears. No ticket queue, no four people, no guessing which permissions the last person in that role had.
4. An audit trail worth having. One sign-in log across the estate, so "who logged into the ERP at 11pm on Saturday" is a query rather than an investigation. That complements the change history inside the application itself.
5. Fewer passwords, which means fewer bad ones. Eight systems means eight passwords, which in practice means one password used eight times. Removing seven of them does more for your security than any policy about special characters ever has.
6. Licence clarity. Once accounts are provisioned from one source, the count of who has a licence in each system stops being fiction.

What it costs, including the parts nobody quotes

• The SSO tax. A large number of software vendors put SAML behind their enterprise tier, so enabling it means moving every user up a price band. This is frequently the single biggest line in the business case, and it is invisible until someone asks the vendor directly. Ask early.
• Per-application effort. Each integration is its own small project: metadata exchange, attribute mapping, a test user, a pilot group, a cutover. Budget days per application, not hours, and more for anything on-premise or elderly.
• Group design, which is the real work. Mapping groups to roles forces you to write down who is allowed to do what — a question most businesses have never answered explicitly. It is valuable and it is slow, and it is not an IT decision.
• A single point of failure, deliberately created. If identity is down, everything is down. That is an acceptable trade, but it has to be a conscious one, with the identity provider treated as critical infrastructure.
• Break-glass accounts. Two local administrator accounts per critical system, excluded from SSO, with long unique passwords in a password manager, sealed and tested twice a year. Without these, an identity outage locks you out of your own business.
• Ongoing hygiene. Groups rot. Without a quarterly review, you end up with "Sales-Old", "Sales-New" and "Sales-Temp-2024", all still granting access.

When it is worth it — and when it is not

The honest threshold is about the product of three numbers: how many people, how many systems, and how often people join or leave. Twelve staff, three systems and almost no turnover does not justify an identity project; a shared register and a disciplined leaver checklist will serve you better and cost nothing. Eighty staff across six systems with seasonal hiring is a different business entirely, and doing it by hand there is not thrift, it is a standing risk.

Three other factors move the line decisively:

• Regulated or personal data. If the systems hold personal information, being able to demonstrate who has access and how it is removed is a POPIA accountability question, not just good practice.
• Distributed or field staff. People who rarely visit the office, on their own devices, are exactly the case conditional access was built for.
• Turnover. High-churn environments — retail, hospitality, seasonal operations — get the payback fastest, because the leaver problem arrives weekly rather than yearly.

A sensible order to do it in

1. Fix the directory first. If AD itself is a mess — dormant accounts, groups nobody understands, service accounts with domain admin — integrating more systems just spreads the mess further. Start with a user audit.
2. Email and collaboration. Usually already done, and it proves the identity provider works.
3. The systems holding money or personal data. ERP, payroll, CRM. Highest risk, highest payoff.
4. Everything else that supports it. In whatever order is cheapest.
5. The ones that cannot. Some systems will never do SSO. Those get unique credentials in the password manager, a named owner, and a line in the leaver checklist. Knowing which systems are in this category is itself a useful output.

The traps that turn a good project into a bad one

Mirroring the org chart with groups. Groups should describe what people do, not where they sit. An org-chart hierarchy has to be rebuilt every restructure; a set of function-based groups survives them.

Nested groups nobody can unwind. Two levels is manageable. Five levels means nobody can answer "why does this person have access to that", which defeats the point of doing it at all.

Service accounts living outside the directory. The integration user your interfaces run as is still an account with a password, usually a permanent one. Bring it into the same inventory even if it cannot use SSO, and give it a named human owner.

Contractors and shared logins. A shared "warehouse" login defeats every benefit here, because you can no longer attribute an action to a person. If the constraint is licence cost, say so out loud and decide — do not let it happen by default.

Disabled versus deleted. Deleting an account on the last day can orphan its records and break history. Disable, transfer ownership, then delete on a schedule.

The short answer

For a business of any real size running more than a handful of systems, connecting them to your directory is worth it — but for the access-control benefit far more than the convenience one, and only if you go past sign-on to provisioning. SSO alone gives you a nicer login screen and a business case that struggles to pay for the licence uplift. Provisioning gives you a business where access reliably ends when employment does, and that is a thing you can show an auditor, a client and your own board.