> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Users

> How to create and manage users and their access in CData Arc.

The first time you launch CData Arc, you are prompted to create the first application user by setting a username and password. The first user defaults to the [Admin role](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/user-roles.md#admin-role).

To create and manage additional users, navigate to the [Settings page](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/settings-page.md), then the **Users** tab. This tab includes a table of all users, and includes information about their roles, their user type and status, whether they are temporary users, their [two-factor authentication (2FA)](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/2fa.md) status, and more.

![Users table](https://mintcdn.com/cdata-arc/JuVWSaGlKX7avH_C/26.4/images/users_table_264.png?fit=max\&auto=format\&n=JuVWSaGlKX7avH_C\&q=85\&s=060c615c92d171a1fcc8d9839329e271)

Members of the Admin role can create, delete, and modify users on this tab. Admin is the only role with permission to manage other users.

## Add or Edit Users

To add a user, click **Add User**. To edit an existing user, hover over their row in the table, click the ellipses, then choose **Edit**.

Complete the following fields:

| Field | Description |
| - | - |
| **User Type** | Choose the type of user account: **Standard**, **SSO**, **Active Directory**, **LDAP**, or **Service**. The selected type determines which other fields appear in the form. The available types depend on your license tier. See [User Types](#user-types) for details. |
| **Username** | Enter a username. This field cannot be changed once you save the user. For **Active Directory** accounts, use the `domain\username` format. |
| **Temporary Account** | If the user should only have temporary access, check this and supply an **Expiration Date**. |
| **Email Address** | Best practice is to provide an email address for each user so that they can [reset their passwords](#password-resets) when necessary. |
| **Roles** | Select the [user roles](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/user-roles.md) to assign the user. |
| **Password** | Enter a password. Ensure that it meets the requirements in [Sign In Settings](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/sign-in-settings.md). The **Password** field appears only for Standard accounts and for SSO accounts with the Admin role. Check **Require password reset on next sign in** to force the user to change their password on login. This checkbox is also available for SSO accounts with the Admin role, which keep a local password. |
| **Status** | Indicate whether the user is active or inactive. |
| **Federation Id** | For **SSO** accounts, enter the value from your identity provider (IdP) that maps the SSO identity claim to this Arc user account. This field always appears for SSO accounts regardless of whether SSO is globally enabled. For more information, see [Single Sign-On](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/single-sign-on.md). |

To give the new user [Admin API](#admin-api-access) and/or OAuth access, click the **API Access** tab.

![Provide Admin or OAuth access](https://mintcdn.com/cdata-arc/pXe_oAwLTI7MI6MK/26.4/images/add_user_api_access.png?fit=max\&auto=format\&n=pXe_oAwLTI7MI6MK\&q=85\&s=d871e0cab8a00327b922e0b3292800a4)

| Field | Description |
| - | - |
| **API Access** | Check **Enable Authtoken Access** to grant the user an authtoken that can be used to access the Admin API. See [Admin API Access](#admin-api-access) for details. When you enable API access, the rest of the fields in this table appear. |
| **Token Expiration (days)** | The number of days before the token expires. Check **No Expiration** if you do not want the token to expire. |
| **Authtoken** | The system-generated authtoken. Make sure to copy it to a safe location before saving the user, because it is not shown again. |
| **Maximum Requests per Hour** | Uncheck **Unlimited Requests** to set a limit on the maximum requests per hour for this user. |
| **Maximum Concurrent Requests** | Uncheck **Unlimited Requests** to set a limit on the maximum number of requests that can be sent simultaneously. |
| **Enable OAuth Access** | Check **Enable OAuth Access** to grant the user credentials that can be used to secure public API endpoints for the [Admin API](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/admin-api-settings.md). OAuth 2.0 provides a structured authentication flow for clients that need to manage token lifecycles or integrate with external applications. When you enable OAuth access, the following fields appear: |
| **Grant Type** | The OAuth 2.0 grant type that determines how the client application obtains an access token. **Client Credentials** is currently the only option. |
| **Client Id** | The system-generated client Id token. |
| **Client Secret** | The system-generated client secret. Make sure to copy it to a safe location before saving the user, because it is not shown again. |
| **Access URL** | The endpoint URL used by the client application to request an access token using the configured credentials. |

To add trusted or banned IP ranges specific to this user, click the **Trusted IP Ranges** or **Banned IP Ranges** tabs to add the ranges. You can provide single IP addresses, simple ranges (such as `203.0.113.*` or `203.0.113.1-255`), or Classless Inter-Domain Routing (CIDR) ranges. These tabs also display the global trusted and banned ranges that have been defined on the [Network Access](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/network-access.md) portion of the **Settings > Security** page.

## User Types

Arc supports the following user types:

* **Standard** accounts are for people who sign in to the Arc console interactively with a username and password.
* **SSO** accounts are for people who authenticate through an external identity provider (IdP). The **Password** field is hidden for SSO accounts that do not have the Admin role. SSO accounts with the Admin role retain a local password as a fallback for signing in when SSO is unavailable. The **Federation Id** field is always shown for SSO accounts and is used to map the identity claim from the IdP to this Arc user account. Because authentication happens at the IdP, Arc 2FA does not apply to SSO accounts, so the 2FA controls are not shown. For more information on configuring SSO, see [Single Sign-On](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/single-sign-on.md).
* **Active Directory** accounts are for people who authenticate using a Windows domain account. Usernames must be in `domain\username` format. Active Directory is only available on the [.NET edition](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/installation/windows-edition.md).
* **LDAP** accounts are for people who authenticate using an LDAP directory service. LDAP is only available on the [Cross-Platform edition](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/installation/cross-platform-edition.md).
* **Service** accounts are for automated, machine-to-machine access, such as invoking [Flow API](https://docs.arc.cdata.com/26.4/self-hosted/en/flows/flow-api.md) endpoints or calling the [Admin API](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/admin-api-settings.md). Service accounts do not sign in interactively, so the **Password** field and 2FA controls are not shown; instead, they authenticate only with an authtoken or OAuth client credentials configured on the **API Access** tab. Service accounts require at least one authentication method configured on the **API Access** tab (either **Enable Authtoken Access** or **Enable OAuth Access**). If neither is enabled, the form displays a warning and blocks saving. For example, you might pair a service account with a role that grants only the [Flow API **Invoke** permission](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/user-roles.md#flow-api-configuration) to let it call specific endpoints without any access to, or visibility into, the Arc UI.

> [!NOTE]
>
> When SSO is globally enabled, the **Federation Id** field also appears for Standard accounts. This supports Standard accounts that have a Federation Id but were not migrated to the SSO type, such as Admin accounts that keep a local password as a fallback.

The available user types depend on your license tier:

| License Tier | Available User Types |
| - | - |
| Enterprise | Standard, SSO, Active Directory, LDAP, Service |
| Professional | Standard, Service |
| Standard | Standard |

## Single Sign-On

Arc supports single sign-on (SSO) via identity providers that implement the OpenID standard. For more information, including specific guidance for Azure AD, see [Single Sign-On](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/single-sign-on.md).

## Admin API Access

Each user is granted an authtoken that can be used to access the [Admin API](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/admin-api-settings.md). For more information on authenticating against the Admin API, see [Admin API Authentication](https://docs.arc.cdata.com/26.4/self-hosted/en/admin-api/admin-api-authentication.md).

The specific actions that a user can perform using the Admin API mirror the actions that the same user can perform using the UI. For example, a user that cannot delete connectors in the UI cannot use the Admin API to delete connectors. To perform any action using the Admin API, use an authtoken from an Admin user when invoking the API.

## Password Resets

Every user can have an email address associated with their account. This way, if they need to reset their password, they can click the **Forgot password** link to have a reset link emailed to them. Every password reset that is sent adds a row to the [application log](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/activity.md#application-logs).

Users who do not have an email associated with their account must contact an administrator to have their password reset, so it is best practice for administrators to associate an email with each user account.

If all admin users are locked out of Arc, the embedded web servers in each edition provide the ability to reset their password to regain access to the application. This requires administrative access to the installation, and should only be used if there is no user with access available.

For example, in the [Cross-Platform edition](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/installation/cross-platform-edition.md):

```
java -jar arc.jar -ResetPassword -User <user> -Password <password> -AppDirectory <appDirectory>
```

In the [.NET edition](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/installation/windows-edition.md):

```
CData.Arc.exe -ResetPassword -User <user> -Password <password> -AppDirectory <appDirectory>
```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.