Adaxes is a standalone software solution that acts as a proxy between users and your Active Directory, Exchange and Office 365. It means that native tools are still in place, so, if you need, you can come back to them at any point and have direct access to your environment the same way as before.
All the Adaxes magic, such as automation rules, approval-based workflows, role-based permissions, data standards enforcements, etc. is only applied when executing operations through Adaxes. So, any of your existing scenarios or integrations, like HR or payroll systems, that directly interact with AD, Exchange or Office 365 won’t be affected and can co-exist with Adaxes.
Adaxes does not pollute your Active Directory in any way. It doesn't store any of its data in AD, doesn't change native permissions and doesn't extend Active Directory schema.
Adaxes doesn't limit you to just what's provided out-of-the-box. It allows you to easily extend and customize its built-in functionality to exactly match the specific needs of your organization.
You can easily add your own scripts to automated workflows and actions or develop your own custom clients for Adaxes. For more details see Adaxes SDK.
Adaxes allows you to set up multiple Adaxes services that share common configuration. This enables more efficient load distribution on your system and adds a redundancy layer to it. So, if one of the services goes down, users will be automatically redirected to the nearest service available.
Adaxes allows you to manage multiple Active Directory domains even if they are located in different forests and have no trust relationships between them. As a result, all automation rules, access rights, scheduled tasks, approvals, etc. can be applied across all your environment in a unified manner.
All the actions that are performed through Adaxes are executed via service accounts with appropriate access rights in each of the managed domains.
With Adaxes there are no security compromises. All communications between Adaxes service and Adaxes clients (Administration Console, Web Interface, etc.) always use an encrypted TCP channel.
All security sensitive communications between Adaxes service and Active Directory use LDAPS or Kerberos encryption. Other connected systems, such as Exchange, Office 365 and Skype for Business use encrypted channels at all times.
All security sensitive communications between Adaxes Web Interface and the user's web browser, such as passing credentials during login or resetting passwords, always use 1024-bit RSA encryption. So, they are secured even if HTTPS is not enabled.
To allow access to Adaxes Web Interface from outside your corporate network, you need to put the Web Interface in the DMZ. No other Adaxes components need to be exposed. The Web Interface also requires a Read-Only Domain Controller in the DMZ. Because the RODC doesn’t store passwords and has only one-way replication and the Web Interface doesn’t directly interact with Active Directory, any security risks are minimized.
To prevent possible attacks on your Active Directory through the Web Interface that's publicly exposed to the Internet, Adaxes provides a robust brute force protection mechanism.