Users
The three user states, why delete means "move to Preserved", what each block of the detail page holds, and which fields depend on licence modules.
Identity › Users has three pages for the three user states: Active, Stage, Preserved. A login exists in exactly one state at a time.
Three states
| State | Page | Can log in | Holds a UID | Comes from |
|---|---|---|---|---|
| Active | Active users | yes | yes | added directly, activated from Stage, restored from Preserved |
| Stage | Stage users | no | no (UID shows -1) | pre-created before onboarding, migrated from a legacy directory pending review |
| Preserved | Preserved users | no | keeps its UID | an active user that was deleted |
A stage user has no Kerberos principal, no UID, and its group memberships are inert; all of that is allocated on activation. Activation is one-way: an active user cannot go back to Stage.
Deleting an active user moves it to Preserved by default. A preserved user keeps its UID, home path and most attributes, but its group memberships are cleared; after a restore, groups have to be re-added. A second delete on the Preserved page removes it for good, and the UID is never reused (the server allocates sequentially from the ID range, see ID ranges).
Why preserve: file ownership on disk is the numeric UID. Deleting and recreating the same login yields a new UID and orphans every old file. Audit trails also depend on the historic login-to-UID mapping.
List page
Search matches login, name and e-mail. Disable keeps the account but refuses authentication; the user still holds its UID and stays in its groups. Disable on departure, delete once nothing is left behind.
Detail page
The jump links on the right map to the blocks:
| Block | Holds | Notes |
|---|---|---|
| Identity settings | first / last / full name, job title, GECOS, class | Full name is cn; the display name AD users see comes from it |
| Account settings | login, home, shell, UID / GID, password, password expiry, SSH public keys, certificates, principal aliases | Login is immutable after creation. The SSH public keys block appears only with the ssh-keys module; the certificates block is in every tier |
| Password policy | the policy in effect for this user | Decided by group policy priority, not editable here; see Password policies |
| Kerberos ticket policy | per-user ticket lifetime override | Empty = global value |
| Contact / Mailing address / Employee information | e-mail, phone, department, manager | Manager is another user; it is cleared automatically when that user is deleted |
| User attributes for SMB services | SID and Samba attributes | Meaningful only once an AD trust exists |
The "Is a member of" tab lists direct and indirect groups, netgroups, roles, HBAC rules and sudo rules. Switch to "Indirect" to see membership inherited through nested groups; "why can this person log in to that host" starts here.
Boundaries
- UIDs are allocated server-side from the local ID range; the UI has no field for it. To pin a UID (keeping numbers from a legacy system) use
ipa user-add --uid=. - Bulk import is not a UI task: loop
ipa user-add, oripa migrate-ds. - Users from an AD trust are not in this list; they live in AD and IPA only maps their IDs. To override a trusted user's uid / shell on specific hosts use ID views.
- While the licence is invalid the page is read-only, including Disable / Enable; changes submit again once the licence is restored.