Adaxes installation fails in Microsoft Entra Domain Services

Question

During installation of the Adaxes in new testing domain hosted in Azure Microsoft Entra Domain Services this error was thrown "Failed to create application partitions on the backend server. The user name or password is incorrect".

Username and password are correct (tested), used user service account is member of the administrators group on this computer and is member of "AAD DC Administrators" group which should be same as "Domain admins" in ordinary AD.

Not sure if this is related to the fact this is not ordinary AD, but Azure hosted.

Comments

Hello,

The fact that it is in Azure Microsoft Entra Domain Services should not influence the installation. Do we understand correctly that you are performing the installation on a domain controller?

---

Not on DC, just ordinary server joined to this domain

Answer 1

Hello,

Thank you for specifying. Most probably, there are some ports used by Adaxes that are not open. For details on the ports, have a look at the following FAQ article: https://www.adaxes.com/questions/20/what-ports-does-adaxes-use.

Comments

Have checked this and all required ports are open on both DCs

---

Hello,

According to the screenshots, you did not check all the ports mentioned in the article. Also, it is a two-way thing to check. Lastly, not only firewall can block the connection, but something else (e.g. protection software) in your environment.

---

Yes I have, because I don;t care about Exchange right now. Only thing missing are dynamic ports which I am unsure about how to test.

Local firewall was turned off.

There is nothing else installed, it is fresh VM with no AV program. Moreover connection was able to establish, so the problem will be in something else.

---

Hello,

First of all, pay attention that the 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.

At the same time, there can be nothing but something in your environment blocking the authentication. It is performed by Windows functionality on the AD side. Adaxes only calls the corresponding functions, nothing more.

---

Sure I know. ANyway the issue isnt at all on the network side.

Through Procmon and Process explorer I found out, that adaxes.msi calls "C:\Windows\ADAM\adaminstall.exe" which is AD Lightweight Directory services installer with answer file that contains this settings:

[ADAMInstall] InstallType=Unique ShowOrHideProgressGUI=Hide InstanceName=AdaxesBackend LocalLDAPPortToListenOn=65279 LocalSSLPortToListenOn=1216 AddPermissionsToServiceAccount=Yes Administrator=AADDS\AADDS_AdaxesSvc ShowInAddRemovePrograms=Hide

So I've called the adaminstall.exe like start-process "C:\Windows\ADAM\adaminstall.exe" -ArgumentList "/answer:C:\Temp\adamanswers.txt" and it got installed, because now when I try to run the installation again I end up with different error

The adaxes.msi and adaminstall.exe are being both called from the same administrator console running under account that will be at the same time used as adaxes service account. So this isn't permission issue either (otherwise leightweight service would install).

So a) I need to forece adaxes installer to use this existing database b) fix the installer issue somehow

---

Hello,

That is not quite right. Your command only crated an AD LDS instance, nothing more. As such, it does not require any authentication in AD. It just uses the credentials you signed in to the computer with and that is it. It is not even requesting anything from AD. At the same time, the Adaxes installer fills the AD LDS instance being created and that is where authentication to AD is required and something in your environment blocks it. You can try viewing Windows event logs for related errors/warnings.

It is not possible to make Adaxes installer to use the AD LDS instance you created manually. You need to delete it and fix the authentication issue before trying to install Adaxes again.

---

I don't think this issue is related to network at all. Because the error is related to creating local database application partition.

I have tried to install the AD LDS (via adaminstall.exe) via "AADDS_AdaxesSvc" domain account. Which is the same I am trying to use when installing Adaxes. As stated before, this account is like global admin and is also in the administrators group on this PC.

If the AADDS_AdaxesSvc account was used just for performing operations (as can be seen on the screenshot) during the installation wizard, and administrators group (or the local account that I used for connecting to this machine) was being granted administrator rights for created LDS instance everything worked as expected.

But when AADDS_AdaxesSvc was selected as LDS instance administrator account, same error as when installing via Adaxes was thrown when trying to import some LDIF files

So the outcom for me is that somehow the domain account AADDS_AdaxesSvc cannot be used as LDS instance administrator in this case.

---

Hello,

That is exactly want we meant when referencing authentication. It might not be the network itself, but there is just something presenting the account from authenticating. It is obvious that the credentials themselves are correct as you were able to pass the corresponding step when installing Adaxes. The only thing we can state is that the issue is not related to Adaxes and your findings just prove it. Unfortunately, there are no troubleshooting steps we might suggest as we were not able to find corresponding documentation. However, as we mentioned in the previous post, you can try viewing Windows event logs for related errors/warnings. Maybe, there will be some additional information.

---

OK I've found the solution.

You can't use user domain account synchronized from your Azure to run Adaxes service. It must be manually created domain user account (in some other OU than "AADDC Users". To this account you also have to assign permission to create child object over computer account where Adaxes service will be run (as manual says).

So this issue was related to Microsoft Entra Domain Services after all :)

---

Hello,

Thank you for the provided details. They are very useful and interesting. Will definitely be helpful for others. We will also add that to our internal support documentation.