0 votes

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".

image.png

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.

by (960 points)
0

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?

0

Not on DC, just ordinary server joined to this domain

1 Answer

–1 vote
by (287k points)

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.

0

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

0

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.

0

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.

0

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.

0

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 image.png

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

0

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.

0

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) image.png during the installation wizard, and administrators group (or the local account that I used for connecting to this machine) image.png 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 image.png image.png

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

0

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.

0

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 :)

0

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.

Related questions

0 votes
0 answers

Hello, The installation of the Adaxes software fails on my network. I have tried the installation on Multiple member servers. All the servers are Windows 2008 R2. The domain ... the software using a service account (domain admin). Both didn't work. Ronnie

asked Oct 25, 2012 by ronnie (20 points)
0 votes
1 answer

I connected my local AD domain as well as my Entra domain in Adaxes, however I am now seeing duplicate user accounts, one under our local AD and the other from ... Connect, and it's confusing determining which user is in which location when making updates.

asked Sep 4 by aswint (50 points)
0 votes
1 answer

Our Adaxes Microsoft 365 Tenant was created before we copmpleted the "app registration" in Azure. Which means that in the instructions for "Register Adaxes as an app in ... M365 tenant, would that affect any of our custom commands that we have created?

asked Feb 17, 2022 by Tfarmer (160 points)
0 votes
1 answer

This note is found in the documentation on how to configure allowed domains in Adaxes 2023. Allowed domain names can only be selected from the alternative UPN suffixes for on- ... required to pick up the change, or is there another way to trigger the update?

asked Jan 31, 2023 by dtb147 (290 points)
0 votes
1 answer

In order to add a managed domain does it have to be trusted by the primary domain adaxes is installed an running in? I have set up a domain for testing adaxes and it ... I have set my host file to point the untrusted domain to it's primary Domain Controller.

asked Oct 5, 2022 by mightycabal (1.0k points)
3,533 questions
3,224 answers
8,216 comments
547,690 users