> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/authentication/admin-portal/user-management.md). # User Management *** #### 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. {% hint style="warning" %} Aliases are **not** supported in QR code flows, Reset Password, Forgot Password, or any other recovery flows. {% endhint %} 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. {% hint style="warning" %} The adaptive auth journey for CP must be configured in the database, not through AdminX. Configuring it in AdminX overrides existing database settings. {% endhint %} 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. {% hint style="info" %} 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. {% endhint %} **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`. {% hint style="warning" %} The QR code expires in **2 minutes**. If not scanned in time, it must be regenerated. {% endhint %} 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. {% hint style="info" %} An **E\_SESSIONS\_TERMINATED** audit event is triggered on every session revocation. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.1kosmos.com/authentication/admin-portal/user-management.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.