The person who set up your master data platform left the company eighteen months ago. Nobody wrote the admin password down, because at the time there was only ever one administrator and he was standing right there.
Last week his account locked itself after five wrong guesses, from someone who was not him. Now nobody can add a user, nobody can unlock anyone, and nobody can even open the user list to see how bad it is.
On a SaaS product you would open a support chat and prove who you are. On software running against your own SQL Server, there is no vendor sign-in screen behind the curtain, because there is no vendor holding the keys. There is a server, a config file, and two doors that were built for exactly this day.
The ordinary unlock needs an admin you do not have
Primentra locks an account after five consecutive failed sign-in attempts. That part is working as designed. The two ways back in from there both assume something you may not have:
- Another administrator unlocks you. Someone with a working admin account ticks Active on yours and saves. This is the whole story when there are two or three administrators and only one gets locked.
- You unlock yourself with Forgot password. This needs a mail server configured and an Application URL that resolves, so the reset email can actually reach you. On a server nobody has touched since go-live, one or both of those is often not set up at all.
When every administrator is locked, forgotten, or the account was deleted along with the person who left, neither route has anywhere to start from. That is by design. Account Recovery takes over from there, and it works from the server, not the browser.
Two doors, and both skip the browser entirely
Neither path can be triggered by anyone who only has a login page in front of them. Both need the file system or a command prompt on the machine Primentra runs on.
| Your situation | Use |
|---|---|
| One admin password is lost, the account still exists | The recovery tool |
| Every administrator account is locked | Either one |
| You want a fresh admin without touching anyone else's account | Force the setup screen |
| Routine password change, you can already sign in | Neither, use the Users page |
Option 1: reset a password from the command line
The recovery tool reads the database connection out of Primentra's own config file and talks to SQL Server directly. The API does not need to be running for this to work, which matters when the lockout is tangled up with some other failure.
On the server, from the installation folder:
node scripts/recover-admin.mjs
Type the full command, including node. Double-clicking the file does nothing useful. Windows has no idea what program should open an .mjs file and will ask you to pick one.
Run it, and the tool prints the config path, the server, and the database it just connected to, then lists every account with its email, name, status, failed-attempt count, and whether it is an administrator. Pick a number, type a new password of at least 8 characters, confirm it, and the tool saves the hash, reactivates the account, and zeroes the failed-attempt counter. It then offers to add the account to the Administrators role if it is not already in one.
If the database has no user accounts at all, which happens after a restore from a backup taken before setup finished, the tool skips straight to offering a new administrator: an email, a display name, a password.
Option 2: force the first-run setup screen
This route adds a brand new administrator through the same screen a fresh install shows on day one. It never touches an existing account.
Open mds-config.json in the installation folder and set:
"forceSetupScreen": true
Open Primentra in a browser. The Create your administrator account screen appears in place of the ordinary sign-in page. Fill in an email, a display name, a password, and click through. The new account joins the existing Administrators role, and Primentra flips forceSetupScreen back to false by itself, so no later visitor ever sees that screen by accident.
Every account that already existed, admin or not, is exactly as it was before you edited the file.
Why there is no button for this on the login page
A remote reset reachable from the sign-in screen would be a way in for anyone who could reach the sign-in screen, which on a network-exposed server is anyone. Requiring a command prompt or a config file on the machine itself is what keeps that door shut. It moves the question from "do you know a password" to "do you already have the kind of access an attacker taking over the login page does not have."
Both actions still leave a trail. A recovery through the tool is recorded as admin_password_reset in the audit log, and a new administrator created through the forced setup screen shows up there as first_user_setup or user_created. A recovery leaves a record naming who ran it and when, the same as any other change to a user account.
Write this down before you need it
The actual fix here has nothing to do with either tool. It is keeping a second administrator alive on purpose: a shared break-glass account with its password in a password manager the whole IT team can reach, not just the one person who happened to click through setup. The same gap that leaves a leaver's account active is the flip side of this one, both come from a user list that lives inside the tool instead of in a directory somebody else already manages.
Check who is in your Administrators role today, right now, while you can still see the list. If the answer is one name and that name has left, changed roles, or cannot be reached this afternoon, you already know which of the two doors above you will be walking through eventually. Better to know on a quiet Tuesday than during an incident.
Common questions
Does the recovery tool need the API server running?
No. It reads the database connection from the config file and talks to SQL Server directly, so it works even when the API will not start. It runs at a command prompt on the server, not through a browser.
Does forcing the setup screen touch existing admins?
No. It only adds a new administrator through the ordinary first-run screen. Every existing account is left alone, and the setting switches itself back off once the account is created.
Isn’t a tool that resets any account a security hole?
It needs a command prompt or a config file on the server, which is a far higher bar than a login page. A remote reset reachable from a browser would be a door for anyone who found the sign-in screen. Both actions are written to the audit log, so a recovery always names who ran it.
What if I don’t have server access either?
Then it is an infrastructure question, not a Primentra one. Whoever manages the server, IT, a host, an MSP, holds the access both paths need. Neither works from a browser or a phone call to a vendor, on purpose.
Does a lockout touch the data?
No. Locking a user out only blocks sign-in for that account. Every entity, row, and pending approval sits untouched, waiting exactly where it was.
Check your own Administrators list today
Open Settings, count how many people can unlock an account, and confirm you can still reach each of them. Running Primentra already? The full recovery steps live in the docs, not just in this post.