User Accounts

User Accounts

An account is how somebody signs in and what the platform attributes their actions to.

Where to find it

Architect Panel → Security:

• Disabled User Accounts — accounts closed administratively
• Blocked User Accounts — accounts banned after failed sign-ins
• Permissions — what a group grants

User accounts and groups live in the Admin Panel sidebar under User Administration — All Users and User Groups. What a group may reach is granted in the Architect Panel.

An account is an identity, not a person

The distinction that explains most confusion. Identity is recorded as three parts — the sign-in method, an identifier within it, and a domain — so the same human arriving by password and by single sign-on is two identities.

That is deliberate: it lets the audit trail distinguish "Jo signed in and did this" from "an integration acting as Jo did this". It also means "I already have an account" can be true and irrelevant.

The account is not the access

An account by itself reaches almost nothing. Access comes from group membership, and group membership is a separate decision.

So creating an account is not granting access, and disabling one is not the only way to remove it — worth being precise about, because people conflate the two constantly.

Settle the lifecycle early

Most organisations plan joiners and discover the rest:

• Joiners — usually handled.
• Movers — rarely. People are added to new groups and left in old ones, accumulating access from every role they have held.
• Leavers — handled for directory-backed accounts, frequently not for local ones.
• Dormant accounts — almost never. Self-registered accounts in particular accumulate indefinitely.

The mover case is the one that shows up in every access review, and it is entirely preventable by making removal part of the same task as addition.

Local accounts need the most attention

They are outside your directory's joiners and leavers process, and they are disproportionately privileged, because local accounts tend to be the ones created for administrators and emergencies.

Keep a list of every local account, who owns it and why it exists.

Never share an account

It destroys attribution — the audit trail records the account, and the account is not a person — and it trips account banning constantly, because one person's failed sign-in counts against everybody.

Where a task genuinely needs an account rather than a person, that is a service identity with its own credentials, not people sharing a login.

Disabling is better than deleting

A disabled account keeps its history intact, so records still say who did what. Deleting one leaves an audit trail referring to somebody who no longer exists.

Worked example

An organisation runs directory-backed accounts for staff and eleven local accounts, each with a named owner and a reason. Group changes are part of the movers checklist, so a role change removes old memberships as well as adding new ones. The annual review found nobody holding access from a previous role.

Recommendations

• Handle movers, not just joiners and leavers.
• Inventory local accounts and review them.
• Never share an account — use a service identity.
• Disable rather than delete.

Creating an Account

An administrator can create an account rather than waiting for somebody to register.

Where to find it

Architect Panel → Security:

• Disabled User Accounts — accounts closed administratively
• Blocked User Accounts — accounts banned after failed sign-ins
• Permissions — what a group grants

Architect Panel → Configuration:

• Site Settings — the welcome e-mail settings

User accounts and groups live in the Admin Panel sidebar under User Administration — All Users and User Groups. What a group may reach is granted in the Architect Panel.

What to settle at creation

1. Which groups — this is the access decision, and the one worth thinking about.
2. How they will sign in — local password, directory, or something else.
3. Whether they are told, and what the message says.

Groups are the decision

Everything else is mechanics. Add somebody to the groups their role needs and no more — it is far easier to add a group later than to notice somebody has one they should not.

If you find yourself unsure which groups a role needs, that is worth resolving once rather than deciding case by case, because case-by-case decisions drift generous.

Never set a password and tell them

Send a link that lets them set their own. A password chosen by an administrator and communicated by e-mail sits in a mailbox indefinitely, gets forwarded, and is known to two people.

The welcome message must explain itself

Somebody who did not ask for an account receives an unexpected e-mail saying one has been created for them. With no context, that looks exactly like phishing — and the more security-aware your users, the more likely they are to ignore or report it.

Name the organisation, say why the account exists, and where possible say who asked for it.

Do not create accounts speculatively

Creating accounts for a team "so they have them" produces dormant accounts nobody owns, which is the population most likely to be forgotten at a leaver's departure. Create them when somebody needs one.

Record why

Particularly for local and privileged accounts. An account with no recorded purpose is one nobody will ever feel able to remove.

Check what they can actually see

For a new kind of account — a new role, a new external population — sign in as them once. It takes a minute and it is the only reliable way to know what you have granted.

Worked example

A manager requests an account for a new starter. It is created with the two groups their role needs, a set-your-password link rather than a password, and a welcome message naming the organisation and the requesting manager. For the first account of a new role type, an administrator signs in as them to confirm what is reachable.

Recommendations

• Decide groups deliberately — that is the access.
• Send a set-password link, never a password.
• Say who created it and why in the message.
• Do not create accounts in advance of need.

Self-Registration

Self-registration lets somebody create an account without an administrator.

Where to find it

Architect Panel → Security:

• Disabled User Accounts — accounts closed administratively
• Blocked User Accounts — accounts banned after failed sign-ins
• Permissions — what a group grants

Architect Panel → Security:

• User Verification — proving something before granting more

Architect Panel → Configuration:

• Site Settings — registration settings

The only question that really matters

Not whether people may register, but what a brand-new account can reach.

Self-registration is safe exactly to the extent that a new account reaches nothing sensitive. If registering grants access to real data, then anybody in the world has that access — and no amount of care in the form changes it.

Check it by registering

Create an account through the actual form and look at what it can see — menus, datastores, browse views, the API. Reasoning from the group configuration is unreliable, because access accumulates from several places.

Pay particular attention to the All Users group: anything granted there reaches every account including new ones, and it does not appear in your default group configuration at all.

Registration proves control of an address

Nothing more. Not who somebody is, not that they work where they claim, not that they are entitled to anything.

Verification is the upgrade path

The pattern that works: let anybody register into a minimal group, and require verification to gain more. That keeps the door open without the door granting anything, and every member of the verified group got there by passing a check.

It is also far less work than approving people by hand, and it scales.

Expect junk

A public registration form attracts automated sign-ups. With minimal default access that is an annoyance; with real access it is an incident. Rate limiting and account banning apply, and neither is a substitute for the accounts reaching nothing.

Give self-registered accounts a lifecycle

Nobody owns their leaver process, so they accumulate indefinitely. Decide what happens to an account unused for two years — because "nothing" is a decision you will have made by default.

Both models can coexist

Staff created by an administrator, customers registering themselves, with different default groups. That is usually the honest arrangement.

Worked example

A portal lets anybody register, granting only their own profile and public content. Verifying an employer domain awards the partner group. A test registration before launch found an All Users grant on a supplier datastore left over from a project, which was moved to a specific group.

Recommendations

• Decide what a new account reaches before opening registration.
• Register one and look rather than assuming.
• Verify to upgrade instead of approving by hand.
• Audit the All Users group.

Resetting Someone’s Password

An administrator can reset somebody's password. The mechanics take seconds; the verification is the part that matters.

Where to find it

Architect Panel → Security:

• Disabled User Accounts — accounts closed administratively
• Blocked User Accounts — accounts banned after failed sign-ins
• Permissions — what a group grants
• Passkeys — the stronger alternative

Architect Panel → Configuration:

• Site Settings — the self-service route

Architect Panel → Activity:

• Activity Log — the record of the reset

This is the attack

Somebody telephoning to ask for a password reset is exactly what an attacker does, and it is the route round every control you have — a passkey cannot be phished, and a service desk can be talked to.

The reset is not the risk. The lack of a verification step is.

Verify with something they cannot easily obtain

Not a name, a date of birth, or an address — all of which are widely known or discoverable. Something specific: a callback to a number already on record, confirmation from their manager, a code sent to a channel they already control, or an in-person check.

Write down what your check is, so it does not depend on who happens to answer the telephone.

Prefer self-service

A reset link to a verified address is a stronger check than a hurried human conversation, and it leaves a cleaner record. Unless you have a rigorous, tested identity process, self-service is the better default and administrator resets should be the exception.

Send a link, never a password

The same rule as account creation. A password you choose and communicate is known to two people and sits in a mailbox.

Ask why they are locked out

Before resetting anything:

• Forgotten — reset, or point them at self-service.
• Recently changed it — something else is probably still using the old one.
• They were not trying — somebody else was. That is an incident, not a reset.

The third answer changes everything, and you only get it by asking.

Check what is actually wrong

A reset does nothing for an account that is disabled, banned after failed attempts, or blocked by address. Check those before resetting — it is the commonest reason a reset "does not work".

Record it

Who asked, how you verified them, and what you did. That is the record that matters if the request turns out not to have been genuine, and it takes a sentence.

Repeated resets are a signal

The same account needing frequent resets is usually a stale credential in some client retrying, or somebody being targeted. Investigate the third occurrence rather than performing it again.

Worked example

A caller asks for a reset. The administrator calls back on the number held on record, confirms, sends a set-password link rather than a password, and notes the verification in the ticket. On another occasion the same check found the caller could not receive the callback — which turned out to be somebody attempting to take over the account.

Recommendations

• Verify with something not publicly known.
• Prefer self-service to an administrator reset.
• Check for disabled, banned or blocked first.
• Record who asked and how you checked.