For the complete documentation index, see llms.txt. This page is also available as Markdown.

User Management

User management covers how administrators create and manage user accounts in 1Kosmos from initial setup and role assignment to onboarding, device management, and session control.


Adding a user to directory

Users are created within a specific user directory in AdminX. Select the appropriate directory before creating the account, then click Create New User and fill in the following:

Account Information

Field
Description

Username

Unique identifier for the account.

Role

Basic User, Community Administrator, or Helpdesk Administrator.

Status

Active or Disabled. Disabled accounts cannot log in.

  • User Information — First name (required), middle name (optional), last name (required).

  • Contact Information — Primary email (required), secondary email (optional fallback), and phone number for OTP delivery. Include the country code.

  • Send Invitation To — Choose whether the onboarding invite goes to the primary email, secondary email, phone number, or not at all.


Managing User Profiles

Once created, a user's status is Not Invited. From the Actions menu (...) next to any user, administrators can:

  • Invite User for Passwordless — sends the onboarding invite so the user can set up passwordless login

  • View Profile — review profile details including name, email, and linked devices

  • Edit Profile — update editable fields; not all fields can be changed after creation

  • Lock User — suspend the account either indefinitely or until a specified date/time; locked users cannot authenticate


Roles

Every user must be assigned one of the following roles:

Basic User

The default role. Users can view their own profile, manage their devices, enroll identity documents, and accept invites.

Helpdesk Administrator

Designed for support staff. Helpdesk Administrators can view reports, logs, SAML/OIDC app information, and profile details across all accounts. With the appropriate permissions, they can also unlink devices and generate onboarding invites on behalf of users.

Community Administrator

The highest privilege level. Community Administrators have full control over AdminX — including IdP configuration, authentication settings, user directories, SAML/OIDC apps, reports, and all other platform settings. They can also edit profiles, remove devices, and send invites across all accounts.


Username Aliases

Community Administrators can associate up to eight alternate usernames (aliases) to a user's account. Aliases are surfaced as SAML claim attributes and let users log in without their primary username.

Aliases are supported on the login page (username tab) for AdminX, Linux/Mac/Windows Credential Providers, Radius Applications, and Step-up OIDC.

To add aliases, go to the user's Profile Information page and click Manage Username Aliases. Enter up to eight alias names and save. Aliases must be unique across the community.

Using Aliases Across Authentication Methods

Radius Applications — Enter the alias instead of the primary username when authenticating via password, IVR, push notification, or OTP. The alias used is visible in Event Logs after authentication.

Credential Provider (V2) — The V2 CP uses adaptive authentication journeys. Aliases work with Password, Push, OTP, and FIDO methods.

If no adaptive auth journey is configured, the CP defaults to: Password, OTP, FIDO, Password + OTP, Password + FIDO, and OTP + FIDO. Windows CP with OTP requires a password regardless of whether an alias is used.

For RDP, enter the alias in the username field of the Remote Desktop Connection and authenticate with the configured method. CP must be installed on the host machine.

For Linux SSH, password authentication with aliases is not supported when the directory is not linked. If password is one of multiple configured methods, it won't appear as an option. If it's the only method configured, access will be denied.

SAML/OIDC — Set the alias as the NameID attribute during SAML or OIDC configuration. The id_token will reflect the alias used. If no alias is set and no default claim value is configured, authentication fails.


Managing Devices

Unlinking a device — Community and Helpdesk Administrators can unlink a device from a user's account (for example, when a device is lost or the user is offboarded) from the user's Devices tab. Helpdesk Administrators need the user.unlink.device permission for the Delete option to appear.

Generating an onboarding invite — Administrators can generate a QR code to onboard a device on behalf of a user when they're physically present. Go to the user's Devices tab, click ..., and select Generate Onboarding Invite.

Helpdesk Administrators need the following permissions: user.generate.qr, users.all-users, users.view-user, and users.edit.

The E_ACCESSCODE_GENERATED event is triggered for each invite generated. The purpose field indicates how it was initiated:

Scenario
Access Code Type
Purpose

User self-creates a new account

Verification_link

account_creation

User self-invites from the login screen

User_invitation

device_onboarding_from_request_invite

User self-invites from My Profile

User_invitation

device_onboarding_my_profile

User onboards via QR from My Profile

User_invitation

device_onboarding_my_profile

Admin generates onboarding invite via QR

User_invitation

device_onboarding_by_admin_via_qr

Admin onboards user by sending an invite

User_invitation

device_onboarding_by_admin_via_email


Terminating Active Sessions

Community Administrators with the user.revoke-sessions permission can terminate active sessions for any user — useful during password resets, offboarding, or potential security incidents.

  • Terminating another user's sessions — Go to the user's profile, click ..., and select Revoke Active Sessions. The user is immediately signed out of all devices.

  • Terminating your own other sessions — From the profile icon in the top-right corner, select Logout all other sessions. All sessions except the current one are terminated.

An E_SESSIONS_TERMINATED audit event is triggered on every session revocation.

Last updated

Was this helpful?