Recently, a Mattermost customer needed a way to provide Mattermost access to team members of newly acquired business entities.
After reviewing the security posture of the companies they acquired, they realized they all had different policies, tools, and systems and needed to bring them all up to the same standards and create an easy to manage multi-authentication solution.
The solution they implemented gave the organization a singular login and multi-factor authentication service.
The following describes the solution they arrived at. If your organization faces a similar challenge, their solution may provide a good framework for managing user access to Mattermost.
Mattermost is installed in Azure in high availability with three production nodes supporting around 30,000 users in total.
The company is utilizing a load balancer and push proxy, as well as a DMZ on the app to control access.
From an architectural perspective, a singular login was ideal. This allowed them to avoid having to connect into every AD system and manage separate Active Directory policies. Controlled access and security, as well as preventing identity collision and degraded performance for access control, were all major considerations in their solution.
To that end, Azure Active Directory was selected as their primary authentication method.
Within Azure Active Directory, all the domains from their acquired organizations (seven currently) are mapped to a single Azure identity and domain. Mapping from the other AD/LDAP systems is unidirectional and Azure Active Directory is the recipient of the user data. All original usernames (active and inactive) are retained and because the domain is the unique identifier there is no issue, even if the username follows the same format in multiple systems. A built-in conflict check was used to assist with configuration. Furthermore, conditional access policies, roles, and users groups are used to determine access to applications.
Azure AD is configured in Mattermost as a SAML provider (login.microsoftonline.com). This allows users to authenticate via single sign-on. They have modified their login page of Mattermost to only show a button to login with Azure Active Directory Credentials.
For Mattermost, users belong to an Active Directory group that includes “Everyone with a Duo account.” These users have a conditional access policy configured that requires them to use Duo as their multi-factor authenticator.
Duo was created as a MFA resource within Azure and is managed through Azure, creating one point of configuration. When a user logs into Mattermost, they are prompted on their mobile device to authenticate. The native Mattermost MFA is not utilized for this customer; they do, however, use Mattermost to manage user sessions.
Other Solutions Considered
Many other solutions on both the Active Directory and MFA technologies were considered. Their need for multiple domains but support for a few domains may still be feasible in these other solutions they considered.
1. Active Directory forests and synced domains
For their scale, an Active Directory forest and synced domain solution had performance challenges. With multiple acquisitions, the scaling and architecture of the Active Directories were out of their control.
To be performant, forests must be right-sized and small enough. Depending on scale, size of forest, and how deeply it is structured, coupled with the number and structure of Organizational Units (OUs), the performance of a scan can vary.
Some recommendations they had on this solution are as follows: Are you doing one big OU group and everything segments out? Then you can scan it fairly quickly, because the OU captures everyone. If you have multiple OUs, there’s a lot more complexity leading to performance problems.
However, this would be worth testing if you have a powerful cluster. If the customer is properly architected, this could work. LDAP can usurp the forest; if you sync everything into LDAP centrally you could avoid a SAML provider.
2. Other third-party identity federation tools
Ping was another potential solution they considered as a broker of multiple Active Directories. However, it did not meet their requirements of using conditional access policies, which was not ideal to have to replicate or bypass.
Additionally, they considered Duo directly, but it was challenging for them to route and administer all AD structures into Duo and some were not supported.
They are currently reviewing the tool Double Octopus. This tool can be owned or hosted and doesn’t require passwords. Once this tool is an approved Azure, they will likely implement.
For more information on AD/LDAP group sync, check out our docs.