We are new to using the E10 edtion, for Academic purposes, and use our LDAP for authentication.
With potentially thousands of students, we want to automate the creation of teams by their courses, and then add the users to their appropriate course teams. Of course we’ll also remove them if they drop the course. We’re using the Go API (client4) to do this. I’ve managed to create the teams if they don’t exist (I’d love to be able to delete it using the API too… especially during development since mistakes happen, but that’s another topic) and now I’m trying to create the users, then add them to their teams (or remove them). But, since password is a required field when creating a user, and since it requires at least 5 characters, and since we’re using LDAP for authentication (so I don’t know and nor do I want to know their passwords), I’m a bit unsure what to do now. I’ve got the code in place to create the users with fake generated-and-complex passwords with the idea that since we’re using LDAP for authentication, the password in the Mattermost user record doesn’t really matter anyway. Does this sound like a reasonable approach? Any pitfalls?
Since you’re going to use your LDAP for authentication, you don’t need to create users but have them sync with Mattermost. See this docs to setup LDAP with Mattermost - https://docs.mattermost.com/deployment/sso-ldap.html. Passwords for LDAP users are not stored in Mattermost database; those were at your LDAP server.
Once all users are in sync, you may use Go API to manage their teams.
Thank you for taking the time to reply saturnino.
I know we can delete teams using the RESTful API, but don’t see a Go equivalent. I really don’t want to do part Go, part RESTful, and part Command Line Interface (CLI), which unfortunately is where it looks like we’ll end up.
As to the use of LDAP, I won’t go into details but yes, we DO need to create users in advance. We’re very familiar with LDAP sync and it is enabled, but we have to create the users in advance and then migrate them to LDAP, something the Mattermost folks have said we can do with the CLI using the user migrate_auth command.
By the way, for those reading this in the future, we learned you can create the users in advance, but as said if you’re using LDAP you then need to migrate them to LDAP, which so far only seems doable using the CLI. We do delete (actually deactivate) people who drop all their courses and then they don’t count towards our licence which is good. But then upon creation we need to watch for them and reactivate them since they already exist in a deactivated state. This often happens in our environment by the way. To reactivate them it seems we have to use the RESTful API (https://api.mattermost.com/#tag/users%2Fpaths%2F~1users~1{user_id}~1active%2Fput), but I’d really like to do all of this in Go without mixing up 3 different methods.
For completeness, I just heard from the Mattermost folks. You can indeed set a user’s active state using Go, using Client4.UpdateUserActive. I had just completely missed that function. However the only way to migrate users is the CLI, and I’m going to put in a feature request to have that capability from both Go and the RESTful API.
Again, for completeness. It turns out that if you’re using LDAP, when the LDAP sync runs it re-activates any users who were deactivated. This, plus the fact that you can only migrate using the CLI makes Mattermost (Enterprise edition) largely unusable from our perspective. And you cannot “just” use LDAP for auth and not bother with sync. It seems that Mattermost feels that once you move to LDAP, LDAP should do all the driving. In an organisation with tens of thousands of users, only a tiny tiny portion of whom should be authorised to use Mattermost, we don’t see it that way at all. So I’ve set this to unsolved again. Such is life.
Migrating users via the API is definitely something we’d like to see. And yes, all of our users already have LDAP accounts. The problem is that we have many many thousands more users in LDAP than would ever use Mattermost. And since “word gets around” we then have people logging into Mattermost who aren’t authorised to use it. The way Mattermost works is to assume that LDAP drives Mattermost and, even though those users don’t have a team, they become “active users” counting against our license. If we deactivate them, the sync simply reactivates them. So then we need a rather manual effort to actually (CLI) fully delete them. We pre-create the users in Mattermost so that they are already added to the teams for their courses. It can’t happen “after the fact” since the instructors want to hit the ground running and get everyone on board in their first lecture. So they give them our Mattermost URL, they login, and their teams are already all there waiting for them.
We’d really like to see just LDAP authentication, without any sync done whatsoever. We are populating Mattermost using the same central data from which we populate most of our diverse systems, and authenticating using LDAP doesn’t mean you’re automatically authorised to use any of those particular systems.
We did look at that Jason, and it’s promising, but for reasons I won’t go into (it’s complicated) we can’t change the LDAP schema to create an attribute to designate Mattermost users, at least not in the short term. Going forward, should we find no way around it we may have to, but for now it’s not an option. Thanks again for your help.