Permissions required by Adaxes

Adaxes distinguishes between three types of service accounts that fulfill different roles – Adaxes service account, managed domain service account, and Azure application account. 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 is used to run the Softerra Adaxes Service Windows service. It only needs the permissions to create/delete service connection points to make Adaxes service discovery possible. Any other native AD permissions are not required.

Managed domain service account

A managed domain service account is used by Adaxes to perform all operations in an on-premises Active Directory domain. For example, creating users, updating their properties, etc.

When you first install Adaxes, the domain where you install it is automatically managed using the credentials of the Adaxes service account. It is a good practice to use the same account to run the Adaxes service and to manage your domain – to minimize the number of service accounts in your environment. However, if you register another domain from a different forest, you will need to use a separate account to manage it.

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.

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.

Azure AD application account

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

---