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:
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)
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.
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.
failed to authenticate user: The account is not found
Ensure the Bind Attribute in Configuration->Logins is "sAMAccountName".
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.
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.
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)
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.
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.
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.
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.
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.
The "Property not set or constructed" error may occur for the following reasons:
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.
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 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.
Typical settings in Configuration->Logins:
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.
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.
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:
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: