Adaxes encryption and security overview

This article provides an overview of how Adaxes handles your data – from authentication, to data security in transit and at rest. It outlines what data Adaxes stores, what data it does not store, and how this data travels between Adaxes components.

Infrastructure security

As a self-hosted solution, Adaxes operates within your infrastructure, making security of the application linked to the baseline security of the domain network where Adaxes is hosted.

For example, Adaxes has no control over the following factors, but they will negatively impact Adaxes security if overlooked. The list is not exhaustive – its purpose is to highlight the areas where infrastructure security and Adaxes security most directly overlap.

• Service account security – during Adaxes installation, you specify an Active Directory account as the Adaxes service account. This account is the primary identity which has ultimate access to the entire Adaxes configuration and all data handled by Adaxes. It should be secured with a strong password and access to it should be strictly limited only to authorized principals.

• IIS security – Adaxes web components are .NET applications hosted on an IIS web server in your infrastructure. The infrastructure owner is responsible for hardening the IIS instance. For instance, installing certificates to enforce HTTPS, and managing SSL settings.

• Allowed TLS versions – Adaxes will use the highest TLS version supported by both, the web client and the web server. Allowed server-side TLS versions are controlled by Windows, on the computer where Adaxes is installed.

• LDAP signing and channel binding – Adaxes will offer to use LDAP signing during SASL binds to domain controllers, but will proceed without signing if the domain controller does not agree. Deciding on whether to enforce LDAP signing and channel binding on domain controllers is the responsibility of the infrastructure owner.

• Network exposure – securing the internal network segments where Adaxes components reside and external access to Adaxes components is the responsibility of the infrastructure owner. While inter-component communication is encrypted, standard network hardening (e.g. firewalls) should be applied. For details, see Adaxes network usage.

• OS-level hardening – applying Microsoft-recommended security hardening measures to the Windows servers hosting Adaxes, including regular Windows updates and best-practice configurations, is the responsibility of the infrastructure owner.

Data in transit

Data in transit refers to any movement of data over the network where an Adaxes component is either a sender or a recipient. The following table summarizes the typical data flows and their encryption and authentication methods.

Web client to Adaxes web server

A web client in this context is defined as a web browser or another application that communicates with an Adaxes web server over HTTP/HTTPS. An Adaxes web server is a computer within your infrastructure, where an Adaxes web component is installed.

Adaxes web components are .NET web applications hosted on Internet Information Services (IIS). They include:

• Web interface
• Web interface configurator
• SPML provider
• REST API

SSL/TLS

Adaxes web components will be accessible over an encrypted HTTPS channel only if you set up SSL on IIS where such components are hosted. Out of the box, IIS allows unencrypted connections over HTTP, and Adaxes web components will accept them unless you enforce SSL in the IIS settings. For more information about configuring SSL in IIS, refer to this article from Microsoft: How to Set Up SSL on IIS 7 or later.

Adaxes web components support all TLS versions allowed in the Windows Schannel configuration on the Adaxes web server. Adaxes will always prefer the highest available TLS version, but will accept connections from clients that support only deprecated TLS versions like 1.1. To prevent such connections, you can restrict allowed TLS versions.

RSA

Adaxes web interface encrypts sensitive data in web requests using RSA-2048, securing them even if you have not configured SSL in IIS. Some examples of sensitive data include passwords that users provide during authentication and new passwords specified when performing Reset password or Change password operations. This secondary encryption layer is enabled by default, but can be disabled if you consider it redundant after configuring SSL.

For details on how to disable it, see Configure secondary encryption.

Request signing

Adaxes web interface signs web requests on the client side, to prevent tampering in transit. The content of every request, including its body and HTTP headers, is hashed using SHA256withRSA to form the request signature. The signature is encrypted with the client's private RSA key and is sent with the request in the Adm-Signature header.

The web server calculates the hash of every received request using the same method, then decrypts the signature with the client's public key, and compares the hashes. Only requests where hashes match are executed.

You may need to disable this feature if you use third-party network security applications or reverse proxies that monitor traffic and inject their own headers, as these modifications break the signature and cause legitimate requests to fail.

For details on how to disable it, see Configure secondary encryption.

Web interface authentication

The web interface authentication flow is different for users signing in with Active Directory and Microsoft Entra accounts.

• AD account – credentials encrypted with RSA-2048 are passed to the Adaxes service, which authenticates the user against a domain controller using Kerberos or NTLM (if Kerberos fails).
• Entra account – the web interface uses the native OAuth 2.0 / OpenID Connect authentication flow for Entra users. Credentials are submitted directly to Microsoft.

Optionally, you can enable two-factor authentication for Active Directory accounts or configure the web interface to use an alternative authentication flow altogether.

REST API access tokens

Adaxes uses 128-byte access tokens to authorize REST API requests. A token must be sent in an HTTP header with every request. Token security in transit relies on HTTPS configured in IIS – if plaintext HTTP is used, the token value may be exposed to interception.

Tokens can be permanent or time-limited, with the expiration date set when a token is generated. After generation, the token value is displayed once and never stored – Adaxes retains only its SHA-256 hash, kept in secure storage. Any token can be revoked by a service administrator at any time.

For more details, see REST API overview.

Adaxes web server to Adaxes service

Adaxes web applications use a secure TCP channel to communicate with an Adaxes service. Adaxes does not use a proprietary mechanism to encrypt this traffic. Instead, it relies on the Security Support Provider Interface (SSPI) component of Windows API for encryption.

For authentication, Adaxes uses Negotiate to select the best authentication method. Kerberos is always attempted first, with a fallback to NTLM if Kerberos fails.

To use Kerberos authentication, a Service Principal Name (SPN) for the Adaxes service must be registered with Active Directory. For more details, see Disable NTLM and enforce Kerberos.

Adaxes service to Adaxes service

In multi-server Adaxes deployments, Adaxes service instances share configuration and keep their data in sync through AD LDS replication. Data encryption during replication is handled entirely by AD LDS. Adaxes does not add proprietary encryption or modify the replication mechanism in any way.

AD LDS authenticates replication partners before replication, and replication authentication always occurs over a secure channel. The Security Support Provider Interface (SSPI) is used to establish the appropriate authentication security level. Kerberos is attempted first, with a fallback to NTLM. After replication partners have successfully authenticated, all replication traffic between the two partners is encrypted.

The AD LDS replication encryption and security is not configurable from within Adaxes. If you need to review or adjust it, this should be done at the AD LDS level. For guidance on the best practices, refer to Microsoft documentation on AD LDS replication.

Adaxes service to Active Directory

Communication between Adaxes service and domain controllers in your environment follows the same protocols used for all Active Directory data exchange. Adaxes uses LDAP to read and write directory data – querying property values, modifying group memberships, creating objects, and so on. For security-sensitive operations, Adaxes automatically uses LDAP with SSL. For example, Adaxes will establish an encrypted LDAPS connection to a domain controller when resetting users' passwords, without any additional configuration.

For general LDAP traffic, the security posture is largely determined by your network infrastructure configuration – Active Directory supports a range of hardening options at the DC level, including SASL binds, LDAP signing, and channel binding. Adaxes can operate in environments where such options are enforced, but whether they are enforced or not is a decision for the infrastructure owner to make.

You can also configure Adaxes to encrypt all communication with domain controllers using SSL or Kerberos. For details, see Encrypt traffic between Adaxes and Active Directory.

Adaxes service to Entra ID

To manage Entra ID and Microsoft 365, Adaxes communicates with Microsoft cloud services through a registered Entra application. You register and configure this application yourself, granting it the permissions required for your environment. For details, see Register Adaxes as an app in Microsoft Entra ID.

Adaxes authenticates with Microsoft services using the OAuth 2.0 client credentials flow. The application presents its credentials directly to the Microsoft identity platform, which issues a time-limited access token. This token is then used to authorize requests to the Microsoft Graph API.

All communication with Microsoft Graph API is conducted over HTTPS. The TLS version is negotiated between the .NET runtime on the computer hosting the Adaxes service and Microsoft servers, which require TLS 1.2 as a minimum. TLS versions available to an Adaxes service instance are governed by the Windows Schannel configuration on that computer.

For Exchange Online operations, Adaxes uses the Exchange Online PowerShell module (EXOv3), authenticating with the same application credentials and OAuth 2.0 flow. The module is maintained by Microsoft and handles connection management and encryption internally. Its transport security follows the same HTTPS/TLS baseline as Graph API communication.

Data at rest

Data at rest refers to data that is stationary in storage at any given point in time. This section covers what Adaxes stores, where, and what it explicitly does not retain.

Configuration data in AD LDS

Adaxes stores its configuration data in the Adaxes partition of a dedicated AD LDS instance. The instance is encrypted using the Windows Data Protection API (DPAPI) – the encryption key is managed by the operating system and is bound to the security context of the Adaxes service account, which is designated as the directory service owner of this AD LDS instance. Only this account has unrestricted access to the configuration data.

The following categories of data are stored here:

• Configuration objects – all business rules, scheduled tasks, security roles, custom commands, and so on, including the configuration of their actions, conditions, and PowerShell scripts.
• Service settings – mail, SMS, logging, and other service-level settings.
• Web interface configuration – all settings of all web interface configurations.
• Custom attribute values – values of custom attributes (e.g. adm-CustomAttributeText1). Each value is stored alongside the GUID of the directory object it belongs to. The directory object itself is not stored.
• Entra ID object cache – property values of users, groups, and resource mailboxes from managed Entra domains. Adaxes caches Entra objects to operate within Graph API rate limits and avoid throttling.
• Adaxes metadata – internal identifiers linking on-premises accounts to their cloud counterparts, Exchange recipient types, and similar metadata.

Secure storage

Credentials and other sensitive values are stored in a dedicated Secure Storage container of the Adaxes partition in AD LDS. Data in this container is encrypted with an AES-256 master key, which is itself encrypted using RSA-2048. The private RSA key required to decrypt the master key is stored locally on the Adaxes service machine, encrypted with DPAPI and accessible only by the Adaxes service account. All encryption keys are automatically rotated every 14 days.

The following sensitive data is stored in secure storage:

• Managed domain credentials – credentials used by Adaxes to connect to and manage Active Directory domains.
• Entra application credentials – credentials for Entra applications used to manage Entra domains and Microsoft 365 tenants.
• Run As credentials – credentials specified in the Run As section of Run a program or PowerShell script actions and If PowerShell script returns true conditions.
• External logging database credentials – credentials for connecting to an external MS SQL logging database.
• REST API access tokens – access tokens for REST API.
• Private RSA key for offline password self-service – for more details, see the Self-service client installation guide.

SQLite logging database

Out of the box, Adaxes writes log records to an SQLite database installed alongside the Adaxes service and located at <InstallLocation>\Service\LogDB.

The database is a file on the local hard drive and is not encrypted, which is consistent with how SQLite operates by default. Its security relies entirely on OS-level access controls.

If encrypted log storage is a requirement, you can configure Adaxes to write log records to an external MS SQL database instead, and apply encryption at the database level. For instructions on switching to an external logging database, see Enable logging to an external MS SQL database.

See also

• Adaxes installation guide
• Self-service client installation guide
• Add/remove service administrators
• Configure Adaxes to use specific domain controllers
• Encrypt traffic between Adaxes and Active Directory
• Configure secondary encryption in web interface