Skip to content

Onboarding and leavers

Steward covers both ends of an account's life: creating accounts for new hires from a template, and closing the account of someone who leaves in one audited flow. Both reuse the delegations and checks of the single actions: there is no separate "onboarding admin" right.

Creating accounts needs the helpdesk (the first password and the enable go through the password service). The leaver flow works without it, but its Disable and Random password steps then report helpdesk unavailable.

Onboarding templates

An administrator prepares the templates under Delegations > Templates (delegations.manage). A template fixes:

  • the OU where accounts are created;
  • the naming rules: patterns for the login (sAMAccountName), the UPN (with one of the domain's UPN suffixes) and the display name. Login patterns use {first}, {last} (lowercase ASCII, accents removed), {f}, {l} (first letter) and the characters a-z 0-9 . - _, for example {f}{last} or {first}.{last}; the display pattern also takes {First} and {Last} as typed, for example {First} {Last};
  • default values for delegated attributes (department, company, office...; at most 15);
  • the groups the new account joins (at most 20);
  • whether the user must change the password at first sign-in, an optional expiry (a number of days from the creation), and whether the account ends up enabled or stays disabled.

Template changes are audited (onboarding.template_created, onboarding.template_updated, onboarding.template_deleted). Operators only see the templates their delegations allow them to use.

Create an account

Users > New user:

  1. Choose a template. A template you cannot fully use is shown as unavailable with the reason (for example, no right on one of its groups).
  2. Person: first and last name, and the template values, which you may change for this person (an empty value is not written). The template's group memberships can be made temporary with an until date (for example a contractor; see temporary membership).
  3. Review: the preview shows the exact login, UPN, display name and OU. Logins are built from the names (accents removed, lowercase, sAMAccountName at most 20 characters) and checked against the whole domain (users, groups, computers): when a name is taken, a suffix 2, 3... is added. Check that the person does not already have an account.
  4. First password: generated (shown once) or typed by you.
  5. Confirm, with a step-up.

Rights needed. A delegation with users.create (plus users.read) on the template's OU, users.attributes.write on each default attribute (and on accountExpires when the template sets an expiry), and groups.members.write on each template group. Everything is checked before anything is written: a missing right refuses the whole creation.

What the console does, in order:

  1. creates the account disabled, without a password, with the write account (Create user objects on the OU);
  2. sets the first password and "must change" with the reset account (password service);
  3. adds the groups;
  4. reads the account back and checks it is a standard account;
  5. enables it with the reset account (only the disable bit), unless the template keeps it disabled.

If a step after 1 fails, the groups already added are removed, the account stays disabled, and the result screen (and the audit) says exactly what exists and what failed. The console never deletes an AD account: finish or remove it in AD.

Uncertain outcome. If the creation's answer is lost (timeout, DC restart), the console cannot know whether the account exists. Its names are then held for 30 minutes (Onboarding:UnknownCreationHold): a new creation for the same names is refused meanwhile, so you search for the account first instead of creating a duplicate.

Limits (per operator, configurable in the Onboarding section): at most 20 creations per hour (Onboarding:MaxCreationsPerOperator, Onboarding:CreationWindow), 60 name previews per minute. A CSV import counts each row against this limit too.

Each creation is audited users.create.

AD rights for account creation

After granting users.create, export the AD delegation again and have a domain administrator apply it (Delegation model and AD rights). On each OU it adds:

  • for the write account: Create user objects, and an OWNER RIGHTS right (read permissions only, on user objects) so the write account does not keep the owner's implicit right to change the permissions of the accounts it created;
  • for the reset account: Reset Password, pwdLastSet and userAccountControl.

The diagnostics check Create user objects (allowedChildClassesEffective).

Residual risk. Whoever steals the write account's password can create accounts in those OUs, including enabled ones with a password of their choice (ordinary domain users, in no group they cannot already change). Grant users.create only on the OUs where new hires go, and monitor account creations (Windows event 4720) that have no users.create audit row. Samba DCs ignore OWNER RIGHTS: there the creator keeps "change permissions" on the accounts it created.

Account expiry date

The account expiry (accountExpires) is an ordinary attribute of type date: grant users.attributes.read / users.attributes.write on accountExpires. The write account sets it (no helpdesk needed). The operator picks the last day the account may be used, or Never.

Like ADUC, the console stores the end of that day (midnight at the start of the next day) in the instance's time zone, Directory:AccountExpiryTimeZone (an IANA id such as Europe/Paris; default UTC, checked at start; in compose: STEWARD_Directory__AccountExpiryTimeZone). Never is stored as 0; both 0 and 0x7FFFFFFFFFFFFFFF read as never.

Leavers

Leaver... in the profile header closes an account in one audited flow.

Preview

The dialog opens with a preview: for each step, whether the console allows it for you on this account (the same checks as every action: delegation scope, tier, VIP, privileged accounts never manageable, never your own account), and why not when it does not. Nothing is written by the preview (audited users.leaver.preview).

Step What it does Needs (on the account)
Disable Sets only the disable bit, through the password service; the account's console sessions end at once users.disable + helpdesk
Random password Resets the password to a strong random one that nobody sees (not shown, not stored, not logged) users.password.reset + helpdesk
Expiry Now (the last day of validity is yesterday, so the account is expired at once) or a chosen last day users.attributes.write on accountExpires
Remove groups Removes the account from each group listed as removable; groups you may read but not manage are listed as kept, groups you may not read are only counted groups.members.write on each group
Clear attributes Empties the selected attributes (e.g. manager, telephoneNumber): only those delegated to you are selectable users.attributes.write on each attribute
Description note Writes the note of the leaver template in the description, e.g. Left on 2026-10-18 (INC-42) users.attributes.write on description

No new permission: each step reuses the action of the single operation.

Run

Enter the ticket (required when the instance says so; it also goes in the note), confirm, then the step-up (authenticator code unless your last one is recent; Teleport sessions are their own step-up). The steps run in a fixed order: disable, password, expiry, groups, attributes, note. Each is decided again on fresh facts and written exactly like the single action. A refused or failed step does not stop the others: the result lists every step as done, no change, refused (by the console) or failed (with the reason, e.g. refused by AD when the service account has no right there). Run the dialog again to retry what failed.

No caller verification is asked: a leaver is not a reset requested by the account's owner.

Audit

Every row of a run shares one correlation id (shown in the result) and carries the ticket: the decisions (authz.decision), each change under its usual action (users.disable, users.password.reset with mode:random and leaver, users.attributes.write, groups.members.remove) and one summary row users.leaver listing step=result (result failed, reason partial:<failed>/<steps> when not everything went through).

Leaver template

Delegations > Templates, below the onboarding templates (delegations.manage and a step-up to change it; audited leaver.template_updated with the old and new values):

  • which steps are ticked by default;
  • which attributes are cleared by default (among the clearable ones: text, e-mail, phone and manager attributes, never the names or the description);
  • the note format: {date} required, {ticket} optional (without a ticket, the placeholder and its brackets are dropped).

The template only sets defaults: the operator can untick any step, and every step is still decided by the console. The same template drives the bulk action Run leaver template (Bulk actions).

What a leaver does not do

It never deletes or moves the account, never touches the home folder, mailbox or licences, and never removes the primary group (Domain Users). Do those in AD / Microsoft 365 according to your procedure.