Preview: LDAP/SSO support

Feedback Design Feedback Request
1

UPDATE: Thanks for everyone’s feedback on Active Directory/LDAP, the feature is now available with Mattermost Enterprise Edition and documentation is available online.

The current release of Mattermost integrates with GitLab to support authentication via LDAP, SAML, Kerberos and other enterprise authentication standards. Run GitLab omnibus to install GitLab Mattermost, a Mattermost deployment pre-configured with Gitlab SSO and ready to connect with enterprise protocols via GitLab accounts.

For connecting Mattermost directly to enterprise protocols, there is a commercial version of Mattermost being developed to offer (among many other features) similar authentication options as a standalone installation, starting with OpenLDAP and Active Directory.

Following our principle of designing familiar experiences, we’ve reviewed a broad range of LDAP configurations and decided to pattern our design off of AeroFS, the leading on-prem DropBox alternative.

We’ve re-grouped and omitted some settings to focus on what we think are priority, and from the below starting point we plan to incorporate feedback from forums and customers to craft a final design that meets the needs of a broad range of users.

We look forward to hearing your thoughts and feedback on prioritizing and adjusting the below features.

1. In System Console > Authentication > Single Sign-On

Offer a “Lightweight Directory Access Protocol (LDAP)” authentication option with the following headings, fields and help text:

2. Basic Configuration options

These would be offered in the pane from the menu above.

Server Host: the hostname or IP of your account server. This address must be resolvable by the Mattermost server.

Server Port: the port to connect to. Default LDAP ports are 389 for ldap, and 636 for ldaps.

Base DN: this will be the root of the search tree. Generally you would like to point this at the most specific node in your LDAP store that will include all the users that should have access to Mattermost.

Bind user name: to search for a user’s information, Mattermost requires access to an account with the ability to run a search. In almost all cases, this should be an account with limited access that you create especially for the Mattermost server.

Using an administrator account with broad permissions is not recommended. Usually this is given in LDAP format (CN=Directory Agent,DC=example,DC=com), but Active Directory will accept other formats (\\DOMAIN\Directory Agent) etc. See below for hints on testing this.

Password: the password for the bind account given above.

Security: StartTLS or SSL is recommended. Selecting plaintext will result in a warning, and should be avoided for best network security.

Also, for user configuration the following fields are required:

User attribute: the attribute in the user record to used to map LDAP users to Mattermost users, such as uid or username.

Email attribute: the attribute in the user record that holds the primary email address. This attribute should hold the email address that users will provide to Mattermost as their login information.

3. Advanced User Configuration

LDAP schemas may vary across customer environments. Here you can configure specifics of your LDAP schema. Most users will not need to modify this section.

Search scope: by restricting this search to the immediate children only, or ignoring the base DN, you can prune undesired matches from the LDAP result set. Normally this is set to “Search the object specified by Base DN and its entire subtree”.

User class: the object class that all users should belong to. This should be restrictive enough to disallow accounts that may have been allocated for software packages, devices, etc. This becomes part of the LDAP query in the authentication path.

First name attribute: the attribute that stores the users’ first name. Normally this should be “givenName”.

Last name attribute: the attribute that stores the users’ last name. Normally this should be “lastName”.

Username attribute: the attribute that stores the users’ username, that will be used as a Mattermost username.

4. Advanced Group Configuration

If you choose to enable LDAP Group Syncing on your Mattermost server, more configuration options specific to Groups will appear below the checkbox. You may need to change these default values if you use custom LDAP Object Classes.

Search Scope: similar to User Search Scope, except this scope is used when looking for groups to sync between LDAP and Mattermost. Normally this is set to “Search the object specified by Base DN and its entire subtree”.

Object Classes: the object classes that Mattermost will recognize as groups and sync from LDAP. Normally there are several different object classes which function as groups, please list them all here in a comma-separated list.

Static Member Attributes: attributes on LDAP group nodes which hold group members’ Distinguished Names (DNs) as values. Normally a groupOfNames object would have “member” as a static member attribute.

Group Name Attribute: the attribute which holds the name of the LDAP group as you want it to appear in Mattermost.

Daily Syncing Time: what time each day you want Mattermost to sync groups with your LDAP endpoint. You can also sync immediately from the Groups administration interface on the Web admin interface.

Open Questions:

  • What are the valid characters for an LDAP username/user group compared to a Mattermost username
3 Likes
2

Looking forward to test LDAP!

3

@cifvts Is there anything specific you would like to see in our LDAP implementation?

4

@crspeller I’ve checked the LDAP configuration of Redmine and GitLab and pretty much it seems that the options I need are all in this preview. Normal case for me is I have a tool which connect to LDAP, user is inserted in LDAP from the sysadmin, after that the user can connect to the tool. The user is not able to create itself if it’s not present yet. Redmine seems to need to have an user created and then it connect that user using LDAP but I prefer not being force to do that, as GitLab does.

5

From description seems quite ok to me. What should be also checked in sync process is if user on LDAP is deleted on disabled it should also be disabled in mattermost (not allowed to log in)

6

Thanks @Lafriks, we’ve been discussing the priority of different ways to update the Mattermost auth tokens once a user has permissions removed via LDAP service.

Which do you feel is higher priority:

a) Check LDAP authorization during Mattermost login authentication

When a Mattermost user with a valid Mattermost token logs in, check for LDAP authorization before allowing the user to enter Mattermost?

Pro: Permissions always in sync with LDAP server
Con: Delays user login

Our thinking is to recommend this solution only if total roundtrip times from LDAP server are less than some performance benchmark.

b) Sync authorization with LDAP daily

Use the “Daily Sync Time” setting to efficiently synchronize account validity between LDAP server and Mattermost instance.

Pro: Permissions up to date with in 24 hours of changes in LDAP
Con: Up to 24 hours lag in sync status

c) Check LDAP authorization after Mattermost authentication

Allowing Mattermost users to login with tokens before polling the LDAP server for confirmation of an active account, then if the account is not active in the LDAP server rejecting the Mattermost user and invalidating the Mattermost token.

Pro: No delay in user login (vs. option A) and user accounts would be disabled on next login rather waiting for up to 24 hours for server to sync (vs. option B).

Con: For a brief period of time (round trip of LDAP auth request) user with deactivated account would have read and write access to Mattermost team.

Early thinking is perhaps b) and c) together as a final solution.

These features would be implemented in phases. We’d highly appreciate feedback on these initial thoughts, other approaches and relative priorities.

7

Is there currently (or will LDAP support bring) a way for admins to “kick” a user and revoke any active session tokens? That might be a factor in what pattern is best for syncing auth data as it would allow admins a way to immediately revoke logins after a change in auth levels without requiring the constant round trips to the LDAP server for normal use cases. The other place such a function is useful is for when people forget and leave their account logged in on some computer they are no longer at.

8

@alerque Absolutely. In the current release you can revoke session tokens under Account Settings-> Security-> View and Logout of Active Sessions

The Admin Console is being developed for IT Admins to do this centrally.

9

I think mix between b) and c) sounds like an optimal solution

10

Hi,

so how would LDAP authorization based on a login via Mattermost token work? Assuming LDAP would do a bind, thus requiring the user’s password to be cached somewhere, or would that only check if the account still exists on the server, using a uid?

In any case a caching of ldap auth seems here only an optimization, thus b) being an optimization of a) which preferably would be configurable. edit I have not seen the “Daily Syncing Time” settings, so it is configurable.

Johannes

11

Which attribute would be used to map ldap users to mattermost users?

I have seen often that applications just use the primary email address. I would hope it is not the case here, since users might change their primary email address on the ldap server account. That would in this case result in a new user in Mattermost, would he login with his new email address, even though it is the same user. Best would probably be to to make that a setting, which ldap attribute to use to map users. This can be uid or username.

12

I agree that using the uid/username would be preferable as a default.

13

Look forward to supporting ldap soon.

1 Like
14

HI folks,

First of all, I have been evaluating mattersmost and it seems like a great communication tool! We were quite enthusiastic about it, but felt disappointed that you decided to roll LDAP support into a commercial product. I can completely understand the need to fund and promote your enterprise. I am not looking for full AD integration, but a simple LDAP based SSO would have sealed the deal for us.

Let me put in a simple business case for supporting it in the open source or community version. Most IT departments tend to be cash starved, and it take skunkwork projects from people not necessary from IT to build something. The closer the skunkworks project is to integration the better the chance of an IT department deciding to support it, and then there is a great business case to get the enterprise version.

I could not use this for the non-profit because we don’t have money but we do have donated funds to have a decent infrastructure with SSO. It would have been nice for established open source project like GNOME (http://www.gnome.org/) to be able to use this while still philosophically supporting open source.

15

Thanks @nebulade, thanks @tribou, appreciate the feedback, and agree uid/username makes sense as an option in addition to email.

Thanks @FangPeishi, agree, we want this out too.

Hi @sri, highly appreciate your enthusiasm and feedback. We want Mattermost to have meaningful impact on organizations who use it.

Our focus so far has been on team communication, which is why we built the product.

Our thinking on enterprise comes from organizations who’ve approached us. Each of those conversations influences how we think. I would love to hear more of your thoughts.

Would you be open to joining us on pre-release.mattermost.com/core?

You can direct message me at it33,

2 Likes
16

When do you release the commercial version with LDAP support? I’m looking for it.

17

SAML SSO,OAuth2 based web,Kerberos will they supported too … What is the expected date of release of the commercial version of this software

18

Early customers, who’ve deployed the Mattermost platform, contacted us, and are seeking a commercial “enterprise communication” solution, have access to pre-released builds of the enterprise version that includes LDAP SSO.

We’re working with them to validate the feature set and roadmap for the enterprise release, which should be availabile in Q1 2016. SAML, Kerberos and custom SSO are among the features requested.

We plan to release new builds monthly, and specific features will depend on feedback from early customers of the commercial version.

21

Hi. I have been championing MM as a real replacement within the org I work for and really appreciate all the work you guys are doing at MMHQ!

The initial dev tests have been v.positive.

I’m now moving into rolling out a wider evaluation, to some of the key departments, that would have influence on MM’s adoption.

1: I’d be keen to road test the enterprise version, as ldap integration would be key (as would voip integration)

2: I do agree with previous posts however, in that the open-source version, should ideally be able to leverage ldap, even if it was limited in scope (i.e. restricted to x number of objects and reduced filter/search).

I would certainly feel this would not impact MM enterprise pickup as more appropriate function, saml etc would still be required for the bigger players and surely, having many users on MM (even small open source players) would only open up MM as a real alternative to slack etc and have a much wider audience.

If it is possible, may I please request access to testing the enterprise version, so that at least during this next phase of testing, I can really test the value of MM as a real replacement to our current setup of Exchange, Lync and Slack leveraging our internal ldap (we have multi global ldap’s).

I still love MM, would just love it a little more if it allowed some ldap functionality in the open source version :smiley:

Thx
Bry

1 Like
22

We’re a small team using Mattermost Gitlab right now, connecting to LDAP through Gitlab. We wouldn’t be able to use Mattermost without LDAP. Will LDAP be phased out of support from Mattermost Gitlab once the Enterprise version is ready?