Unable To Authenticate


Choose your authentication mechanism below:



Azure authentication


AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application


Azure won't authenticate MailArchiva users if at least one of the Reply Url's specified in the MailArchiva app registration section in the Azure Portal doesn't match the Authentication Callback URL defined in Configuration->Logins->Azure. For example, assuming the URL "https://office365.archiva.com/authorize.do" was specified as the Authentication Callback URL in MailArchiva, then the Azure Portal must have at least one matching Reply URL (including port) present. The Authentication Callback/Reply URL must have the "/authorize.do" query appended to enable MailArchiva to negotiate with Azure during the authentication process.


To add the Reply Url to Azure, login to the Azure Portal, click Azure Active Directory on the left, click App Registrations, click MailArchiva app, click Settings, click Reply URL's, type an appropriate URL that matches the Authentication Callback URL defined in MailArchiva and click Save. When defining a Reply URL, it is possible to specify a wildcard prefix. For example: http://*.stimulus.local:8090/authorize.do. This URL will match any domain prefix, for example, http://xxx.stimulus.local:8090/authorize.do.


Further to the above, for the authentication process to work correctly, the MailArchiva web console must be accessed from your web browser using the same domain as specified in the Reply URL. In the case above, the MailArchiva web console would be accessed from https://office365.archiva.com.


Since the callback URL only needs to be resolvable from localhost and does not need to be contactable externally, during testing, it is possible to create a temporary domain by adding one to your hosts file on your local client workstation. For example, for test purposes, one might add the domain mailarchiva.local to your local hosts file, then add the reply URL http://mailarchiva.local:8090/authorize.do to both the Authentication Callback URL in the MailArchiva Console and to the Reply URL section in the Azure Portal.

To summarize, for testing purposes:

  1. Add domain mailarchiva.local to hosts file on your local workstation
  2. Set http://mailarchiva.local:8090/authorize.do to Authentication Callback URL field in MailArchiva->Configuration->Logins->Azure
  3. Add http://mailarchiva.local:8090/authorize.do to Reply URL in Azure
  4. To test the authentication, access the URL http://mailarchiva.local:8090 using your web browser.
  5.  If the authentication fails, access http://mailarchiva.local:8090/signonform.do and login using your admin credentials to make adjustments to your configuration.


NTLM Active Directory authentication


NTLM Single Signon Note: Please refer to the NTLM SSO for all NTLM single signon related troubleshooting.


Preparation Step: Before proceeding, ensure that you have followed the AD configuration steps in Logins. In particular, you need to run the ADSetupWizard.vbs script. This script creates the needed computer account in Active Directory. Furthermore, it sets a password of your choosing on the computer account.


Common Active Directory settings


Typical settings in Configuration->Logins:


DNS server lookups: Checked (if connecting over the Internet, this option should be unchecked)
Perform DNS SRV lookups: Checked
DNS Server IP Address: (Note: This is the IP address of your DNS server)
Base DN: CN=Users, DC=company, DC=local (note: capitalization of DC)
Service Account Login: service$@company.local (note: a computer account called service must be created in Active Directory. 
Active Directory Server Address: activedirectory.company.local (NOTE: must be fully qualified domain name). If this does not work, try company.local) (do not enter an IP address here!!!)
Bind Attribute: userPrincipalName
Email Attribute: proxyAddresses (if using MS Exchange)
Email Value: SMTP:(.*) (if using MS Exchange)
DNS Site: (leave this blank)
UPN Attribute: userPrincipalName
UPN Value: (.*)
NTLM single-sign-on authentication: Uncheck (unless you have carefully followed the NTLM preparation steps)


In Configuration->Domains, ensure all domains are entered correctly.


The following ports must be open from the MailArchiva Server to Active Directory: 389 (LDAP), 135, 49670 and 49667 and 53 (DNS)


Note: If connecting to an AD server over the Internet, typically, the DNS server lookup should be unchecked. With DNS lookups enabled, the DNS server will return an internal IP address to the subnet where the AD server resides. This is not wanted if you connected from the outside. It's better to simply specify the IP address of the AD server.


No role assignment


Error: User is authenticated, but no role is assigned

Exactly as it says. Authentication was successful, although a role could not be assigned to the user. You need to create a matching role assignment in Configuration->Logins.

Missing MemberOf LDAP Attribute in Role Assignment

The affected AD group needs to be assigned the Read permission in Active Directory.


Error: LDAP Attribute must be selected in Active Directory Role Assignment 0

You have a role assignment with a missing LDAP attribute. You need to redefine your role assignments in Configuration->Logins.


Incorrect bind attribute


failed to authenticate user: The account is not found

Ensure the Bind Attribute in Configuration->Logins is "sAMAccountName".


Invalid credentials (LDAP Error 49)


The following error is outputted when performing a test authentication:

LDAP: error code 49 - 8009030C   : LdapErr: DSID-0C09056D, comment: AcceptSecurityContext error, data 52e, v2580


LDAP code 49 usually means invalid credentials. Most likely the computer account password is incorrect or it is disabled. Rerun SetComputerPassword.vbs or ADSetupWizard.vbs scripts. Set account password in Configuration->Logins and ensure your computer account is active.


Failed to authenticate user:Connection timed out: connect.


The following ports must be opened:


Ports 80, 443 from CAS to MailArchiva (e.g. archiva.com)
Ports 389, 135, 49670 and 49667 from DC to MailArchiva (e.g. archiva.com)


Only If AD is running outside of the network, running MailArchiva: Ensure that DNS lookup is disabled in Configuration->Logins->Active Directory.  In the Server IP field, enter the IP address of AD server.


If, after doing the above, the auth still doesn't work, enable troubleshoot logging in Configuration->Logs. Restart MA service. Perform a test authentication, view content of auth.log in COnfiguration->Logs. On the line that starts with MsrpcEpmMap: .[netlogon] maps to port: x1 and [lsarpc] maps to port: x2. Open specified x1 and x2 ports to the  DC server on the firewall and retest authentication.


Incorrect DN


Error: account [accountname] was not found in ldap repository.


The DN specified in Configuration->Logins is incorrect. For example, should NOT be:


DN=demo.local (.local is incorrect, should be DN=demo, DN=local)


Error: failed to connect to LDAP {javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-031007DB, problem 5012 (DIR_ERROR), data 0                   


You are using lower case, dn in the DN. It should be:


dc=demo,dc=local (incorrect: DC must be upper case, as in DC=demo, DC=local)


Incorrect service account name


Service account must be in the correct format. Assuming the service account is a service, it may NOT be:




The correct value is: service$@company.local. 


Note, the dollar sign after the account name. This denotes a computer account in AD. If you don't know what a computer account is or why it is needed, please reread the Logins section.


Emails not visible in search

Make sure that the mail attribute is correct. If using MS Exchange, in Configuration->Logins, the mail attribute should be set exactly as "proxyAddresses". 


If you are using another mail server, it may be something else. e.g. mail. In addition, there must be the value %email% in the user role filter.


No connectivity to Active Directory


The following ports must be open from the MailArchiva Server to Active Directory: 389 (LDAP), 445 (SMB) and 53 (DNS)


If in doubt, Telnet to each port from the MailArchiva server to confirm that a connection can be established.


NTLM SSO Enabled Without Following Preparation Steps


Error: When accessing the web interface from the browser, the webpage begins flickering and changes quickly between "detect screen resolution" and another page.


The NTLM checkbox was enabled in Configuration->Logins, without following the NTLM preparation steps. Either NTLM authentication must be disabled or your browser must be configured correctly. Refer to NTLM Authentication Failure for further troubleshooting steps. Alternatively, disable NTLM authentication as follows:


Visit https://localhost:8090/mailarchiva/signonform.do directly. Click Configuration-Logins, uncheck NTLM SSO and click Save.


Active Directory Server Name incorrect


In Configuration->Logins, it is necessary to specify the fully qualified domain name of the Active Directory server (e.g. activedirectory.company.name). Note: The server name must be the actual name of the AD server and not only the DNS name (if it is different). Do not enter the IP address of the server here!


For good measure, please ping the fully qualified domain name of the Active Directory server to ensure that it is resolved OK. If not, there is a DNS issue to attend to.


Property not set or constructed

The "Property not set or constructed" error may occur for the following reasons:


  •     Assuming you have a firewall present between MA and AD, ensure ports 135, 49670 and  49667 are open between MA and AD.
  •     There is a both a forward and reverse lookup entry for the MailArchiva server specified in the DNS manager on the AD server
  •     The machine hosting MailArchiva has a hostname, ip address, and a fully qualified domain name.
  •     The name of the AD server specified in Configuration-Logins is the actual fully qualified name of the AD server (not the DNS name)
  •     To combat ransomware vulnerability, SMB v1 has been disabled on AD server. The resolution is to upgrade MA to the latest version.


The underlying error is outputted in auth.log in Configuration->Logs when debugging is enabled. A debugging analysis may proceed as follows:


1) enable debugging in Configuration->Logs
2) perform a test LDAP lookup in Configuration->Logins
3) go back to Configuration-Logs and view contents of auth.log
4) if auth.log doesn't contain debugging info, you may need to restart the service and perform step 2 above
5) In the auth.log, a stack trace containing the underlying error message will be outputted in audit.log

6) if the error that appears is "connect refused" as below:


NETLOGON: Connecting DCERPC handle to ncacn_ip_tcp: [netlogon] with identity ISGLOCAL.ISG\MAILARCHIVAS$
java.net.ConnectException: Connection refused (Connection refused)
    at java.net.PlainSocketImpl.socketConnect(Native Method)


then either  a firewall/port issue. or it could be that the SMB v1 service has been disabled. In this case, assuming there is a firewall btw MA and AD, the resolution is open ports. Alternatively, if SMB v1 is disabled, upgrade MA as newer versions of the auth lib embedded in MA use RPC's instead of SMB.


If the error is "Failed to locate authority for name" as in below:


2012-05-12 18:34:26: Caused by: jespa.security.
SecurityProviderException: Failed to locate authority for name: domain.com
2012-05-12 18:34:26: at jespa.security.SecurityProvider.getAuthorityDnsNames(SecurityProvider.java:233)


This means that the name of the AD server is incorrect in Configuration->Logins. Some folks tend to have a different DNS name for the AD server than the current name of the AD server. MA requires the actual name, not DNS name (if different). To complete it, go to the AD server, view computer information. Take note of the current host name of the AD server. Then, enter the actual FQDN of the AD server in Configuration->Logins.


UserPrincipalName not set or constructed

Usually, this means that the account being used for the purposes of Test Login does not have a userPrincipalName associated with it. Please try logging in using a different account. For folder sync to work, the Bind Attribute in Configuration->Logins->AD Authentication, ought to be set to userPrincipalName. If folder sync is not needed, then it is possible to set the Bind Attribute to sAMAccountName. In this case, one can login to any account (even those without userPrinicipal names).

Some MemberOf attributes missing


Some users are unable to login due to failed role assignment. Upon further examination, it appears some AD MemberOf attributes are not being retrieved from AD during user logon. Curiously, MemberOf attributes may be missing for some users, and others not. To resolve this, the computer account will need to be assigned read privileges to all user groups.


LDAP Authentication


Common LDAP settings


Typical settings in Configuration->Logins:


DNS server lookups: Checked
Perform DNS SRV lookups: Checked
DNS Server IP Address: (Note: This is the IP address of your DNS server)
Base DN: DC=company,DC=local (note: capitalization of DC)
Service Account Login: CN=Users,DC=company,DC=local
LDAP Server Address: ldap.company.local (NOTE: must be fully qualified domain name). If this does not work, try company.local
Bind Attribute: uid
Email Attribute: mail
Email Value: (.*)
Primary Email Attribute: mail
Primary Email Attribute Value: (.*)


UID Mismatch


Cannot find user due to UID mismatch

MailArchiva cannot locate the user logging in since your uid's do not have the domain (e.g. "@company.com") appended to them and you have mistakenly specified a default login domain. The default login domain should be empty (blank) if your uid's dont have the domain name appended.


Zimbra LDAP settings


The below settings configure login with Zimbra LDAP by user's email address.


DNS server lookups: Unchecked
Server IP Address: (Note: This is the IP address of your Zimbra server)
Base DN: DC=company,DC=local (note: capitalization of DC)
Service Account Login: uid=admin,OU=people,DC=company,DC=local
LDAP Server Address:
Bind Attribute: zimbraMailDeliveryAddress
Email Attribute: zimbraMailDeliveryAddress
Email Value: (.*)
Primary Email Attribute: zimbraMailDeliveryAddress
Primary Email Attribute Value: (.*)


Example role assignments: When creating a role assignment, assign role "user" to ldap attribute "objectClass" with match criterion "ZimbraAccount". Assign the role of "administrator" to ldap attribute "ZimbraMailDeliveryAddress" with match criterion user@company.com.

Kerberos Active Directory Authentication (v2.1 and lower) Including OSE)


Note: The troubleshooting tips in this section do not apply to MailArchiva EE v2.5 or higher!

There are several reasons why the MailArchiva email archiving server might not be able to authenticate with Active Directory. They are:

Login Domain Incorrect: krb Error 68

KDC_ERR_WRONG_REALM 68 Reserved for future use. Your service account login domain or user account login domain is incorrect.
Solution: Check the service account login domain (e.g. admin@business.local) or user login domain (e.g. user@smallbusiness.local)

There is a missing entry in the hosts file

Either your DNS is not configured correctly or you are running MailArchiva in a test environment. In these cases, an entry needs to be added to your hosts file to help MailArchiva solve your AD by FQDN. In MailArchiva Enterprise Edition 2.0 and greater, you may need to click the Add To Hosts button to automatically add the ip address info to the hosts file. For OSE and older versions of EE, the hosts file is updated automatically. However, sometimes it can go astray and add more entries than necessary, causing authentication to fail. In this situation:


  1. Delete all MailArchiva entries inserted in your hosts file
  2. Add the IP address, fully qualified domain name (FQDN) and name of the server running Active Directory to your c:\windows\system32 \drivers\etc\hosts file (Windows) or \etc\hosts (Linux) .


You need to add the following entry (WITH CAPITALS included) to the hosts file on the machine running the MailArchiva server: ACTIVEDIRECTORY.COMPANY.LOCAL ACTIVEDIRECTORY

(NB: Please replace ACTIVEDIRECTORY.COMPANY.LOCAL with the ACTUAL fully qualified domain name of your Active Directory server!!! If you do not do this, you will get Server Not Found In Kereberos Database error. This error will only appear in your debug.log file)

Server Not Found In Kerberos Database

In your host file, you must substitute ACTIVEDIRECTORY.COMPANY.LOCAL ACTIVEDIRECTORY" with the fully qualified domain name of your Active Directory Server. For instance, your server may be called AD01 and your company HITECHINC. In which case, you would add the following to your hosts file: HITECHINC.LOCAL AD01

In the MailArchiva email archiving server Configuration screen, you will want to specify the following in Active Directory configuration settings:

Kerberos Server: ad01.hitechinc.local:88 LDAP Server Address: ad01.hitechinc.local:389

The important point is that the fully qualified name of your AD controller must correlate exactly to the name of the server registered in Active Directory.

KDC and LDAP Address must be fully qualified domain names
Ensure that your KDC and LDAP address is fully qualified (e.g. activedirectory.company.com)
Do not use the short name or ip adresss of the server
You must use the fully qualified name when logging in
You login using john@company.com, not just john.

There is a clock skew between the AD controller and the MailArchiva server.

The time needs to be exactly the same between these machines.

Password is incorrect

You entered an incorrect password when testing the account.

Server unable to reach the AD controller

Drop into a DOS prompt and ping the AD server using the fully qualified domain name. i.e. type:

Firewall blocking ports 88 and 389 

Enable ports 88 and 389 on your firewall. It is a good idea to shut down your firewall while testing (if you have real problems).

Wrong Base DN

Make sure you are using the correct Base DN. No quotes needed. Change to DC=company, DC=com. It does not need to be any more complicated than that.

No Roles Are Assigned

Don't forget to create a role assignment for your test user. If a role is not assigned to a user, then you won't be able to perform a Test login for that user.

No support for encryption type

When attempting to authenticate against a Windows 2008 server, you might receive the message "no support for encryption type" or something equivalent. To maintain backward compatibility against older AD controllers, by default, MailArchiva uses DES encryption for kerberos authentication. This is not compatible with Windows 2008 server which uses AES as the default encryption type.

The easiest way to get MailArchiva to authenticate is to enable DES authentication in individual AD accounts. From the AD console, select user properties, select Account tab and select "Use kerberos DES encryption types for this account".

Alternatively, it is possible to enable AES encryption in MailArchiva by creating a file called kr5.conf with the following:



default_tkt_enctypes = aes256-cts

default_tgs_enctypes = aes256-cts

permitted_enctypes = aes256-cts
Save the krb5.conf in /opt/mailarchiva/server/webapps/mailarchiva/WEB-INF/conf (Linux)
c:\Program Files\MailArchiva\Server\webapps\mailarchiva\server\WEB-INF\conf


Troubleshooting complex Active Directory problems


  1. First off, please reboot the server and try again before following these advanced instructions. Sometimes it takes a reboot to sort a Kerberos problem out.
  2. Stop the Server
  3. Enable DEBUG logging in the ServerLog
  4. Start the Server from the DOS console (to do this in Windows, run the following exe C:\Program Files\MailArchiva\Server\bin\MailArchivaServer.exe)
  5. From the Configuration Screen in the Email Discovery and Administration Console, click the Test Login button in the AD configuration
  6. Examine both the Console Output and Debug Log (kerberos protocol handshake information should be outputted to the console)
  7. Check out Jaas Kereberos Troubleshooting to solve your problem.


© 2005 - 2024 ProProfs

Found this information useful? Visit mailarchiva.com to learn more about MailArchiva.