Unable To Authenticate

Choose your authentication mechanism below:

• Azure authentication - Authentication with Microsoft Azure
• NTLM Active Directory Authentication - Used by modern versions of MailArchiva to authenticate with MS Exchange
• LDAP authentication - Authentication against LDAP servers such as OpenLDAP
• Kerberos Active Directory authentication - Used by older versions of MailArchiva to authenticate with MS Exchange

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 127.0.0.1 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 127.0.0.1 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

Common Active Directory settings

Typical settings in Configuration->Logins:

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)

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:

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:

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:

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:

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.

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:

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

192.168.0.100 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:
ping ACTIVEDIRECTORY.COMPANY.LOCAL

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:
 

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.