Accounts

Accounts is the administration workspace for people, groups, access requests, and service-account credentials. Users can understand their own access and management scope. Administrators and group managers use the same app to review and change the records they are allowed to manage.

Review duplicate email addresses

Open Administration → Duplicate email addresses to compare accounts sharing an address. Matching ignores letter case and surrounding spaces. The last Cloud web login is shown separately for each account; FreeIPA accounts also show the last Kerberos login and sync time. Kerberos activity can include use outside Cloud. Times are in UTC. Not recorded does not mean the account has never been used.

Open an account to inspect its access before deleting it. Deleting a FreeIPA account also deletes the user in FreeIPA. Data and permissions are not transferred to the remaining account. Confirm each deletion separately. Resolved addresses disappear from the list; you cannot delete your own account.

Use Accounts

Account types are Guest, Login (with a configurable label) and FreeIPA. Configure which types are allowed and visible in Core's Accounts & sign-in settings, not in Accounts. See Account types.

• Find a user by uid, name, or email and review provider, profile, roles, expiry, and group membership.
• Search groups, distinguish direct from inherited membership, and maintain members or managers within your scope.
• Process pending account requests and inspect the history of deleted or expired accounts.
• Review user-bound and resource-bound service credentials, then revoke an active key when its access should end.
• Trace account and access changes through the audit log, reminder history, and notification batches. Creating or deleting a batch draft, finalizing a batch, and retrying failed recipients record the acting administrator and batch ID. Message content and recipient email addresses are not copied into these audit entries.
• Inspect and maintain Linux identity attributes. Configure defaults and backfill existing accounts in Administration. FreeIPA manages its own values. See Linux identities.

Understand the Accounts model

Direct membership is stored on one relationship. Effective access can also come through nested groups. Removing one direct membership therefore does not prove that access is gone.

Email addresses and existing duplicates

Creating an account or changing its email checks the address across local and FreeIPA accounts, ignoring case and surrounding whitespace. A conflict returns HTTP 409. New addresses are stored in lowercase without surrounding whitespace.

A local full account may have no email address when the operator allows it. Such accounts sign in with a paired app or a passkey. One-time login tokens from the account's actions are bound to the account, so they work without an email address. Notify and switching to FreeIPA are hidden for them.

Existing duplicate addresses remain attached to their account IDs. Updating other profile fields, or submitting the same normalized address, keeps the stored email spelling. Cloud does not merge accounts or add a new database uniqueness constraint. Existing login and directory synchronization behavior is unchanged; operators can resolve old duplicates separately.

A FreeIPA account creation can still promote an existing local account. An exact stored email match takes precedence; otherwise there must be exactly one matching local account. Promotion preserves its ID and stored email spelling. Directory synchronization remains authoritative and can mirror duplicates created outside Cloud; this check applies to Cloud's account mutations.

Create users and groups

Choose New user or New group and complete one form. When FreeIPA is available, choose whether Cloud or FreeIPA manages the record. The account type starts empty, including when only one type is available. Account requests fill in the person's details and restrict the choice to FreeIPA.

For local users, choose a full or guest account and review any administrator access. The form explains the selected type and what happens after creation. FreeIPA creates a temporary password, included in the welcome email; local accounts use email links instead. If email delivery is disabled, the form explains how to give the user access yourself. For FreeIPA groups, review the POSIX option before creating the group. A normalized group name is shown when it differs from your input.

Create account or Create group saves directly. If saving fails, the form keeps your entries so you can correct them and retry. Use Cancel or the close control to leave; edited forms ask before discarding entries. Successful changes can show optional follow-up instructions configured in Administration → Accounts & sign-in → Registration & requests. An empty template adds no notice. User creation, maintenance, group changes and membership changes use the same action-dependent template. These are instructions for the administrator or group manager, not messages sent to the affected user. See Follow-up notices for supported actions and template variables.

Global account settings and lifecycle backfill controls live in Administration. The Accounts dashboard links to Operations; account records, request processing and lifecycle history stay in Accounts. Disabling new account requests does not remove existing requests from this workspace.

How Accounts fits Cloud

Accounts operates the platform identity records and group relationships used by Cloud access checks. Local records stay in Cloud. When FreeIPA is enabled, FreeIPA-backed users and groups are written through the Accounts service. Applications still own their resources and decide which permission each principal needs.

Find detailed product help

Open Help inside Accounts for users, groups, requests, service credentials, notification batches, lifecycle views, and audit filters. Developers can read Request identity, Resource authorization, Resource API keys, and FreeIPA for the adjacent platform contracts.

Inspect Accounts from the terminal

Accounts provides a native CLI module for administration and automation. Start with read commands before selecting a record for a change:

cld accounts users list --json
cld accounts groups list --json
cld accounts users linux get alice --json
cld admin linux preview --json

Run cld accounts help to see requests, audit, and service-account areas. Run cld accounts <area> <command> --help before a mutation to read its current fields and confirmation requirements.

Deployment requirements

See Deployment requirements for this app’s startup prerequisites, optional integrations, configuration and functional checks.