Here you can find the answers to frequently asked questions about Adaxes.
Softerra Adaxes does not extend the AD schema. Moreover, Softerra Adaxes does not store its data in Active Directory and doesn't modify the native permissions assigned in AD. If you uninstall Softerra Adaxes, you can use Active Directory just you did before the product installation.
In Adaxes, permissions are granted via Security Roles. To view the Security Roles that grant permissions to a user:
By default, SSL is not configured for the Adaxes Web Interface and network transmissions are not encrypted. However, you can configure SSL on the Adaxes Web Interface the way you do it for any other website hosted by IIS. If you configure SSL on the Adaxes Web Interface, it will work in both cases: with Windows-integrated authentication and with forms-based authentication.
Softerra Adaxes is licensed in packages based on the number of enabled and not expired user accounts in your AD domain(s). To check the number of enabled and not expired user accounts in all managed Active Directory domains:
Launch Adaxes Administration Console.
In the Licensing section, the total number of all enabled and not expired user accounts in managed AD domains is displayed.
Once you've purchased a license for Softerra Adaxes, all you need to do is activate your license key. No need to reinstall or reconfigure the product. After that you can continue using Adaxes just as you did during the evaluation period.
Adaxes service uses the LDAP protocol to communicate with Active Directory. Interaction between the Adaxes service and Active Directory is secured for security-sensitive operations only. For example, prior to change or reset a password for an AD user, an SSL connection is established and the data are sent via an encrypted channel.
Interaction between Adaxes clients and Adaxes services is always performed using an encrypted TCP channel.
You can search for objects in all the Active Directory domains managed by Adaxes. Just select Everywhere in the Look in drop-down menu when performing a search.
All operations performed via Adaxes service are logged in the Service Log. You can view the log using Adaxes Administration Console.
To find the initiator of an operation:
Use the built-in Empty Groups and Empty OUs reports:
Adaxes itself doesn't store the password for the Adaxes service account. Adaxes service is installed as a Windows system service that runs under the Adaxes service account. The logon information for this system service is specified during Adaxes installation and is stored by Windows.
Credentials for managed AD domains are encrypted using the Data Protection API (DPAPI) provided by the Windows operating system. These encrypted credentials are stored locally on the computer where the Adaxes service runs and associated with the Adaxes service account, which means that only processes running under this account can unprotect the data.
To check for pending approval requests using Adaxes Administration Console:
To check for pending approval requests using Adaxes Web Interface:
During installation of the second instance of Adaxes service, join it to the configuration set:
For more details, see Multi-Server Deployment for High Availability.
In Adaxes, permissions are granted via Security Roles. To view the Security Roles that grant permissions on an object:
Using Property Pages
Using the Add/Modify Property wizard
You need to grant users the permissions to modify properties of their own account and add fields for the properties to the corresponding form in Adaxes Web Interface. For details, see Allow Users to Modify Specific Properties of Their Accounts.
To automate user deprovisioning, you can use the built-in Custom Command Deprovision. For information on how to configure this Custom Command, see tutorial Configure User Deprovisioning.
Also, to deprovision user accounts automatically, you can use other automation facilities provided by Adaxes, such as Scheduled Tasks. For detailed description on how to use Scheduled Tasks for user deprovisioning, see tutorial Automatically Deprovision Inactive AD Users.
You do not need to create a trust between AD domains to manage them with an Adaxes service. When registering an AD domain, an account with administrative permissions is specified. All operations performed via the Adaxes service in this AD domain are executed using this account. To control the user access to the managed resources, the Adaxes service uses Security Roles.
To enable communication between Adaxes service and Active Directory, the following ports (TCP and UDP) must be open for outgoing connections on the computer where your Adaxes service is installed, and for incoming connections on the Domain Controller(s) that you want Adaxes to connect to.
Also, you need to allow Adaxes service to ping Active Directory domain controllers. To do this, enable Echo ICMP Requests (ping) in the firewall settings.
Adaxes Web Interface and Adaxes Administration Console use the following ports (TCP and UDP):
It is possible to change the port used for communication between Adaxes service and Adaxes clients (Web Interface and Administration console). For this purpose you need to change the port attribute of the following XML element of the Adaxes service configuration file (Softerra.Adaxes.Service.exe.Config):
<customErrors mode="Off" />
<channel ref="tcp" port="54782" priority="2" secure="true">
The Softerra.Adaxes.Service.exe.Config file is located in the folder where the Adaxes Service is installed (by default, C:\Program Files\Softerra\Adaxes 3\Service).
* To enable communication through dynamic RPC ports:
To upgrade to a new version and keep all configuration settings, you need to backup the current configuration, re-install Adaxes and then restore the configuration.
For details, see Upgrade to New Version.
Sometimes, if an Adaxes service was not uninstalled properly, Adaxes Administration Console shows the removed instance in the list of available Adaxes services.
The easiest way to clear the registration information is to install Adaxes service on the same computer again, register all the AD domains, and uninstall the service. If you cannot do this, read the rest of this article.
Information about available Adaxes services is stored in Active Directory. To publish the information, Adaxes uses Service Connection Points (SCPs). To clear the registration information, you need to delete appropriate Service Connection Point entries in Active Directory:
In the Console Tree, expand the node of your Adaxes service, right-click Active Directory, and then select Find.
Click Find Now. Adaxes will search for all the SCPs of Adaxes services in all managed Active Directory domains:
By default, the language of Self-Password Reset screen is selected based on the original locale that was specified when installing Windows. To change it, you need to update the configuration of Internet Explorer.
Right-click the Internet Explorer key, select New and click Key.
If Internet Explorer key is missing you will need to create it manually:
- Right-click the Microsoft key, select New and click Key.
- Type Internet Explorer and press Enter.
If you want to configure the language administratively for multiple computers in your AD environment, you can do that via Group Policies.
Run the Microsoft Management Console:
In the Group Policy Management console, navigate to the OU with the target computers and right-click it.
- or -
Right-click the domain if you want to apply the settings to the whole domain.
Specify the following settings:
Specify the following settings:
Specify the following settings:
The settings will be applied to computers within the GPO scope as soon as they refresh group policies applied to them.