Permissions required by Adaxes

Adaxes distinguishes between three types of service accounts that fulfill different roles:

  • Adaxes service account – to run the Softerra Adaxes Service Windows service.

  • Managed domain service account – to perform operations in a managed domain.

  • Microsoft Entra application account – to perform operations in a Microsoft Entra domain and tenant.

The minimum level of permissions required by these service accounts is totally different.

Adaxes service account

The Adaxes service account is the account you specify during the installation. It only requires the permissions that enable it to run the Adaxes service.

  • Native AD permissions to create/delete service connection points – to make Adaxes service discovery possible. For details, see How do I grant permissions to publish Adaxes service.

  • The right to Log on as a service on the computer where Adaxes service is installed. Normally, this right will be granted to the service account during the installation, but it might become revoked later by a domain-based Group Policy that denies it. If you have such a policy, you need to explicitly grant this right to the Adaxes service account. For details, see How do I grant Log on as a service right.

  • The right to Access this computer from the network on the computer where Adaxes service is installed. Normally, this right should already be granted to Everyone or Authenticated Users. If it isn't, you need to explicitly grant it to the Adaxes service account. For details, see How do I grant Access this computer from the network right.

Managed domain service account

A managed domain service account is used by Adaxes to perform all operations in an Active Directory domain. For example, creating users, updating their properties, adding group members, and so on.

You can choose between two options for the managed domain service account:

  • Use the Adaxes service account

    This option is considered best practice and should be your first choice. It minimizes the number of service accounts in your environment.

  • Use a separate account

    It is recommended to use this option only if strictly necessary. For example, to manage a second domain from another forest.

For information on how to view and change the current service account for a managed domain, see Change service account for a managed domain.

The managed domain service account must have the native AD permissions for all the operations you intend to perform via Adaxes. In addition, if you have on-premises Exchange, this account also must have the appropriate permissions in your on-premises Exchange organization.

Active directory permissions

Adaxes can perform practically any operation in Active Directory. For this reason, making a managed domain service account a member of the Domain Admins group is the simplest and fastest solution to grant it all the required permissions.

If you do not wish to add the service account to Domain Admins, you can delegate the permissions granularly, e.g. using the Delegation of Control wizard in Active Directory Users and Computers. The minimum level of required AD permissions is unique for every organization. For example, if you will use Adaxes only to create/edit/delete users and reset their passwords, these are the only native AD permissions that the managed domain service account must have. If these users are located in a specific OU or container, the permissions can be delegated only over this OU or container.

Here is a sample table of typical operations in Adaxes and the corresponding permissions in the Delegation of Control wizard.

  • Operation

  • Permission

  • View user accounts and their properties

  • Read all user information

  • Create user accounts

  • Create, delete, and manage user accounts

  • Modify user account properties

  • Create, delete, and manage user accounts

  • Add/remove group members

  • Modify the membership of a group

Exchange permissions

It is recommended to add the managed domain service account to the Organization Management role group in Exchange. It provides administrative access to an entire Exchange organization and grants the rights to perform almost any task.

If, for some reason, you do not want to grant the account administrative access to your Exchange organization, you need to assign the account to the following role groups in Exchange:

  • View-Only Organization Management – to be able to read Exchange configuration.
  • Recipient Management – to be able to create and manage Exchange recipients (except the Unified Messaging feature).
  • UM Management – to be able to manage the Unified Messaging feature.

Microsoft Entra application account

Microsoft Entra domains are managed using an application account. For more details about how to register Adaxes as an app in Microsoft Entra ID and what permissions this app requires, see Register Adaxes as an app in Microsoft Entra ID.