Users & identities
Onboarding
The form asks for the profile (first name and surnames separately). The full name is not typed: BIAM composes it (first name + paternal + maternal surname) and uses it for the cn/displayName and the sn in AD. A user can be born in local mode or anchored to Active Directory (BIAM creates it in the corresponding OU).
The username in each system is generated by the connector's naming convention (see Policies); manual exceptions exist but are flagged as such.
AD management from the console
BIAM writes to Active Directory — operators never need RSAT nor direct access to the domain controllers:
- Editing identity attributes in the profile (phone, title, location, manager…) pushes the change to AD immediately, mapped through each attribute's directory key; bridged target systems receive the update too.
- Full name (
cn/displayName) and surname (sn) are composed by rule, keeping the whole directory consistent. - Password resets, enable/disable, and governed OU moves with four-eyes approval and a frozen preview of the effects.
- Every one of these operations is permission-gated and audited.
Statuses
| Status | Effect on target systems |
|---|---|
pending | No access yet; activated when credentials are set or its hire window opens |
active | Re-enables accounts backed by a current access grant (least privilege: an orphaned account does not come back on its own) |
inactive / blocked | Disables all provisioned accounts |
suspended | Reserved for lifecycle windows; never set by hand |
Per-system accounts
The user's sheet shows their accounts per connector: the materialized username, its source (generated, same as AD, or manual as an exception) and its status mirroring the target system.
Deleting an account is tombstoning: it requires four-eyes approval and leaves a tombstone — the account is never re-created automatically even if the user is granted the policy again. To bring it back you must explicitly rehabilitate (with a reason, audited) and re-grant the access.