Self Service login is failing with bad username or password for secondary domain

Question

We have multiple secondary domains that are being managed by Adaxes. Everything seems to be working except self service portal login. We tested with our other secondary domains and those work. I don't see any errors other than sign failed. What else can I look at to figure this out?

Comments

Hello,

Please, post here or send us (support[at]adaxes.com) a screenshot of the error.

Also, for troubleshooting purposes, you can enable tracing of Web Interface requests and send us the output file. To do so:

1. Navigate to the folder where Adaxes Web Interface is installed. By default, the folder is C:\Program Files\Softerra\Adaxes 3\Web Interface.
2. Open the App folder.
3. Open the Web.config file with a text editor.
4. Locate the configuration\adaxes.web.ui\trace XML element.
5. Set the enabled attribute to TRUE.
6. Specify the path to the file in the filePath attribute.

<adaxes.web.ui adaxesConfigurationSetId="">
   <trace enabled="true" filePath="C:\logs\adaxes.webui.trace.txt" data-tomark-pass />
</adaxes.web.ui>

7. Save the file.
8. Reproduce the issue and send us the log file.

---

Here is the error:

I will turn on the tracing and get you that result shortly.

---

I uploaded the zip to the ftp site you sent. For some reason, I can't respond to the private message.

Answer 1

Hello Mark,

Thank you for the provided details. The "Unknown username, bad password or you are not allowed to log in" message appears when the When a login error occurs, do not show the reason and the number of login attempts left (checked) option is selected in the Sign In settings for the Web Interface. For details, see https://www.adaxes.com/tutorials_WebInterfaceCustomization_PreventBruteForceAttacks.htm. Please, disable the option and check whether the issue persists. If you get a different error message, please, post here or send us a screenshot.

Comments

This is the error we get now.

The trace log just says the same thing.

I tested that I can edit properties on the domain through adaxes and save them successfully.

---

Hello Mark,

Thank you for the provided details. For further troubleshooting, please, specify the following:

• Does the issue persist from the very beginning of the domain registration in Adaxes or started to occur recently? If latter is the case, please, specify what updates were performed in your network environment around the time when the issue occurred first.
• How many instances of Adaxes service run in your environment? Do they share common configuration? For information on how to check it, please, take a look at the following help article: https://www.adaxes.com/help/?HowDoI.ManageService.MultiServerEnvironment.html.
• On how many computers is the Web Interface installed? Are the Web Interfaces and Adaxes services installed on the same computer(s)?
• Are there instances of Adaxes Service and/or Adaxes Web Interface in the secondary domain?

---

I am sorry for the delay. I got caught up in my other support ticket and forgot about this one.

• The issue seems to have started recently. I know it worked when first put in place. We have upgraded Adaxes but not sure of other changes. What is the flow of authentication? Could a firewall be blocking it? We have firewalls in between our domains.
• We have 4 instances of the service
• We have 6 with the Web Interface installed. 4 have the full Adaxes install and 2 have just the Web Interface.
• There are no instances of the Service or Web Interface in the other domain.

---

Hello Mark,

Thank you for the provided details.

What is the flow of authentication?

After the logon form of a Web Interface is submitted, the Web Interface sends authentication request to a domain controller (DC). If the authentication is successful, Adaxes checks Access Control of the Web Interface. If the user is allowed to sign in, Adaxes checks whether MFA is enabled for the Web Interface and if it is, the user gets prompted for the security code or application configuration. When all the conditions are fulfilled, the user gets logged on to the Web Interface.

Could a firewall be blocking it?

A firewall could block access to a DC, but it would cause another error.

For further troubleshooting, please, clarify the following:

• Are the instances of Adaxes Web Interface placed behind a load balancer? If they are, please, check whether the SSL offload is enabled on the load balancer.

• Does the issue persist with all the instances of Adaxes Web Interface? To check access to a specific instance, you can specify fully-qualified domain name (FQDN) of the instance server in the URL which you use to access Adaxes Web Interface. The URL should be like the following:

  http://server.domain.com/Adaxes

  where server.domain.com is FQDN of the server where the instance of Adaxes Web Interface is installed.

---

Yes, they are behind a load balancer. The load balancer is doing the ssl termination.

I tried on each instance and got the same error of bad username or password.

---

Hello Mark,

Thank you for the provided details. Please, disable SSL offload on the load balancer and check whether the issue persists.

---

SSL is now being terminated on the servers and not the load balancer. Same error as before.

---

Hello Mark,

Could you, please, clarify the configuration of the load balancer and servers related to SSL? Does the issue persist when accessing the Web Interface without the load balancer amid?

Also, please, disable the When a login error occurs, do not show the reason and the number of login attempts left option in the Sign In settings for the Common Sign In page and check whether the error message the same as before. If you get a different error message, please, post here or send us (support[at]adaxes.com) a screenshot.

Does the error occur when accessing the Self-Service Web Interface by a direct URL (e.g. http://server.domain.com/Adaxes/SelfService)?

---

• If I access the web interface on the servers directly, the issue is there.
• If I access through the LB, the issue is there.
• As requested, we are now terminating SSL traffic on the individual servers and the LB is just managing which server to send the TCP traffic to.
• Same error if I go directly to the Self-Service Web Interface url.
• Screenshot below of the error:

---

Hello Mark,

Thank you for the provided details. According to the error message in the screenshot, the specified password does not match the username. Please, try to sign in using the credentials that are confirmed as valid on the domain controller (DC) the Adaxes service is connected to. To validate the credentials, you can use them to connect to the DC via Active Directory Users and Computers. To find out which DC Adaxes is using for a domain, create a Custom Command as follows and execute it on any user from the domain you need. The DC will be displayed in the Execution Log after the command completes.

To create the Custom Command:

1. Launch Adaxes Administration Console.
2. In the Console Tree, right-click your service.
3. In the context menu, navigate to New and click Custom Command.
4. On step 2 of the Create Custom Command wizard, select the User object type and click Next twice.
5. Click Add an action.
6. Select Run a program or PowerShell script and paste the following script into the Script field:

$domainName = $Context.GetObjectDomain("%distinguishedName%")

$context.LogMessage("Domain Controller: " + $Context.GetDomainController($domainName), "Information")

7. Enter a short description and click OK.
8. Click Next and finish creating the Custom Command.

---

I have followed your instructions and double checked that I can sign in to the DC that it is connecting to. I tested all my DCs in that secondary domain. My password works there but not in Adaxes web interface. Is there another way we can test where the web interface is connecting to? A log that shows the attempt?

---

Hello Mark,

Thank you for the clarification.

I tested all my DCs in that secondary domain. My password works there but not in Adaxes web interface.

According to the trace you provided earlier, you have 5 instances of Adaxes service. Could you, please, clarify the actual number of Adaxes services in your environment? For information on how to view Adaxes services in multi-server environment, have a look at the following help article: https://www.adaxes.com/help/?HowDoI.ManageService.MultiServerEnvironment.html. Please, make sure that the domain the issue persists with is registered with the valid credentials on all the instances of Adaxes service that share common configuration. For information on how to check/change the credentials, have a look at the following help article: https://www.adaxes.com/help/?HowDoI.ManageActiveDirectory.ManageDomains.ChangeManagedDomainLogonInfo.html.

Is there another way we can test where the web interface is connecting to? A log that shows the attempt?

The selected service can be checked in the trace of Web Interface requests. For information on how to enable the tracing, see the first comment in this topic. The trace record should be like the following:

2020-08-25 12:40:54.305|Trace|Service '[service FQDN]' will be used to process the request.

where [service FQDN] is the fully qualified domain name of the computer where the service runs.

---

We have 4 adaxes services but we also have two servers where just the web interface is installed so that we can expose just the self service portal externally.

I have tried from each individual web interface server and get the same invalid username or password message.

All services have valid credentials and I can access the domain from those services and edit accounts.

My question about where the web interface is connecting to was in regards to the domain controller it is trying to use. I guess I could force it to use a single dc.

---

Hello Mark,

I have tried from each individual web interface server and get the same invalid username or password message.

Please, provide us with the latest trace of Web Interface requests. To do so:

1. Navigate to the folder where Adaxes Web Interface is installed. By default, the folder is C:\Program Files\Softerra\Adaxes 3\Web Interface.
2. Open the App folder.
3. Open the Web.config file with a text editor.
4. Locate the configuration\adaxes.web.ui\trace XML element.
5. Set the enabled attribute to TRUE.
6. Specify the path to the file in the filePath attribute.

<adaxes.web.ui adaxesConfigurationSetId="">
    <trace enabled="true" filePath="C:\logs\adaxes.webui.trace.txt"/>
</adaxes.web.ui>

9. Save the file.
10. Reproduce the issue and send us (support[at]adaxes.com) the log file.

My question about where the web interface is connecting to was in regards to the domain controller it is trying to use. I guess I could force it to use a single dc.

Your guess is correct. For information on how to configure Adaxes to use specific DCs, please, have a look at the following help article: https://www.adaxes.com/help/?HowDoI.ManageActiveDirectory.ManageDomains.SpecifyDCsForDomain.html.

---

I configured my services to only connect to a single dc in the secondary domain and I sent the log to your via email. Thank you for your support.

---

Hello Mark,

Thank you for the provided details. It looks like Kerberos authentication does not work for the secondary domain. To check if this is the case, try to log on to Adaxes service via Adaxes Administration Console with the credentials of an account of the secondary domain. If the issue persists, make sure that port 88 is open between your instances of Adaxes service and domain controllers of the domain. For additional information on how to troubleshoot issues related to Kerberos, have a look at the following article: https://blogs.msdn.microsoft.com/canberrapfe/2012/01/01/kerberos-troubleshooting.

---

You are correct in that we do see the kerberos pre-authentication failing and the reason is 0x18 which means the account is disable or locked. The problem is that my account works to log into the domain to even view the log, the account also works to connect in the adaxes console.

We checked with our security team and there are no blocks either port or ips to the domain from the adaxes servers. I think this began with the latest adaxes version.

Is it possible this is a bug in the web code?

---

Hello Mark,

Thank you for the provided details. Could you, please, clarify whether the domain where the Adaxes services run and the domain the issue persists with are in the same forest? Do we understand correctly that your account resides in the secondary domain and you can logon to Adaxes service via Adaxes Administration Console but cannot perform the logon via Adaxes Web Interface? To check whether an account from the secondary domain can logon to Adaxes service via Adaxes Administration console, please, do the following:

1. Launch Adaxes Administration Console.
2. In the Console Tree, right-click your service.
3. In the context menu, click Logon As.
4. Select This account and specify the credentials of an account from the secondary domain.
5. Click OK.

---

They are separate forests. The domains have no trust between them at all. We connect to the domain using different service credentials and I tested my account by using it to connect to the domain.

To do this, I right clicked the domain and selected "Change logon information"

Following your instructions about didn't work but i think that is because the service is not using that domain but our primary domain.

We need to schedule a call on this one for you to truly understand how we have it set up.

---

Hello Mark,

They are separate forests. The domains have no trust between them at all. We connect to the domain using different service credentials and I tested my account by using it to connect to the domain. To do this, I right clicked the domain and selected "Change logon information"

Thank you for the clarification. The check that you performed does not test Kerberos because the authentication that is performed via the Change Logon Information option uses LDAP.

Following your instructions about didn't work but i think that is because the service is not using that domain but our primary domain.

The logon to the Adaxes service did not work because Kerberos authentication cannot be performed for the accounts of your secondary domain. When Kerberos works, logon to an Adaxes service should be possible using the credentials of any enabled, not expired and not locked account managed by the service.

We need to schedule a call on this one for you to truly understand how we have it set up.

We can schedule a WebEx meeting. If it is suitable, please, specify your time zone and convenient date/time for the meeting. Also, please, confirm that we can use the email address specified in your Q&A profile to send the meeting invitation.

---

Thank you for scheduling a session. I am central time zone. I have tomorrow (10/29) open from 1pm to 5pm. I have Monday (11/2) open from 10am to 11:30am or 1:30pm to 5pm. I have Tuesday (11/3) open from 10am to 3:00pm.

Yes my email address in my profile will work.

---

Hello Mark,

Thank you for specifying. We scheduled the WebEx meeting for Monday, November 2, at 10:00 AM CST (UTC -6). You should receive the invitation shortly.

---

Hello Mark,

This is a follow-up message to our WebEx meeting. Could you, please, clarify the functional level of the primary and secondary domains? Also, for troubleshooting purposes, you can allow only TLS 1.2 on the servers where your Adaxes services run and check whether the issue persists.

As the issue is related to Kerberos authentication, you can try to install another instance of Adaxes service in the secondary domain sharing common configuration with the existing ones and check whether the issue persists. Kerberos authentication within one domain should work just fine.

---

Primary and Secondary domain is Windows Server 2012 R2.

TLS 1.2 is enforced on both.

How would installing a service in the secondary domain work with our other domains? Can it manage just the one domain?

I am still trying to get a firewall resource to comb through the logs.

---

Hello Mark,

Primary and Secondary domain is Windows Server 2012 R2. TLS 1.2 is enforced on both.

Thank you for the provided details.

How would installing a service in the secondary domain work with our other domains? Can it manage just the one domain?

An instance of Adaxes service can be configured to manage only specific domains, but the approach will not work in your environment because of load balancing. The thing is that information about registered domains is replicated between the instances of Adaxes service that share common configuration and an instance of Adaxes Web Interface can connect to the service where the domain should not be managed. In this case, management of other domains will not be possible for the users who should be able to do it. On the other hand, if all your domains are managed via an instance of Adaxes service that shares common configuration with other ones and resides in the secondary domain, the domains management will be performed the same way as it works now. So, there is no reason to limit the domains managed via an instance of Adaxes service.

Before installing an instance of Adaxes service in the secondary domain, you can try to install only an instance of Adaxes Web Interface and check whether the issue persists.