I want to authenticate users over Active Directory, so I configured LDAP on the administration page of our openproject instance. After configuring I created a new user account with LDAP/AD-Authentication Mode. The users login name I have choosen is the same as the sAMAccountName in Active Directory. Moreover I granted Administrator priviledges.

But if I try to login with this name, the login is permitted. I always get an error: “Invalid user or password or the account is blocked due to multiple failed login attempts. If so, it will be unblocked automatically in a short time.”

What do I wrong here?

I think I figured it out. There appeared to be a bug where anytime you changed the LDAP settings, the password was removed. Perhaps it’s a mass assignment/strong parameter thing; I didn’t go deep enough into that. To get around that, you need to explicitly (only) set the password (again) after you set all other LDAP parameters.

The hard way to do that is to “rails db” and “update auth_sources set password=‘xxx’;” after you create the LDAP authentication source.

Let’s know if that solves your problem. It worked for me…I did it both ways.

Hi all,

I couldn’t reproduce the error from Doug but the one from Ho-Ki. Thus, I created a bug ticket for this: .

I hope we can fix this soon. Until then it is a possible workaround to explicitly set the password again, like Ho-Ki said.

Best,

Jonas

Thanks Doug,

The type field was blank, we applied the script update auth_sources set type = ’LdapAuthSource’; and everything worked! Now we know we have a bug on creating a “New Authentication Mode”.

This worked for me:

Name: Whatever you wanto for your name.
Host: IP/host name of your LDAP Service
Port: Port listening LDAP Service
LDAPS: Blank, at least you need it for secure authentication
Account: Enough with your username, no need to use username@mydomain or username\mydomain formats.
Password: Your pass
Base DN: Depends of your domain, e.g.: DC=domain_name,DC=top_level_domain,DC=country_level_domain. DC=mycompany,DC=org,DC=de
On-the-fly user creation= yes
Login = sAMAccountName
Firstname = givenName
Lastname = sN
Email = mail

Hi everyone,

I have gone through all steps that everyone has posted, and am still getting a ‘Invalid user or password’ error. Anyone have any ideas as to what to take a look at next?

• Running OpenProject CE 4.1.3 on CentOS 6.6 w/ MySQL2
• I have verified in MySQL that the type in auth_sources is set to ‘LdapAuthSource’
• Below are my LDAP Settings:

1. Name: Ldapname
2. Host: dc.company.example.org
3. Port: 389
4. LDAPS: not selected
5. Account: ldapservicename
6. Password: pass
7. Base DN: DC=company,DC=example,DC=org
8. On-the-fly user creation: selected
9. Login: sAMAccountName
10. First name: givenName
11. Last name: sN
12. Email: mail

• I have verified Base DN is correct for lookup using ldapsearch command
• Testing authentication method comes back with ‘Successful connection’
• These are the logs from /var/log/openproject-ce/production.log when attempting to login with an account that has LDAP Authentication set:

Started POST "/login" for 127.0.0.1 at 2015-06-23 12:05:34 -0500 Processing by AccountController#login as HTML Parameters: {"utf8"=>"✓", "authenticity_token"=>"O3ch3WHpb/5afZirOJm3mdM2Chqy/sUm+PCBNwWsrKI=", "back_url"=>"http%3A%2F%2Fopenproject.example.org%2Flogin", "username"=>"khoyt", "password"=>"[FILTERED]", "login"=>"Sign in"} OpenProject User: Anonymous Failed login for 'khoyt' from 127.0.0.1 at 2015-06-23 17:05:39 UTC Rendered account/_password_login_form.html.erb (3.4ms) Rendered hooks/login/_auth_provider.html.erb (0.0ms) Rendered account/_auth_providers.html.erb (0.3ms) Rendered account/login.html.erb within layouts/base (4.3ms) Rendered search/_mini_form.html.erb (0.5ms) Rendered hooks/login/_auth_provider.html.erb (0.1ms) Rendered account/_auth_providers.html.erb (0.3ms) Rendered account/_login.html.erb (3.1ms) Rendered layouts/_action_menu.html.erb (0.0ms) Completed 200 OK in 5054.0ms (Views: 20.5ms | ActiveRecord: 7.3ms)

Thanks everyone,

Ken

This may seem stupid, but try replacing

2. Host: dc.company.example.org

with

2. Host:

where is the actual ip address of dc.company.example.org

That was a problem that I ran into, but never resolved the “why” satisfactorily.

Hi Doug,

Thanks for the response! I tried using the IP Address of the DC, but unfortunately the issue persists.

Couple other things I tried were opening the firewall on the server, as well as disabling SELinux. Still no luck.

I guess I should have added that our business is running Microsoft Active Directory for LDAP Authentication, not sure if that makes any difference or not. I’m honestly thinking about setting up my own LDAP & OP sandbox at home and seeing if it will work. I will update when I have more information.

Thanks,

Ken

Everything looks good to me. I’m grasping at straws, here but …

• check “Administration -> Users -> ”khoyt" -> Authentication mode and make sure that it is (from your example) “Ldapname” and not INTERNAL.

• look at a packet capture

1. start interface packet capture from the command line

sudo tcpdump -s 0 -w /tmp/foo.pcap -i <interface|eth0> tcp port 389

1. attempt to login with an unknown username, correct username and an incorrect password, the correct username and password
2. hit in tcpdump window
3. then look at /tmp/foo.pcap with wireshark to see the actual reason that the request failed

Doug Perham wrote:

Everything looks good to me. I’m grasping at straws, here but …

• check “Administration -> Users -> ”khoyt" -> Authentication mode and make sure that it is (from your example) “Ldapname” and not INTERNAL.

• look at a packet capture

1. start interface packet capture from the command line
   […]
2. attempt to login with an unknown username, correct username and an incorrect password, the correct username and password
3. hit in tcpdump window
4. then look at /tmp/foo.pcap with wireshark to see the actual reason that the request failed

Hi Doug,

I finally figured out my issue, hooray!

First, I followed you directions in packet capturing, and here is something I noticed:

Lightweight Directory Access Protocol

• LDAPMessage bindResponse(1) invalidCredentials (80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1)

Basically this is telling me the Admin Bind response is returned with invalid credentials. What’s weird is these same creds work successfully with other products. Then I remembered back to my ldapsearch command, specifically what I used for the bind DN. Turns out the service account cn is “LDAP Service Name”, and the sAMAccountName is “ldapservicename”. After switching to the cn for the Account field in OpenProject, things starting working. Odd that it doesn’t work with the sAMAccountName, but I don’t think this would be considered a bug?

Thanks for your help Doug!

Ken

Hi,

I have a new OpenProject Installation via packager.io onto a Debian 8.0 64bit box. Installation worked without issues.

I have set up a LDAP Account to our MS-AD (Server 2012R2). Within wireshark I see that the LDAP Bind with the Specified User works, but the SearchRequest fails with:

LDAPMessage searchResDone(2) operationsError (000004DC: LdapErr: DSID-0C090748, comment: 
In order to perform this operation a successful bind must be completed on the connection., data 0, v2580) [0 results]

I have built a test-ruby script which works on the Debian box with Debian Packaged net-ldap package:

require 'net/ldap'

def initialize_ldap_con(ldap_user, ldap_password)
  options = { host: 'dc.domain.local',
                port: 389,
            }
  options.merge!(auth: { method: :simple, username: ldap_user, password: ldap_password })
  Net::LDAP.new options
end


ldap = initialize_ldap_con('DOMAIN\LDAPQUERY', "PASSWORD")

login_filter = Net::LDAP::Filter.eq("sAMAccountName", "testuser")
object_filter = Net::LDAP::Filter.eq('objectClass', '*')
treebase = "ou=TU,dc=intern,dc=tuwien,dc=ac,dc=at"

ldap.search(:base => treebase,
            :filter => login_filter & object_filter,
            :attributes => ["dn"] ) do |entry|
  puts "DN: #{entry.dn}"
  entry.each do |attribute, values|
    puts "   #{attribute}:"
    values.each do |value|
      puts "      --->#{value}"
    end
  end
end

p ldap.get_operation_result

That script works, but OpenProject fails. Has anyone any idea, what went wrong?

thanks
Philipp

Philipp Kolmann wrote:

Hi,

I have a new OpenProject Installation via packager.io onto a Debian 8.0 64bit box. Installation worked without issues.

I have set up a LDAP Account to our MS-AD (Server 2012R2). Within wireshark I see that the LDAP Bind with the Specified User works, but the SearchRequest fails with:

If you use 2012R2 AD you should use LDAPS and port 636
Account in format: DOMAIN\User

Hi,

Has someone got the final concrete resolution? I have tried every possible troubleshooting described here, but no luck. I have also updated the DB as - “auth_sources set type = ’LdapAuthSource”, that also is of no use.

It gives the same error - “Invalid user or password or the account is blocked due to multiple failed login attempts. If so, it will be unblocked automatically in a short time.”

Any other ideas as to what needs to be looked at in order to resolve the issue? Any help would be much appreciated.

Thanks,
Amit

Amit Sharma wrote:

Hi,

Has someone got the final concrete resolution? I have tried every possible troubleshooting described here, but no luck. I have also updated the DB as - “auth_sources set type = ’LdapAuthSource”, that also is of no use.

It gives the same error - “Invalid user or password or the account is blocked due to multiple failed login attempts. If so, it will be unblocked automatically in a short time.”

Any other ideas as to what needs to be looked at in order to resolve the issue? Any help would be much appreciated.

Thanks,
Amit

Hi Amit,

Could you share details about your environment with us? Some good things to know would be:

• OpenProject version
• Operating System
• Database software
• Your current LDAP settings (be sure to obfuscate things like username, password, etc.)

-Ken

Hi Ken,

OpenProject version - OpenProject 6.0.3 (MySql2)

Operating System - RHEL 7.2

Database software - MySql

Your current LDAP settings (be sure to obfuscate things like username, password, etc.) - !!

After entering these settings, if I test the connection, it says connection successful, but user wont authenticate. The logs’ file /opt/openproject/log/production.log also doesn’t list any thing. Is there any other parameter to enable logs debug for ldap ? Or any other file, in which we can pass these settings manually ?

Thanks in advance for your help.
-Amit

Hi Amit,

your screenshot got the answer already.
The “Attributes ” section needs to have valid LDAP/AD-attributes.
Simply entering your binding account name will not make the connection possible.
You will have to enter the attributes by which users of your domain will be referenced.
This could be “samAccountName” on a Windows-AD for example.
The rest (like Email, which is “mail” on LDAP) is optional.

Best regards,
Oliver

Hi Oliver,

We have tried entering - ‘samAccountName’ as well over there but no luck so far.

Is there any config file in the server that I can view these settings directly in?

Thanks,
Amit

Good day,

It seems that the password entering issue is not resolved yet.

For those on OP version 6.1.5, you still need to ensure that you enter the password when any changes are made to LDAP Authentication Settings.

Regards,

After having same trouble with new user accounts authenticating against AD i found this simple solution:

you don’t need to enable ‘on-the-fly user accounts’!

Create a new openproject user

membername = samaccountname = ‘windows username’
givenname, surename doesn’t matter
a valid email address

If you want to login with this new user now, you’ll get the well known error…
This is because the account has the status ‘invited’, not active!

You need to activate the new account. Therefore you need the valid email address above.
Go to the activation email, click the activation link, login with domain credentials and… Voila!, you are logged in.

From now, you can directly got to your openproject site an login with your domain creds.

cu

kk

Here is my working settings for a Zimbra LDAP integration:

Host: [zimbra intranet IP]
Port: 389
Account: uid=zimbra,cn=admins,cn=zimbra
Password: [ZImbra Root Password]

Attributes

Login: mail

The Login attribute is the one to build the query. Since I want user to login via email, I put the mail attribute here.

I went through a ton of posts with everyone asking and running into the same error over and over.  Everyone that posted solutions said it was working and recommended attribute names, but no one correctly outlined the procedure to getting it to work correctly with LDAP/AD.

 I'd figure I emphasize this as it took me a bit to figure out and the answer was right there in front of my screen the entire time.  Thanks kuno kette.

If anyone has their LDAP/AD connection set and it's successfully tested - make sure you invite your user and then have them click on the activation link from the email invitation. Then have them log in from that link. If you invite and the user goes to the main page to login - it won't work per the reason below that kuno kette had stated and it will produce the generic error.

kuno kette wrote:

After having same trouble with new user accounts authenticating against AD i found this simple solution:

you don’t need to enable ‘on-the-fly user accounts’!

Create a new openproject user

membername = samaccountname = ‘windows username’
givenname, surename doesn’t matter
a valid email address

If you want to login with this new user now, you’ll get the well known error…

This is because the account has the status ‘invited’, not active!

You need to activate the new account. Therefore you need the valid email address above.
Go to the activation email, click the activation link, login with domain credentials and… Voila!, you are logged in.

From now, you can directly got to your openproject site an login with your domain creds.

cu

kk

We use OpenProject 10.1.0 (PostgreSQL) on Ubuntu 18.04.3 LTS.
The following settings worked for us:

Name: AD
Host: [domain].local
Port: 389
Connection Encryption: none
Account: [domain]\LDAP-Read
Base DN: DC=[domain],DC=local
On-the-fly user creation: Yes
Username: sAMAccountName
First name: givenName
Last name: sn
Email: mail