jonmbake / discourse-ldap-auth Goto Github PK

New discourse standalone installation, local hosted, version: v2.3.0.beta9 +330, all settings are default.
On LDAP create account or login nginx show 502 error on
http://forum.domain.ru/auth/ldap/callback.
Is there anything I can do to fix it?

LDAP plugin settings (I tried different ones, I tested this settings with ldap client):

ldap user create mod: auto
ldap lookup users by: email (#tried username too)
ldap hostname: srv01.local.org
ldap port: 636
ldap method: tls
ldap base: cn=users,cn=accounts,dc=msk,dc=domain,dc=ru
ldap uid: uid=system,cn=sysaccounts,cn=etc,dc=msk,dc=domain,dc=ru
ldap bind dn: uid=system,cn=sysaccounts,cn=etc,dc=msk,dc=domain,dc=ru
ldap password: password
ldap filter: (&(objectClass=inetOrgPerson)(employeeType=staff))

Nginx log:

2019/05/14 08:10:10 [error] 59#59: *91 upstream prematurely closed connection while reading
response header from upstream, client: 192.168.65.70, server: _, request: "POST
/auth/ldap/callback HTTP/1.1", upstream: "http://127.0.0.1:3000/auth/ldap/callback", host: 
"forum.domain.ru", referrer: "http://forum.domain.ru/auth/ldap"

production.log:

Started GET "/auth/ldap" for 127.0.0.1 at 2019-05-14 08:18:49 +0000
(ldap) Setup endpoint detected, running now.
(ldap) Request phase initiated.
Started POST "/auth/ldap/callback" for 127.0.0.1 at 2019-05-14 08:19:10 +0000
(ldap) Setup endpoint detected, running now.
(ldap) Callback phase initiated.

unicorn:

Deprecation warning: please give :encryption option as a Hash to Net::LDAP.new
E, [2019-05-14T08:19:41.761492 #65] ERROR -- : worker=3 PID:206 timeout (31s > 30s), killing
E, [2019-05-14T08:19:41.784454 #65] ERROR -- : reaped #<Process::Status: pid 206 SIGKILL (signal 9)> worker=3
I, [2019-05-14T08:19:59.188376 #2320]  INFO -- : worker=3 ready

I'm wondering if it's possible to modify the login screen popup. I looked through all the files in this repo and for the life of me couldn't figure out where to change anything. Maybe I just don't know how Discourse plugins work. I need a way to add a "Register" button to the page (linking to an external site) and to change the title from "LDAP Authentication" to something else.

Also is there any reason it couldn't open in a new tab instead? Seems less intrusive that way.

In #37, we had to remove the button icon due to a breaking change in Discourse: discourse/discourse@03deda2. We should try and add it back.

Hi Jon,

we've made the experience that users misunderstand the button "Login with LDAP" as a headline. They try to login with der LDAP credentials in the form fields below. After some tries they finally found out that they have to click the button.

Is it possible to improve the design of the overlay to avoid this?

Best regards
XL

Hello everyone,

I currently try to configure Discourse to only allow users in a specific ldap group to log in.

My plugin configuration:
ldap enabled: true
ldap hostname: the hostname of my ldap server
ldap port: 389
ldap method: plain
ldap base: the base of my ldap server
ldap uid: userPrincipalName
ldap bind dn: Nothing
ldap password: Nothing
ldap filter: (&(userPrincipalName=%{username})(memberOf=cn=[the name of the required group],ou=....,[base]))

When using this configuration, nobody can log in to the forum. When I use the bind dn and password, everybody can log in.
I also tried this filter without success (copied from my ldap servers filter): (&(&(&(userPrincipalName=%{username})(memberOf=[dn of the group]))))

What do I have to configure, to only allow users in that specific group to log in?

I didn't found any errors or indicators in the log. Please help!

Thanks fou your help and attention!

ldap_password is displayed as a plain text input on the configuration screen. It should display as a password input, where the actual value is obscured.

Hi, I'm sorry if I have just misunderstood the docs, but I'm a little confused how to configure the
ldap lookup users by setting. Our AD has user's email addresses stored in an attribute called mail (not email). I now have uid set to mail and ldap lookup users by set to email but LDAP login still fails.

I setup a Discourse server on Yunohost and I'd like only a Yunohost (LDAP) users to login. I would like to set Discourse to "invite only" mode to disable public registration (and the "Registration" button) itself, but I'd like users to be created using LDAP. Would it be possible to override "invite only" setting for LDAP users?

I'm trying to use your plugin with Bitnami Docker Discourse.

For reference: https://github.com/bitnami/bitnami-docker-discourse/issues/111

Short version: No matter how I install the plugin (e.g. in Dockerfile or via shell script with git clone) I am encountering an exception:

nami    TRACE Error: Error executing 'postInstallation': rake aborted!
LoadError: cannot load such file -- /opt/bitnami/discourse/plugins/discourse-ldap-auth/lib/ldap_user
/opt/bitnami/discourse/plugins/discourse-ldap-auth/plugin.rb:14:in `require_relative'
/opt/bitnami/discourse/plugins/discourse-ldap-auth/plugin.rb:14:in `activate!'
/opt/bitnami/discourse/lib/plugin/instance.rb:486:in `instance_eval'
/opt/bitnami/discourse/lib/plugin/instance.rb:486:in `activate!'
lib/discourse.rb:171:in `block in activate_plugins!'
lib/discourse.rb:168:in `each'
lib/discourse.rb:168:in `activate_plugins!'
/opt/bitnami/discourse/config/application.rb:261:in `<class:Application>'
/opt/bitnami/discourse/config/application.rb:58:in `<module:Discourse>'
/opt/bitnami/discourse/config/application.rb:57:in `<top (required)>'
/opt/bitnami/discourse/Rakefile:7:in `require'
/opt/bitnami/discourse/Rakefile:7:in `<top (required)>'
/opt/bitnami/discourse/vendor/bundle/ruby/2.5.0/gems/rake-12.3.2/exe/rake:27:in `<top (required)>'
/opt/bitnami/ruby/bin/bundle:23:in `load'
/opt/bitnami/ruby/bin/bundle:23:in `<main>'
(See full trace by running task with --trace)

    at runProgram (/opt/bitnami/nami/node_modules/nami-utils/lib/os/run-program.js:223:14)
    at Object.runProgram (/opt/bitnami/nami/node_modules/nami-utils/lib/os/index.js:63:12)
    at Object.$app.helpers.execute (/root/.nami/components/com.bitnami.ruby/helpers.js:44:7)
    at Object.$app.helpers.bundleExecute (/root/.nami/components/com.bitnami.ruby/helpers.js:62:8)
    at Object.<anonymous> (/opt/bitnami/nami/node_modules/lodash/index.js:51:276)
    at Object.$app.helpers.migrateDatabase (/root/.nami/components/com.bitnami.discourse/helpers.js:235:8)
    at Service.$app.postInstallation (/root/.nami/components/com.bitnami.discourse/main.js:58:18)
    at Service.runStep (/opt/bitnami/nami/node_modules/nami-core/lib/components/component.js:159:12)
    at _.each.step (/opt/bitnami/nami/node_modules/nami-core/lib/components/component.js:236:32)
    at r (/opt/bitnami/nami/node_modules/lodash/index.js:5:348)

After sshing into the container, I've determined that sometime during the rake ldap_user.rb is getting moved out from the lib subdirectory and into the parent plugin directory. It's unclear to me whether this is an issue cause with Bitnami, Plugin, or (more likely) something I'm doing incorrectly. Any help is greatly appreciated.

I'm using Freeipa to authenticate using LDAP when I sign in using LDAP I am unable to create an account instead the email field is blank and the create account button disabled.

Here is my LDAP User Schema since FreeIPA is slightly different sometimes.

 # LDAPv3
 # base <dc=freeside,dc=co,dc=uk (default) with scope subtree
 # filter: uid=kcoldron
 # requesting: ALL
 #
 
 # kcoldron, users, compat, freeside.co.uk
 dn: uid=kcoldron,cn=users,cn=compat,dc=freeside,dc=co,dc=uk
 objectClass: posixAccount
 objectClass: ipaOverrideTarget
 objectClass: top
 gecos: Kieran Coldron
 cn: Kieran Coldron
 uidNumber: 1602800010
 gidNumber: 1602800010
 loginShell: /bin/bash
 homeDirectory: /mnt/nfs/home/kcoldron
 ipaAnchorUUID:: ***
 uid: kcoldron
 
 # kcoldron, users, accounts, freeside.co.uk
 dn: uid=kcoldron,cn=users,cn=accounts,dc=freeside,dc=co,dc=uk
 givenName: Kieran
 sn: Coldron
 uid: kcoldron
 cn: Kieran Coldron
 displayName: Epictek
 initials: KC
 gecos: Kieran Coldron
 krbPrincipalName: [email protected]
 mail: [email protected]
 preferredLanguage: EN
 objectClass: top
 objectClass: person
 objectClass: organizationalperson
 objectClass: inetorgperson
 objectClass: inetuser
 objectClass: posixaccount
 objectClass: krbprincipalaux
 objectClass: krbticketpolicyaux
 objectClass: ipaobject
 objectClass: ipasshuser
 objectClass: ipaSshGroupOfPubKeys
 objectClass: mepOriginEntry
 loginShell: /bin/bash
 homeDirectory: /mnt/nfs/home/kcoldron
 krbCanonicalName: [email protected]
 ipaUniqueID: ***
 uidNumber: 1602800010
 gidNumber: 1602800010
 krbPasswordExpiration: ***
 krbLastPwdChange: ***
 memberOf: cn=ipausers,cn=groups,cn=accounts,dc=freeside,dc=co,dc=uk
 memberOf: ipaUniqueID=***,cn=hbac,dc=freeside
  ,dc=co,dc=uk

When a new user is created in the popup aparently the [en.login.ldap.name] is not defined. Tried to defined in the configuration files, but without success. Where is this actually defined?

Hi, I have a problem with install this plugin on my VM Debian with Discourse. You prefer install this in app.yml file but I haven't this file. I try via link https://docs.bitnami.com/aws/apps/discourse/configuration/install-plugins/ but I have a lot of errors. Can someone help me?

Another one issue - I wanted to make a half-auto registration. Meaning that an LDAP user can just log in any time (if it's account is Active), but an external (non-LDAP) user must be registered and confirmed by staff member. Is there any mechanism to do so?

Hi!

How can I help to translate user's visible part such as

auth_provider title: 'with LDAP',
message: 'Log in with your LDAP credentials',

?
I doesn't see this messages at /config/locales/

I'm getting the following warnings in the log after an upgrade to v2.1.0.beta5

This is just copy paste issue from that project https://github.com/punitkrjain/discourse-ldap-auth Your plugins were published almost a the same time so don't know who much closely you guys work on it.

It if very easy to login as other person if the plugin is on and LDAP has open registration. All you need to do is to create an account on LDAP that exists on discourse instance (via other auth methods) but not on LDAP.
In result you will be able to login and have full control over the persons account.
I tried the same with github auth and it is not possible as the discourse will indicate the account exists and will prompt you for new user registration with different username (usually adding 1 at the end).

I noticed when stealing identity, that the email hasn't change (the original user email was still there rather then email on ldap).
Maybe the idea would be to check against users email, and only when it matches allow authentication.

Discourse: v2.2.0.beta4 +353

When you open the page in browser you see only

Error: Undefined variable: "$fa-var-sitemap".
on line 5 of plugins/discourse-ldap-auth/auto_generated/plugin b5e97b66bal5dcff76b2524272bb34dd1df3b54c.css
>> content: $fa-var-sitemap;

Hi,

I am getting the following error when I run ./launcher rebuild app in the discourse docker image:

Bundled gems are installed into ./vendor/bundle.

I, [2016-01-12T16:36:08.438005 #36]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
rake aborted!
LoadError: cannot load such file -- ./lib/ldap_user
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.5/lib/active_support/dependencies.rb:274:in `require'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.5/lib/active_support/dependencies.rb:274:in `block in require'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.5/lib/active_support/dependencies.rb:240:in `load_dependency'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.5/lib/active_support/dependencies.rb:274:in `require'
/var/www/discourse/plugins/ldap/plugin.rb:14:in `activate!'
/var/www/discourse/lib/plugin/instance.rb:308:in `instance_eval'

Looks like the addition of this code:

 gem 'net-ldap', '0.3.1'
 gem 'omniauth-ldap', '1.0.4'

 +require 'yaml'
 +require './lib/ldap_user'
 +
  class LDAPAuthenticator < ::Auth::Authenticator
    def name
      'ldap'
    end

Maybe the issue.

Thanks.
-Scott

Hello everyone,

I sucessfully installed the LDAP auth plugin and registered an user with the plugin. I's kinda ugly to navigate to the url https://forum.example.com/mySubfolder/auth/ldap to be able to login with the account since you can't login through the default login button.

So I decided to use your tip When disabling Local Login and other authentication services, clicking the Login or Sign Up button will directly bring up the LDAP Login popup.

But since I configured this I got empty popups when trying to registering or loggin in:
Login:

Register:

There are no errors in the browser's console.

Here is the latest log, but it seems fine:
https://pastebin.com/qVAe37qL

Can you tell me what I am doing wrong?

Could possibly use something like: https://www.forumsys.com/tutorials/integration-how-to/ldap/online-ldap-test-server/, along with a framework like cypress.

The LDAP Login form looks quite old-styled.
Would it make sense to use the same styling as Discourse has?

Where I can change and edit this page? I want to add regulations for users on this page.

Please help

Hi,
We have discourse production 1.9.0 with ldap plugin from https://github.com/jonmbake/discourse-ldap-auth.git commit ccf5e36 (0.3.0).
We restored data from production to our staging server which is 2.2.0 discourse version with recent ldap plugin (0.4.0).
Unfortunately we are not able to authenticate with ldap even if ldap setting is same as before.
Please support.

Hello,

In our discourse install, we have been using email addresses as usernames. With the change in commit f15176f this causes breakage.

When a user logs in for the first time, they are given the prompt to set their email address and choose their display name.

When the user logs out, and logs back in, they are presented with this same new user dialogue, except they are informed the email address is in use already. Existing users created before this change are also unable to log in.

Reverting back to 0.3.5 allows the users to log back in.

hello

my discourse is running behing a nginx proxy. I can access discourse through url like : https://XXX.YYY.ZZ/forum
I had to install nginx on host and to redirect http(s) cnx to 2 sockets in /shared directory. The container's nginx has to listen to those sockets to receive packets.
I had to change the long polling parameter in discourse admin page.

I have a problem with this plugin. When I click on login button, discourse shows me a banner. I have to click on "login whith ldap".
Discourse shows me an other banner : https://xxx.yyy.zz/forum/auth/ldap
I wrote ldap login and password and click on sign in button.
Here is the problem. This redirects me to https://xxx.yyy.zz/auth/ldap/callback. The /forum subdirectory in the url is lost during the redirect. So it does not work.

note : I used this plugin without the /forum hack ; it works perfectly
note2 : I'am able to make it works by adding a this line to nginx conf
rewrite ^/auth/ldap/(.*)$ /forum/auth/ldap/$1 last;

In 0.3.0, a typo in SiteSettings was fixed. We added a fallback to ensure this wouldn't be a breaking change for existing users. Remove this fallback in the next major release.

Currently the Sign Up button redirects to the LDAP login page when Local Logins are disabled. Can we configure this behavior to point to an external URL if the LDAP service provides registration?

Hey, I'm having a strange issue while connecting to LDAP.
I suppose there is a problem because of LDAP Attribute names - there are no "e-mail" or "username", just "mail" and "name" .
Can you please update your plugin to give a possibility of using custom fields in LDAP?

In LDAP settings, for the "LDAP Filter" field, I'm using the following syntax:

memberOf=CN=Group,OU=Users,DC=Domain,DC=com

Authentication works for the user if that user is the only member of "Group". However, if more than one member is added to "Group", only the first user account on the group membership list is able to authenticate.

Hey there,

first I want to mention, thats great, that you guys did implement such a function for Discourse.

I found myself playing around with this and found, that you need a bind_dn if anonymous access to LDAP isn't allowed. In another application of me, I simply use the Loginname (userPrincipalName) as bind_dn. I tried to to that with your plugin, but no avail. Is it possible to have variable-names within the base_dn or password-field, so the values typed in are used instead of fixed values?

BR,
RaVoR

I cannot see anywhere to set this at all, as memberof will not work in most LDAP deployments for a standard ou, and a filter search on (cn=%{username}) could in theory retrieve things from any ou, this is quite required.

It would be nice to have a group sync between LDAP and Discourse, i.e. when creating a new user on Discourse, assign it to the Discourse groups matching the groups on LDAP. What would be the best way to do this?

Take the following DN as an example:

memberOf=CN=Discourse Users,OU=Groups,DC=ad,DC=foobar,DC=com

This results in the following error on the UI:

Sorry, there was an error authorizing your account. Perhaps you did not approve authorization?

And in the error logs:

(ldap) Authentication failure! invalid_credentials encountered.

/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/logster-1.2.11/lib/logster/logger.rb:94:in `add_with_opts'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/logster-1.2.11/lib/logster/logger.rb:51:in `add'
/usr/local/lib/ruby/2.5.0/logger.rb:545:in `error'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:162:in `log'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:483:in `fail!'
/var/www/discourse/plugins/discourse-ldap-auth/gems/2.5.1/gems/omniauth-ldap-1.0.5/lib/omniauth/strategies/ldap.rb:43:in `callback_phase'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:236:in `callback_call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:188:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:168:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:190:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:168:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:190:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:168:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:190:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:168:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:190:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:168:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:190:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:168:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:190:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/strategy.rb:168:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/omniauth-1.8.1/lib/omniauth/builder.rb:63:in `call'
/var/www/discourse/lib/middleware/omniauth_bypass_middleware.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/tempfile_reaper.rb:15:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/conditional_get.rb:38:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/head.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionpack-5.2.0/lib/action_dispatch/http/content_security_policy.rb:18:in `call'
/var/www/discourse/lib/middleware/anonymous_cache.rb:214:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/session/abstract/id.rb:232:in `context'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/session/abstract/id.rb:226:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionpack-5.2.0/lib/action_dispatch/middleware/cookies.rb:670:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionpack-5.2.0/lib/action_dispatch/middleware/callbacks.rb:28:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/activesupport-5.2.0/lib/active_support/callbacks.rb:98:in `run_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionpack-5.2.0/lib/action_dispatch/middleware/callbacks.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionpack-5.2.0/lib/action_dispatch/middleware/debug_exceptions.rb:61:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionpack-5.2.0/lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/logster-1.2.11/lib/logster/middleware/reporter.rb:31:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/railties-5.2.0/lib/rails/rack/logger.rb:38:in `call_app'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/railties-5.2.0/lib/rails/rack/logger.rb:28:in `call'
/var/www/discourse/config/initializers/100-quiet_logger.rb:16:in `call'
/var/www/discourse/config/initializers/100-silence_logger.rb:29:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionpack-5.2.0/lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionpack-5.2.0/lib/action_dispatch/middleware/request_id.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/method_override.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/actionpack-5.2.0/lib/action_dispatch/middleware/executor.rb:14:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/sendfile.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-mini-profiler-1.0.0/lib/mini_profiler/profiler.rb:174:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/message_bus-2.1.5/lib/message_bus/rack/middleware.rb:63:in `call'
/var/www/discourse/lib/middleware/request_tracker.rb:180:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/railties-5.2.0/lib/rails/engine.rb:524:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/railties-5.2.0/lib/rails/railtie.rb:190:in `public_send'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/railties-5.2.0/lib/rails/railtie.rb:190:in `method_missing'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/urlmap.rb:68:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/urlmap.rb:53:in `each'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-2.0.5/lib/rack/urlmap.rb:53:in `call'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:606:in `process_client'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:701:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:549:in `spawn_missing_workers'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:142:in `start'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/unicorn-5.4.0/bin/unicorn:126:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.5.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.5.0/bin/unicorn:23:in `<main>'

Workaround: put \20 in place of spaces.

memberOf=CN=Discourse\20Users,OU=Groups,DC=ad,DC=foobar,DC=com

This might be required for other fields as well, haven't tested it extensively.

H! Thanks for the excellent plugin.

Noticed or just can't find, that this plugin has no license? What license is the code released as?

Thanks!

I've successfully install the plugin according to the docs and configured it according to the readme.

I'm running v1.8.0.beta11 of discourse and 89fda80 of this plugin. Here are my settings:

I've tried the following cases and get the following issues:

Scenario 1. With an existing user of wesb that is the admin and was created w/o LDAP I tried to login with LDAP. The authentication is successful according to the LDAP and rails logs, but I get redirected to the signup page where the email is omitted and the signup button is disabled.

Clicking on Login with LDAP opens another browser window and I enter in my credentials.

The logs say the auth is successful, but I am brought to this screen instead of logging in.

Scenario 2. With a non-existent discourse user jayh I try to signup for a new account with LDAP. The authentication is successful according to the LDAP and rails logs, but I get redirected to the signup page where the email is omitted and the signup button is disabled.

When I run tail -f /var/discource/shared/standalone/log/rails/production.log I see the following:

Started GET "/auth/ldap" for 127.0.0.1 at 2017-04-28 21:30:48 +0000
(ldap) Setup endpoint detected, running now.
(ldap) Request phase initiated.
Started POST "/auth/ldap/callback" for 127.0.0.1 at 2017-04-28 21:30:57 +0000
(ldap) Setup endpoint detected, running now.
(ldap) Callback phase initiated.
Processing by Users::OmniauthCallbacksController#complete as HTML
  Parameters: {"username"=>"wesb", "password"=>"[FILTERED]", "provider"=>"ldap"}
  Rendered users/omniauth_callbacks/complete.html.erb (6.1ms)
Completed 200 OK in 12ms (Views: 2.7ms | ActiveRecord: 6.3ms)
Started GET "/u/hp.json?_=1493415042487" for 127.0.0.1 at 2017-04-28 21:30:57 +0000
Processing by UsersController#get_honeypot_value as JSON
  Parameters: {"_"=>"1493415042487"}
Completed 200 OK in 2ms (Views: 0.2ms | ActiveRecord: 0.0ms)

Has anyone see this issue or have any help on debugging?

hi all,
I'd like to change ldap user create mode setting to "list" but don't know where to put the ldap_user.yml file on my system.
I'm using ubuntu and installed discourse on /var/discourse.
any ideas? thanks in advance!

HI,

I noticed that in discourse, under the settings and LDAP bind password field is in plain text?
It would make a lot of sense to me, if its field type is password and password is masked from prying eye

Regards

For cases where you use self-signed certificates, it would be nice to allow those, else the ldap call fails in this situation.
Please add an option to configure this. Thanks!

Hello,
Using version 2.5.0.beta2
I am trying to set up discourse with Active Directory. When I use 'LDAP Authentication' I am getting redirected to the discourse home page. There are no window called 'Create new account'
It seems like 'auto' mode does not work.

When I create account with the same email then I can use AD credentials to log in and it is working fine. But I would like to have an account created automatically.

Any suggestions?

I've installed and configured the discourse-ldap-auth plugin and configured it at thus:

  ldap_enabled:
    default: true
  ldap_user_create_mode:
    default: 'auto'
  ldap_hostname:
    default: 'my.ldaps.com'
  ldap_port:
    default: 636
  ldap_method:
    default: 'tls'
  ldap_base:
    default: 'ou=people,dc=myServer,dc=net'
  ldap_uid:
    default: 'uid'
  ldap_bind_dn:
    default: 'uid=binduser,ou=people,dc=myServer,dc=net'
  ldap_password:
    default: '#########'
  ldap_filter:
    default: ''

In the app production.log I'm getting ldap_error: Net::LDAP::Error, no start_tls result
On my ldap server, I'm getting: slapd: closed (TLS negotiation failure)

Is it possible to increase the logging produced by discourse-ldap-auth?

Hi, first of all thanks for this great plugin, it was very easy to use.

My only comment is that when user creates a new account, it's currently using the full name (replacing spaces by _) as the discourse username. I'd like to have the ability to set it as the actually LDAP login so we can keep it consistent with the AD rules of my company.

Also, is there a way to restrict user registration only using the same LDAP username, password and e-mail address?

Thanks!

-Eugenio

I connect users from my work place via LDAP to Discourse. It take credentials from Active Directory. Currently username takes me from the uid field of AD (which is shown as a number) and I want to display displayName (name and surname) there. Where can I change it?

And my second question: Is there any possibility to set ldap login to default?

Hi,

not sure if this is solveable at all or just the way it is, but due to some odd circumstances some of our users have a wrong mail attribute in LDAP. If they change their e-mail address in Discourse and logout / login again, they are greeted with the new account window. So it seems the plugin now no longer finds the right account. So it seems the link between user name for login and the Discourse account is based on the e-mail address.

Any suggestions?

I'm trying to automate LDAP user creation via this plugin using Python (so that the new user added to LDAP doesn't have to click the "Create New Account" button after first login). I searched Discourse API: https://docs.discourse.org/#tag/Users/paths/~1users/post in order to see if there are any specific options on user that are being detected upon login and then altering them but I haven't found anything.

There are no problems logging the LDAP user in and then creating new user (with the Create New Account window that appears upon first login) via the UI, but is there any way to do it via Python code? Like, with requests library or maybe I have missed something in Discourse documentation?

So, in production.log, I have

Started GET "/auth/ldap" for x.y.z.a at 2016-07-19 20:21:13 +0000
(ldap) Setup endpoint detected, running now.
(ldap) Request phase initiated.
Started POST "/auth/ldap/callback" for x.y.z.a at 2016-07-19 20:21:20 +0000
(ldap) Setup endpoint detected, running now.
(ldap) Callback phase initiated.
(ldap) Authentication failure! invalid_credentials encountered.

but the error the LDAP login box gives

Sorry, there was an error authorizing your account. Perhaps you did not approve authorization?

In general, I'm slightly stymied at figuring out how to troubleshoot errors with LDAP authentication, so any suggestions on logs / errors would be appreciated. (Super glad to see this tho!)

Hi,
Is it possible to get profile photo from LDAP in to discourse? if yes, how can we achieve this?

Thank you.

The plugin worked great, then I upgraded to Discourse v1.9.0.beta14 +124
And now there is no more link to the LDAP login modal.

I'm getting the following errors in Discourse error logs, though I'm not sure if that's related to the problem

TypeError: Cannot read property 'addPreProcessor' of undefined
    at https://my.discourse.org/assets/plugin-third-party-ed07a7d5fac63719b5dadaef7c4b1315b94ebd83dabf18715bf688fbd3e5b43b.js:1:358
    at https://my.discourse.org/assets/plugin-third-party-ed07a7d5fac63719b5dadaef7c4b1315b94ebd83dabf18715bf688fbd3e5b43b.js:1:401

When looking at the auth options, and the docs regarding it there's the "none" option:

"Fail auth if the user account does not already exist. This is a good option for an Admin that creates accounts ahead of time."

I'm curious how you'd go about creating accounts beforehand. We'd like to import all active accounts before launching the service, and this'd be a pretty sweet deal for us.

Do we just create an account via User.create or? Don't see how the password would be handled if we did that.

Either way, thanks for making the plugin. LDAP integration is sort of a must for us.

So for example, when LDAP is used to Sign Up, the LDAP employee ID (e.g. 123456) becomes the username for that new user, instead of the actual name of the employee, (e.g. "Brandon"). We can see the full name is added properly (e.g. "Foster, Brandon"), but we would like the username to be the name of the employee instead of the employee ID.

More details on the way. My intention is to submit a pull request solving this issue.