Skip to content

john thompson Posts

Mattermost Office 365 SSO and TLS

My goal was to test out the Office 365 SSO authentication to Mattermost. The limitation is that the Office 365 SSO (Azure AD) requires the OAuth Redirect URI to match whatever the SiteURL is configured on the Mattermost server. 

My Mattermost HA Cluster lab environment was setup with:
Mattermost SiteURL:
NGINX TLS config:

So in my example this will fail as Azure AD expects as the redirect URI endpoint whereas I only have the HTTPS endpoint published by NGINX to the internet and visible to Office 365/Azure AD.

The Mattermost service is secured with a certificate and domain name I do not own so I wasn’t able to change certs or DNS myself. So I could….
1) Configure the NGINX server as a load balancer to passthrough TLS to the Mattermost app server cluster
2) Remove the NGINX proxy and configure a load balancer in AWS to passthrough TLS to the Mattermost app server cluster

NGINX must be a version that has the Stream module to enable passthrough. First thing is to check the stream module is installed:

nginx -V 2>&1 | tr -- - '\n' | grep module

Once I knew NGINX could support passthrough I focused on getting the SSL certificate onto the Mattermost server. I was able to just copy the same certificate and private key file currently used by the NGINX reverse proxy to the Mattermost server. Making sure I changed the owner and permissions:

sudo chown -R mattermost:mattermost /opt/mattermost/config/fullchain.pem
sudo chown -R mattermost:mattermost /opt/mattermost/config/privekey.pem
sudo chmod 400 *.pem

I then followed the TLS configuration steps described in our docs. Leaving me with ServiceSettings similar to below:

"ServiceSettings": {
        "SiteURL": "",
        "WebsocketURL": "",
        "LicenseFileLocation": "",
        "ListenAddress": ":443",
        "ConnectionSecurity": "TLS",
        "TLSCertFile": "/opt/mattermost/config/fullchain.pem",
        "TLSKeyFile": "/opt/mattermost/config/privkey.pem",

NGINX needs to be told to look for a passthrough configuration. So edit the nginx.conf and at the end of the http configuration block add the include statement.

sudo nano /etc/nginx/nginx.conf 
http {
include /etc/nginx/passthrough.conf;

We now have to create the passthrough configuration file you have just referenced.

sudo nano /etc/nginx/passthrough.conf

The NGINX docs are really good here and I picked out a couple of key points. There are many settings you could use to determine the load balancing settings but I wanted to keep my configuration simple in my lab.

Load Balancing Method and Session Persistence
Firstly the Open Source version of the product only allows the Session persistence methods hash or ip_hash directive. I tried ip_hash first but ended up getting the following error:
nginx: [emerg] “ip_hash” directive is not allowed here in /etc/nginx/passthrough.conf:4
As far as the notes go, it should work but I didn’t have the patience to find the answer.
I selected for my configuration:

hash – The server to which a request is sent is determined from a user‑defined key
$remote_addr – client address
consistent – Requests are evenly distributed across all upstream servers

# LB https to 2 backend servers
stream {
    upstream mm_mydomain_com {
      hash $remote_addr consistent;

    server {
        listen 443;
        proxy_pass mm_mydomain_com;
        proxy_next_upstream error timeout;

Once I had a passthrough.conf that I thought would work, I removed the current NGINX https reverse proxy configuration.

cd /etc/nginx/sites-enabled
ls -l
sudo rm mattermost

I then ran a test against the NGINX configuration sudo nginx -t

The final test was to take my two Mattermost app servers and reboot testing connections to both, which finally worked!

This was the best way I had to quickly get a working configuration in place to test Office 365 SSO with Mattermost and give me a chance to learn a bit about NGINX. There are likely better ways I could have completed this but this works well for me for testing Mattermost Office 365 sign on in my lab.

If I was looking at this for a production instance then I would investigate the ip_hash configuration, health_check and proxy_next_upstream settings in more detail.

Thank you to those who have shared before and used as a basis for this:

Ansible and Windows a match made in…

…Windows Subsystem for Linux Heaven?

My creative colleague Christian Johannsen has developed an amazing script to deploy a demo environment of Mattermost with two of our DevOps integrations the Jira and Jenkins plugin. He hopes to open source the repo at some point.

It uses terraform to deploy the environment in AWS, bash and python scripts to configure the services and an Ansible playbook for the Jenkins install.

Christian created the instructions to run all the scripts but these were for Mac. I’m a rare breed at Mattermost as I am a Windows user so I had to go through the environment setup myself and modify it for Windows.

I was aiming to run this all natively in Windows or at least in Git Bash but got beaten in the end by Ansible. As they point out Ansible cannot run on a Windows host natively, though it can run under the Windows Subsystem for Linux (WSL). They then go on to say that they do not support the WSL and it shouldn’t be used in production.

Installing WSL on Windows 10
Installing Ansible on WSL

I raised  a query on the Ansible Google forum and a helpful Redhat engineer stated that there are also no plans to support this natively on Windows. “It will work but in the odd case it doesn’t you won’t get any help from GitHub unless you can replicate it on an actual Linux platform.”

So it looks like Windows is an outlier in the Ansible world. Just like me and my Surface Laptop at Mattermost!

intro to the mattermost CLI

At work we have been building out our demo environments and looking to create a re-usable Github repo for deploying and configuring Mattermost. The aim is to automate as much as possible of the mattermost deployment. Mattermost can be configured using the API or the CLI. These are my adventures with the CLI….

The updates from the CLI are automatically written to the config.json. There are some considerations when changing settings:

  • Dotted Notation: you have to put the section of json file ahead of the config setting. Shown below as TeamSettings.ExperimentalDefaultChannels
  • Arrays: CLI accepts multiple values for array settings. In the example as Public-Channel01 PublicChannel-02
"ExperimentalDefaultChannels": []

sudo ./mattermost config set TeamSettings.ExperimentalDefaultChannels Public-Channel01 PublicChannel-02

"ExperimentalDefaultChannels": [

I’ll will add to this post over time so it is a resource to keep coming back to.

But for now this is the story so far…

/remind me

My memory is not my strongest quality somebody told me once, I forget who.

To help with this Mattermost has a /remind plugin developed by a member of the Mattermost community Scott Davis. This can be really useful as a prompt for your forgetful self or a friendly nudge to @co-worker. If you want to see your options then type:

/remind help

If you want to make sure meeting notes get sent out after your call…

When you receive a notification you get prompted by the Remindbot with a new message in your UNREADS

You have options to complete or delete, and can even reschedule the reminder

To install the plugin go to and search for remind or go to the GitHub page.

A simple productivity tip to help you in your day.