Local accounts and security policy
What this page covers
Section titled “What this page covers”A connection first has to prove who you are. Layer 01 handles identity: where accounts come from, how strong passwords have to be, where the lockout threshold sits, what the login page says to the user, and which source addresses may use an account. Local accounts coexist with a directory service and single sign-on. This page covers local accounts and the policies they share with every other kind.
How to set it up
Section titled “How to set it up”Accounts
Section titled “Accounts”Administrators maintain accounts on the Users page. The list can be searched by username or email, each account shows where it came from (created locally, an LDAP directory, or an identity provider), and an external identity can be bound or unbound. A role change takes effect immediately, and the login credentials tied to it are invalidated at the same time.
Other common actions:
- Release a lock: let an account locked by consecutive failures back in.
- Idle exemption: keep an account out of the automatic deactivation of idle accounts.
- Disabling someone’s two-factor authentication: the rescue path for a user who changed phones and lost the recovery codes too.
- Allowed source ranges: see below.
Every local account an administrator creates carries the forced password change flag, so the user replaces the initial password that passed through someone else’s hands at first login. The initial password enters the password history, so it cannot be set back.
AI agent identities
Section titled “AI agent identities”Users also holds AI agents with human owners. Their tokens, roles, and self-service quotas follow the identity type. See AI agent accounts and tokens.
Groups
Section titled “Groups”User Groups is the grouping dimension for authorization subjects, orthogonal to roles. Granting to a group grants to every member. When you delete a group, the interface first tells you how many grants the action revokes along with it.
A user-group member may be added manually or through external group mappings on external sign-in. The page marks manual, mapped, or both; editing the manual list does not overwrite mapped support, and a mapping recompute preserves manual membership.
The personal page
Section titled “The personal page”Every user has a Profile page, where account information, self-service password change, and two-factor authentication management sit at one entrance. The formal name stays read-only for the directory service, and a separate display name is available. For accounts managed by a directory service or an identity provider, the password card becomes a notice pointing to where the password is changed.
Security policy
Section titled “Security policy”Policy keys on the Security Policies page and the values they ship with:
| Policy | Shipped value |
|---|---|
| Lockout threshold (failures) | 10 |
| Lockout duration (minutes) | 30 |
| Minimum password length | 12 |
| Password must mix letters and digits | Yes |
| Password history entries | 4 |
| Password validity (days) | 0 (no limit) |
| Force a change after a reset | Yes |
| Two-factor authentication scope | Off |
| Web idle timeout (minutes) | 60 |
| Maximum web session (hours) | 12 |
| Automatic deactivation of idle accounts (days) | 0 (off) |
Each policy key lists the requirements and verdicts of the in-force policy groups in a drawer. The page head can apply one group or every in-force group, and previews the keys that will change. A stricter value is left alone, and a conflict between groups is left to the administrator. It takes effect when you save. See Policy groups and Compliance map.
Login banner
Section titled “Login banner”Also on the security policy page, fill in the login banner title (one line, up to 120 characters) and the login banner body (line breaks allowed, up to 2000 characters). The content appears as plain text ahead of the form on the login page, and stays visible at every step of signing in. Clearing the body stops it from being shown.
Per-account source address restrictions
Section titled “Per-account source address restrictions”In the “allowed source ranges” field of the account editor, enter addresses or ranges such as 10.0.0.0/8, up to 32 entries per account.
A bare address counts as a single host. An empty list means no restriction, and the interface marks the three states apart: unrestricted, equivalent to unrestricted, and restricted.
A setting that would lock you out raises a warning without blocking the save, and comes with a way back.
What auditors can see
Section titled “What auditors can see”- An account update leaves field-level before and after values; releasing a lock is its own action type.
- Changes to source ranges use the same field diff, with the full values before and after.
- A policy change records the person, the policy key, and the old and new values; both login banner keys keep their old and new values in full.
- Automatic deactivation of an idle account and changes to the exemption flag are each their own record.
- A user signing in with a password that does not meet policy leaves a record that holds the classification only, with no password material.