Say Anna leaves on Friday. At five o'clock IT disables her Active Directory account, and her laptop and her mail stop working. Her account in the master data tool keeps working, because nothing told it. We are building Active Directory SSO into Primentra to close that gap.
MDS never had the problem. It kept no users of its own, so a leaver was gone everywhere at once. Most replacements keep their own user list, Primentra included today, and we wrote earlier about who turns those leavers off in the meantime.
We expect the Active Directory sign-in to ship in Q4 2026. First what changes on screen for administrators and data stewards, then a technical deep dive for IT.
Why on-premises AD first
Primentra runs on your own Windows server and SQL Server and needs no internet, so a cloud tenant would be its first outside dependency. Teams that leave MDS also keep their users and groups in AD already. We named the columns IdentityProvider and ExternalId, so Entra ID can fit in later without a second schema change.
What changes for your users and administrators
Signing in
The sign-in screen asks Windows account or Primentra account. It offers the Windows account first and remembers the choice. Your users type their Windows name and password: anna, COMPANY\anna or anna@company.com.
A refusal says Invalid username or password. for a wrong password, an unknown name or an account AD has disabled. The text is the same for all three on purpose. An expired Windows password gets Change your Windows password first. A Sign in with Windows button, with no typing at all, is planned too. It is still in test.
Roles on the role page
Open Access Management → Roles and pick a role. The page has four numbered steps: 1 Settings, 2 Who gets this role, 3 Has the role now and 4 What this role may do. In step 2 you add AD groups, or single users by hand, and each change saves at once. Step 3 lists everyone with the role and why: via AD group or added by hand.
A person in a mapped group gets the role at every sign-in and loses it when IT takes them out of the group. Roles you add by hand stay. Use groups where you can, so IT keeps the one list.
New user from AD, and the labels
Access Management → Users → New user first asks: Primentra user or AD user. For an AD user you search AD, pick the person and choose the roles. Name and e-mail come from AD with a from AD badge. A person who is already in Primentra shows as Already in Primentra.
Lists label every user AD user or Primentra user. An administrator who is not linked to AD gets the label Local admin. Keep at least one: it signs in with its Primentra password, also when every domain controller is down.
The Sign-in tab
When someone leaves
When IT disables, expires or deletes the AD account, Primentra switches the user off at the next sign-in or at the daily check, and every open session ends. When AD enables the account again, the user stays off until an administrator ticks Enabled, so AD never overrules an administrator who switched someone off. The Users list marks such a person Enabled in AD, switched off here.
The technical deep dive
This part is for IT. If you only use Primentra, you can stop here.
How the sign-in works
- Primentra refuses an empty password before it talks to AD, because AD reads an empty-password bind as an anonymous sign-in and answers OK.
- With its own read-only AD account, it searches
sAMAccountNameanduserPrincipalName. A typed domain prefix must match the user's own domain (msDS-PrincipalName). - On a second connection it binds as that user with the typed password. That bind is the password check.
- It reads the user again by object ID and decides who this is.
Primentra accepts ldaps:// addresses only. It remembers the controller that answered for 5 minutes, so a dead first controller slows down one sign-in, not every one.
The Windows password form needs HTTPS and stays hidden on plain HTTP. Behind IIS, the proxy on the same server must prove HTTPS with X-Forwarded-Proto or X-ARR-SSL. Primentra ignores those headers from any other machine.
Primentra sends at most 3 wrong passwords per user name to AD in 30 minutes, then refuses the name without asking AD. So nobody can use our sign-in page to lock a domain account. The catch is that a colleague who types Anna's name wrong three times also blocks Anna from that form for half an hour. Both numbers are settings. Keep them under the lockout rule of your domain.
Kerberos: still in test
The Sign in with Windows button uses the Kerberos ticket of a domain PC. We are testing it now on a real domain controller, with Primentra running as a Windows service. We will write about how it works when that test has passed.
Identity: objectGUID, never the e-mail
Primentra stores a linked user with the AD objectGUID, in the byte order Get-ADUser shows, and reads the user with <GUID=...> as the search base. That finds the user in any OU. Rename Anna, move her or change her e-mail, and the link holds.
The e-mail comes from mail, else from the UPN. It matters once: at the first sign-in, Primentra links a plain Primentra user with the same mail. The match never uses the UPN, so a migration can not make a second user for one person. With the UPN as e-mail, approval mails may reach an address that is not a mailbox, so ask IT to fill in mail.
Primentra never links an administrator, approver or moderator that way. Anyone who can set their own mail in AD to the address of a Primentra administrator would sign in as that administrator. A first sign-in does not link a locked account either: five wrong passwords may be an attack on it right now.
Groups: tokenGroups and nesting
One read of tokenGroups gives every group SID of the user, nested groups and the primary group included. When a plain AD account gets an empty answer, Primentra asks per mapped group with the rule 1.2.840.113556.1.4.1941, which follows nesting. When neither works, it stops and changes nobody. The usual fix is to add the AD account to Windows Authorization Access Group. Mappings store the group SID, so a renamed group keeps working.
The daily check and its brake
Once a day, after the hour you set (02:00 by default), Primentra reads every linked user by GUID. It switches off users who are disabled or past accountExpires, and syncs the AD roles of everyone else. A temporary AD lockout changes nothing, because it ends by itself.
"Not found" was the hard case. A hardened domain hides protected accounts from a plain AD account and answers "no such object", as for a deleted user. So each run first reads the built-in Administrator of the domain, the domain SID plus -500. If that read fails, "not found" switches nobody off. A user who signed in during the last 24 hours also stays on. The run lists both groups for you.
An automatic run that would switch off more than half of the linked users, and at least three, changes nobody and counts as failed. We call it the brake. A broken permission should not empty your user list overnight. Run now shows the list first and applies nothing until you confirm. A failed run tries again after 60 minutes. After two failures in a row every active administrator gets one mail, and the bell stays on until a check passes.
Guards and audit lines
- Set
"enabled": falsein theadblock ofmds-config.json, and AD is off at the next request, with no restart. While it is off Primentra can not see who left, so use it for an outage only. recover-adminon the server makes a new local administrator at any time. See Account Recovery.- The password of the AD account sits in
mds-config.json. Only the service and administrators can read that file, and the API never returns the password. - The audit log gets a line for every sign-in with its method, every refusal, link, unlink, role sync, switch-off and settings change. A hand edit of the config file does not show up there.
Connecting to the domain
On a server in the domain, Fill in from this server's domain reads the primary DNS suffix, asks DNS for _ldap._tcp.dc._msdcs.<domain>, writes each controller as ldaps://host:636 and builds the Base DN. It never overwrites a field you typed. The AD account needs read rights and nothing more; it is not the account the Primentra service runs as.
Primentra trusts Node's own list, the Windows certificate store (hence Node.js 22.15 or later) and an optional CA file on a local drive. Each address must be a name in that controller's certificate, usually the controller's own name, not the domain name. For a wrong name, Test connection shows the names the certificate does carry.
What this version does not do
- One domain. Primentra does not find users from another domain in the forest.
- No Entra ID, SAML, OIDC, SCIM or NTLM.
- The AD link of a user does not travel in a model export. Group mappings do.
- No screen to link many existing users at once. They link at their first sign-in, and an administrator links the privileged ones one by one.
The Active Directory & SSO page gets the full set-up steps when it ships. Until then, sign-in works as Authentication describes.
Common questions
Does Primentra write to Active Directory?
No. It reads, with an AD account that has read rights and nothing more. It never changes a user, a group or a password in AD.
Does a wrong Windows password count toward the Primentra lockout?
No. Five wrong Primentra passwords lock an account. Wrong Windows passwords have their own limit of 3 per user name in 30 minutes, and they never touch the Primentra count.
Planning a move from MDS and need AD sign-in on day one? Follow issue #13 on our public tracker. We close it when this ships.