Would it work on Windows Server 16?

[sebastianslutzky]

Hi,

We are currently running Team Edition on windows (https://docs.mattermost.com/install/prod-windows-2012.html)

Do you think we could get this LDAP integration to work on windows? or are there strong dependencies on linux?

thanks Sebastian

[Crivaledaz]

Hi,

Theoretically, Mattermost-LDAP should work with Windows because it is based on an apache server and MySQL/PostgreSQL which can be setup on Windows. However, I never test Mattermost LDAP on Windows, so I can't ensure it is the case in practice.

Obviously installation and configuration on Windows will be longer and time consuming, because automatic scripts are designed for Linux (shell).

So if you want to try, you should install a database server and an apache server. Then you need to create an oauth database and user like is performed by the installation script. After that, there is no big difference between Windows and Linux.

Nevertheless, Windows uses an Active Directory which is slightly different from the LDAP protocol. You can use LDAP on Windows, but if your company works with an AD you must have to adapt the oauth server. You can try changes suggested by @mmkeeper on issue #5.

Feel free to share your feedbacks here, I am interrested in the issue.

Regards,

Crivaledaz

[sebastianslutzky]

Thanks Crivaledaz.

We have forked this repo and will try to get the integration working. If we do, we'll send you a PR to review

Regards, Seb

[welfJasper]

Hey,

Currently trying to install this on Windows Server 2016 also. I'm working with:

MySQL Community Server 8.0 PHP 7.2.6 Apache HTTP Server 2.4 Mattermost 4.10

I went through the process of installing and configuring the database and apache server. I have also configured Mattermost to enable authentication with GitLab. Below are the configurations that I have on Mattermost:

GitLab Site URL: http://[apacheserver]:8000/resource.php User API Endpoint: http://[apacheserver]:8000/resource.php Auth Endpoint: http://[apacheserver]:8000/authorize.php Token Endpoint: http://[apacheserver]:8000/token.php Mattermost Site URL: http://chatserver:8065

I manage to authenticate successfully with LDAP and I can see that handleTokenRequest in token.php is being called and a token is being granted. I did an output in Response.php to print the Response Body that the server is sending back to the client and it looks correct to me.

{"access_token":"c6e4db4d962d12974b79534f4b184bc5967217a4","token_type":"Bearer","refresh_token":"c75d76e8b23bb6ec0f0c568db925880f87a710e2","scope":"api","created_at":1528198820}

However, it seems to fail at the redirection and I'm getting "Bad response from token reqeust" on the Mattermost client. I'm guessing this could be some configurations that I don't have set up correctly. I've also ensured that "EnableInsecureOutgoingConnections" on Mattermost is set to true. Perhaps this is something you have come across @Crivaledaz?

This is the error from the Mattermost log:

{"level":"error","ts":1528209783.5362,"caller":"api4/oauth.go:466","msg":"AuthorizeOAuthUser: Bad response from token request, response_body="}

Any help would be appreciated. Thanks

[mmkeeper]

In my case next condition did not work properly

AuthorizationCode.php: In the function validateRequest: if ($authCode["expires"] < time()) {

Try to remove it

[welfJasper]

Thanks for the suggestion but that didn't work I'm afraid. It seems anyway that I am getting an access token which I thought is only granted after the auth token is validated?

[Crivaledaz]

Hi,

@welfJasper I never had this kind of error before (or I don't remember). Can you try to request data by hand with the access token you get (ask for a new one for each test). On Linux the easiest way is to use the command below, but I don't know the curl equivalent on Windows.

curl --header "Authorization: Bearer ACCESS_TOKEN" http://example.com/oauth/resource.php

The access token is the token you got during authorization process (returned by token.php). Normally, you should get user data in JSON format like this :

{"id":1,"name":"Denis CLAVIER","username":"Crivaledaz","state":"active","avatar_url":"","web_url":"","created_at":"0000-00-00T00:00:00.000Z","bio":null,"location":null,"skype":"","linkedin":"","twitter":"","website_url":"","organization":null,"last_sign_in_at":"0000-00-00T00:00:00.000Z","confirmed_at":"0000-00-00T00:00:00.000Z","last_activity_on":null,"email":"user@email.com","theme_id":1,"color_scheme_id":1,"projects_limit":100000,"current_sign_in_at":"0000-00-00T00:00:00.000Z","identities":[{"provider":"ldapmain","extern_uid":null}],"can_create_group":true,"can_create_project":true,"two_factor_enabled":false,"external":false,"shared_runners_minutes_limit":null} 

However, for security purposes, the access token expires after 30 seconds and can be used only once. If you need more time to test, you should comment the if condition suggested by @mmkeeper.

For more information about Oauth process by hand, you can see issue #5.

Please do some tests and let me know your result,

Regards,

Crivaledaz

[welfJasper]

Hi @Crivaledaz

I was following the trend on issue #5 and did a simple Get request using Postman to resource.php with Access_Token in the database. That returns:

{"id":"2","name":"Jsp","username":"Jsp","state":"active","avatar_url":"","web_url":"","created_at":"0000-00-00T00:00:00.000Z","bio":null,"location":null,"skype":"","linkedin":"","twitter":"","website_url":"","organization":null,"last_sign_in_at":"0000-00-00T00:00:00.000Z","confirmed_at":"0000-00-00T00:00:00.000Z","last_activity_on":null,"email":"user@email.ie","theme_id":1,"color_scheme_id":1,"projects_limit":100000,"current_sign_in_at":"0000-00-00T00:00:00.000Z","identities":[{"provider":"ldapmain","extern_uid":null}],"can_create_group":true,"can_create_project":true,"two_factor_enabled":false,"external":false,"shared_runners_minutes_limit":null}

So it looks like things are fine on the oauth server end but when it's returned to the client it is where it is giving out. Using Fiddler, I see that a POST request is performed on /authorize.php?response_type=code... but is failing with a generic 500 on [chatserver]:8065/signup/gitlab/complete

It seems to be failing now with "[runtime error: invalid memory address or nil pointer dereference]" so it looks like something else has gone wrong but an access token is still being generated so I take it this is more on the client side being unhappy with the response that is coming back from the server?

[Crivaledaz]

I am not sure to understand when the error happen. You said /autorize.php page lead to an error 500. So are you able to perform authentication on the Oauth Server or not ?

On the other hand, an access token seems to be created. Is it the case when you use Oauth through the Mattermost login process ? If yes, the runtime error must be a parsing error of JSON data received from Oauth (ressource.php) like issue #20. Maybe you use a Mattermost version I didn't test and the Oauth output is not compliant anymore with. Which Mattermost version have you installed ? Can you try with Mattermost 4.9, which I'm sure Mattermost-LDAP is working with.

[welfJasper]

I'm using the latest version of Mattermost, which is 4.10.1

I mean that the error is occurring on the Mattermost client: http://[chatserver]:8065/signup/gitlab/complete. That's where the 500 error is appearing.

I just downloaded and installed a clean version of Mattermost 4.9 but continued using the same oauth server. This still produces the same error. So it looks like Mattermost just isn't liking the response from the oauth. But it looks like my json is the same as yours if I use the Access Token. Do you have any other ideas?

[Crivaledaz]

I saw that a new version was released, but I have not tested it yet. According to the changelog, it is possible Mattemost-LDAP is not compliant to Mattermost 4.10 because we can read : "Simplified Mattermost administration by supporting environment variables in GitLab Omnibus". I'm afraid they have changed JSON data expected by Mattermost. I will look at this, when I have a moment. To be sure, please keep using Mattermost 4.9 for the moment.

I looked carefully at your JSON output and I compared with mine. Data are almost the same, but in yours id is a string and in mine is an int. This little difference could be the reason why Mattermost have a runtime error, because it expects an int and not a string. However, I have no idea why your Oauth server returns an int for id.

Can you try to change the id value in resource.php file and force the int associated to your user (in your case 2). If it works, we will try to understand from where come from this error.

[welfJasper]

@Crivaledaz

Looks like that was the problem! Using Mattermost 4.9 and casting $assoc_id to an int did the job! I also had to set extern_uid to null as $data['dn'] does not exist but that might be more to do with our ldap configuration.

But it looks like the main thing was the casting of the id to an int instead of a string and the version! I tried looking into why it was returning as a string for me and not you but this might be something on our end. But thanks for all the help!

[Crivaledaz]

Super, I'm happy your problem is solved !

I think the data 'dn' is associated with LDAP and you certainly use an AD. This information could help companies which use AD.

For information, I have installed Mattermost 4.10.1 in a test environment and tried Mattermost-LDAP. A priori, it works fine. So you can update Mattermost to the latest version, if you want.

Thank you for your feedback, do not hesitate if you have another issue.

[Crivaledaz]

@sebastianslutzky So, Mattermost-LDAP seems to work well on Windows Server 2016. I close the issue because it is solved, but if you still encounter problems feel free to re-open it or create another one.