Your MDM users are not in Active Directory any more. Who turns them off?

Every MDS migration plan has a row in it that reads something like “AD users and groups → roles and users”. It looks like the smallest row in the table. One line, one afternoon, recreate the membership and move on.

It is the only row in that table that is not a mapping. It is a process you are taking over, and unlike the others it never finishes. How the three MDS permission layers translate covers the mapping work. This covers what happens in month seven.

Only one of the three jobs was signing in

MDS managed no accounts. It asked the directory who you were and which groups you were in, and the directory answered. That arrangement quietly covered three separate things, and teams evaluating a replacement usually price only the first one.

Authentication is genuinely the easy half. People type an email and a password instead of getting a silent Windows sign-in. Somebody grumbles for a fortnight. Group membership is the middle case: the AD group named MDM-Procurement-Editors becomes a role, and rewriting it is useful work, because half those groups accumulated members through tickets nobody can find.

The third job was never configured by anyone on the MDM side. When somebody left the company, HR told IT, IT disabled the AD account, and access to master data ended the same afternoon as access to the file share. No MDM administrator was involved because no MDM administrator was needed.

The leaver is the expensive one

Go-live hides this. Every account is fresh, every role is deliberate, and the access model has never looked better than it does in week one. The gap opens the first time somebody resigns.

IT runs the offboarding checklist. AD account disabled, laptop collected, mailbox delegated, VPN revoked. The checklist was written when the MDM tool was part of the directory, so it has no line for the MDM tool. The leaver keeps a working password against the system that holds supplier bank details, and there is no error message anywhere, because nothing has gone wrong yet.

We have written before about the terminated employee who keeps approving invoices for three weeks because the ERP never heard about the termination. This is the same failure aimed at your own tool, and the irony of an MDM platform having a stale employee record problem is not lost on us.

Why it lands harder here than in most applications

A dormant account on a reporting tool is a licence you are wasting. On the master data platform it is a different kind of problem, mostly because of how quietly master data changes.

Editing a payment term or a bank account produces no alert, no ticket and no obvious victim. It surfaces weeks later in a payment run, by which point the change looks like any other steward edit. It also does not stay put: whatever is changed here reaches the ERP and the warehouse on the next distribution cycle, so one row rewrites itself across every downstream system that trusts you. The record of what happened is the audit trail, and an audit trail is only useful if the name attached to a change still means a person you can go and ask.

That last point is the reason for a rule that sounds bureaucratic and is not: deactivate a departing user, never delete them. A deleted user takes the meaning of every past entry with them, and you find out during the one investigation where it mattered.

What to do before SSO exists

Primentra does not have Active Directory integration today. It is on the roadmap for Q4 2026, and saying that plainly seems more useful than describing what it will do. Four things close most of the gap in the meantime, and none of them need a project.

Start by getting onto the offboarding checklist by name. Not under “other systems”. The tool, spelled out, with the person who administers it. That is a ten-minute conversation with whoever owns the leaver process, and it removes the entire failure mode. Have it in the week you go live, while the migration still has everyone's attention, because a year later nobody remembers the checklist exists.

Then read the last sign-in column, which most teams never open. Primentra records the last sign-in per user, and the admin dashboard's Active users panel shows every active account with the age of its last sign-in, or the word never. The answers tend to be obvious. An account reading “never” four months after go-live was provisioned speculatively. An account last used in March belongs to somebody who changed jobs in April. That is the report an access review normally spends a week assembling by hand.

Keep the number of roles small while you are at it. Permissions belong to roles rather than to people, so the honest answer to “who can edit suppliers?” ought to fit on one screen. Six roles you can name beats twenty that grew one exception at a time, and it turns the review above into a membership check instead of an exercise in reconstructing what somebody meant in 2024.

Last, keep approving separate from editing. Approval is its own grant on a role, and approvers are named per entity, so a reviewer is not an editor by default. That separation earns more without a directory than with one: an account nobody switched off can propose a change, but it still runs into a person at the approval step. A second lock on the door you forgot to check.

The mover, and the shared account

Two smaller versions of the same problem deserve a mention, because the last-sign-in report catches neither.

Someone who moves from procurement to finance signs in every day, so their account looks perfectly healthy while carrying a role they have no business holding any more. Nobody takes it away, because removing access from a colleague who still works here feels rude and no event forces the question. Only a membership review finds it, which is the honest argument for running one twice a year instead of annually.

The shared account is worse, and it arrives through a chain of reasonable decisions: a team needs access for a temp, provisioning takes a day, somebody shares a login. From that moment the audit trail is fiction. Every change carries a name that four people were using, and the one control that made the quiet edits investigable is gone. Named users cost nothing extra here, since Primentra's licence is flat and does not count them, so there is no budget argument to lose this one on.

Ask the vendor the lifecycle question, not the SSO question

“Do you support SSO?” gets a yes from nearly everyone and tells you almost nothing, because it is answered about authentication. The question that separates products is what happens to an account after the person stops working here.

Ask whether disabling the directory account actually revokes access or only removes a convenient sign-in path. Ask whether the tool can show you every account and when each was last used, without an export and a spreadsheet. Ask whether a user can be deactivated while their history stays readable. Our answer to the first is “not yet, ask again after Q4”. To the other two, yes. If a vendor answers all three with an unqualified yes, push on the first one, because it is harder than it sounds and plenty of products mean the sign-in path.

This is not an argument for staying on MDS, which is going away on a published schedule either way. It is an argument for spending one afternoon of the migration on the leaver process, rather than meeting it at the first access review, where it turns up as a finding with your name on it.

Common questions