Users & groups

Users and groups are the identity layer of Taranac. A user is an account; a group bundles users together and carries the policy-relevant attributes. Together they answer the WHO dimension of every AAA decision: when a TACACS+ or RADIUS request arrives, Taranac matches the authenticated identity (and the groups it belongs to) against your AAA policy rules. The same accounts and groups also govern who can sign in to the Taranac admin UI, and what they are allowed to do there.

Identities come from one of two sources. Local users live entirely in Taranac and are managed on these pages. Directory users (auth_source = ldap) are mirrored in from a directory — Active Directory, OpenLDAP, FreeIPA or another LDAP server — by the sync engine; they appear in the same lists but are largely read-only here. This page covers local accounts and group membership; for directory-sourced identities see LDAP directories.

A user has no role of its own. Permissions, admin rights, and MFA enforcement are all derived from the groups the user belongs to. An account in no groups can still authenticate to network devices through AAA policy, but has no access to the admin UI.

Open Infrastructure → Users. The list is searchable, filterable, and sortable, with columns for username, email, name, groups, status, locked state, source, validity, and last login. Filters cover status (active/inactive), locked, source (local/ldap), and validity (valid / expired / pending).

The Users list — group badges, status, source and validity at a glance.

Click New and fill in the form:

Passwords are validated against the password policy (minimum 12 characters, with upper- and lower-case letters, a digit, and a special character), hashed with bcrypt, and recorded in password history. For local users Taranac also derives an NT password hash, which is what RADIUS MS-CHAP / PEAP MSCHAPv2 authentication needs — so a local user can be used for 802.1X without any extra step. Directory users never have an NT hash.

In edit mode the page shows the form alongside read-only metadata, MFA status, and linked PKI certificates.

• Change password is a collapsible section — leave it empty to keep the current password.
• Lock / Unlock is independent of the active flag: a locked account fails authentication even while active. Unlocking also resets the failed-login counter. Repeated automatic failures can auto-lock an account until a timeout passes; a manual lock stays until an admin unlocks it.
• Delete is blocked for your own account and for directory users. Deleting a user automatically revokes their active PKI user certificates and detaches any device certificates that were linked to them.

Open Infrastructure → Groups. Columns show name, source, the Admin and MFA flags, and the member count (click it to preview members).

The Groups list — admin and MFA flags are the levers that matter.

When you create or edit a group you set:

The Members panel lets you add and remove users (changes are saved together with the form). You can also create a brand-new user inline while building a group.

A user’s effective UI/API permissions are resolved through their groups:

User → Groups → Group.rbac_model → permissions

If the user belongs to any group flagged as an admin group, they get full access and all permission checks are skipped. Otherwise their permissions are the union of every group’s RBAC model. A user with no group — or whose groups have no RBAC model and no admin flag — cannot use the admin UI. MFA enforcement follows the same logic: if any of the user’s groups requires MFA, MFA is mandatory at login.

AAA policy rules match on WHO (users and/or groups), WHERE (devices/device groups), and WHEN. A rule can target specific users, one or more groups, or any identity. At request time Taranac evaluates the authenticated user together with all the groups it belongs to, so adding a user to the right group is usually all it takes to grant device access — no rule edit required. See AAA policy.

For TACACS+ device administration, the enable (privilege escalation) password is resolved through an inheritance chain, with the first explicit (non-inherit) setting winning:

User → Group → TACACS+ profile → Global default

Each enable_mode can be:

If a user is in several groups that each define an enable mode, the most recently updated group wins. Custom enable passwords are stored encrypted; revealing one in the UI is audit-logged.

Local accounts can carry an optional valid-from / valid-until window. Outside the window the account is rejected at login, at token refresh, and on every API request — a soft but consistently enforced expiry. Leave a bound empty for “no restriction”. These fields apply to local users only; directory users have no validity window in Taranac.

• A new network engineer. Create a local user, add them to a “Network Admins” group that has an RBAC model (or the admin flag) plus a TACACS+-friendly enable mode. They can now log in to the UI and administer devices governed by AAA rules that target that group.
• A contractor with an end date. Create a local user and set valid-until to the contract end date. Access stops automatically — no cleanup reminder needed.
• Granting AD users access without recreating them. Let LDAP sync import the AD security group, then set its RBAC model / admin flag here. AD members gain Taranac access on their next login; you never manage their passwords.
• A 802.1X service/user account. A local user automatically has the NT hash needed for MS-CHAP / PEAP, so it can be referenced by NAC and RADIUS flows with no extra configuration.
• Forcing step-up auth for sensitive staff. Turn on Require MFA on the group rather than per user — it overrides individual settings for everyone in it.

• LDAP directories — sync directory users and groups.
• Roles & permissions — what RBAC models actually grant.
• Multi-factor (MFA) — enrollment and enforcement.
• AAA policy — how users and groups feed the WHO dimension.
• TACACS+ — enable handling and shell profiles.
• Project repository