Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LDAP problem with Harbor 1.1.0 #2034

Closed
roldancer opened this issue Apr 17, 2017 · 23 comments
Closed

LDAP problem with Harbor 1.1.0 #2034

roldancer opened this issue Apr 17, 2017 · 23 comments

Comments

@roldancer
Copy link

Hi All, We had Harbor 0.5.0 working properly with Active Directory (LDAP) but after migrating to Harbor 1.1.0 LDAP integration is not working I get the following error.

Apr 17 17:34:27 172.19.0.1 ui[20184]: 2017-04-17T15:34:27Z [DEBUG] [authenticator.go:59]: Current AUTH_MODE is ldap_auth
Apr 17 17:34:27 172.19.0.1 ui[20184]: 2017-04-17T15:34:27Z [DEBUG] [ldap.go:145]: one or more ldapFilter: FILTER_DELETED_FOR_SECURITY_REASONS
Apr 17 17:34:27 172.19.0.1 ui[20184]: 2017-04-17T15:34:27Z [DEBUG] [ldap.go:280]: username:,email:[email protected]
Apr 17 17:34:27 172.19.0.1 ui[20184]: 2017-04-17T15:34:27Z [ERROR] [ldap.go:97]: Can't import user , error: duplicate_mailbox
Apr 17 17:34:27 172.19.0.1 ui[20184]: 2017-04-17T15:34:27Z [ERROR] [base.go:64]: Error occurred in UserLogin: can't import user , error: duplicate_mailbox

Any idea ?

@ericallen
Copy link

ericallen commented Apr 17, 2017

I ran into the same problem. I was using sAMAccountName for the ldap uid. I changed it to cn and it was able to find the user name. It seems to be in harbor/src/common/utils/ldap/ldap.go lines 204-218 that LDAP attributes are parsed but only uid, cn, mail, and email. sAMAccountName isn't in the list so it never parses the attribute. At login, the user is successfully authenticated but it is not able to get the sAMAccountName attribute for the username so the attempt is rejected.

I would think in adding a case for sAMAccountName would solve the issue. Something like

for _, ldapEntry := range result.Entries {
		var u models.LdapUser
		for _, attr := range ldapEntry.Attributes {
			val := attr.Values[0]
			switch attr.Name {
			case ldapConfs.LdapUID:
				u.Username = val
			case "uid":
				u.Realname = val
			case "cn":
				u.Realname = val
			case "mail":
				u.Email = val
			case "email":
				u.Email = val
                       case "samaccountname":
                               u.Email = val
			}
		}
		ldapUsers = append(ldapUsers, u)
	}

@ywk253100
Copy link
Contributor

@roldancer Could you provide your LDAP configuration in harbor.cfg?

@reasonerjt
Copy link
Contributor

@ericallen could you try to set the UID as "samaccountname" and retry?

@roldancer
Copy link
Author

roldancer commented Apr 18, 2017

Hi, We don't use attribute sAMAccountName, by the way this ldap configuration was working properly with Harbor 0.5.0 ...

##By default the auth mode is db_auth, i.e. the credentials are stored in a local database.
#Set it to ldap_auth if you want to verify a user's credentials against an LDAP server.
auth_mode = ldap_auth

#The url for an ldap endpoint.
ldap_url = ldap://MY_HOST_LDAP:389

#A user's DN who has the permission to search the LDAP/AD server.
#If your LDAP/AD server does not support anonymous search, you should configure this DN and ldap_search_pwd.
ldap_searchdn = uid=USER,ou=Administradores,o=REAL_MADRID

#the password of the ldap_searchdn
ldap_search_pwd = [LDAP_PASSWORD]

#The base DN from which to look up a user in LDAP/AD
ldap_basedn = o=REAL_MADRID

#Search filter for LDAP/AD, make sure the syntax of the filter is correct.
ldap_filter = (&(objectClass=inetOrgPerson)(isMemberOf=ou=global-paas-openshift,ou=roles,ou=groups,ou=ALM,cn=SERENITY,o=REAL_MADRID))

The attribute used in a search to match a user, it could be uid, cn, email, sAMAccountName or other attributes depending on your LDAP/AD

ldap_uid = corpAliasLocal

#the scope to search for users, 1-LDAP_SCOPE_BASE, 2-LDAP_SCOPE_ONELEVEL, 3-LDAP_SCOPE_SUBTREE
ldap_scope = 3

@ywk253100
Copy link
Contributor

ywk253100 commented Apr 18, 2017

Could you set the ldap_uid as corpaliaslocal and try again? Do these on configuration tab of web UI .

@roldancer
Copy link
Author

I did that but it doesn't work, for some reason my user can login but with admin role ...

@ywk253100
Copy link
Contributor

What do you mean by "for some reason my user can login but with admin role"? Does it mean only admin user can login?
What are the logs now?

@gavinbunney
Copy link

gavinbunney commented Apr 19, 2017

@ywk253100 we are facing the same issue as @roldancer described.

harbor.cfg:

auth_mode = ldap_auth
ldap_url = ldap://dc.mydomain.com
ldap_searchdn = <ldap-user>
ldap_search_pwd = <password>
ldap_basedn = ou=GWUsers,dc=mydomain,dc=com
ldap_filter = (objectCategory=Person) 
ldap_uid = sAMAccountname
ldap_scope = 3 
ldap_timeout = 5

I've attempted to use different ldap_uid values but as our AD uses sAMAccountname they all fail to authenticate. I've tried setting the ldap_uid value through the web-ui back to sAMAccountname but still the same error persists:

[DEBUG] [authenticator.go:59]: Current AUTH_MODE is ldap_auth
[DEBUG] [ldap.go:145]: one or more ldapFilter: (&(objectCategory=Person)(sAMAccountName=gbunney))
[DEBUG] [ldap.go:280]: username:,email:[email protected]
[ERROR] [ldap.go:97]: Can't import user , error: duplicate_mailbox
[ERROR] [base.go:64]: Error occurred in UserLogin: can't import user , error: duplicate_mailbox

@reasonerjt
Copy link
Contributor

@gavinbunney I believe the workaround is to set the value of ldap_uid in lowercase, could you update it via ui and retry?

@gavinbunney
Copy link

Tried that :) same error:

[DEBUG] [authenticator.go:59]: Current AUTH_MODE is ldap_auth
[DEBUG] [ldap.go:145]: one or more ldapFilter: (&(objectCategory=Person)(samaccountname=gbunney))
[DEBUG] [ldap.go:280]: username:,email:[email protected]
[ERROR] [ldap.go:97]: Can't import user , error: duplicate_mailbox
[ERROR] [base.go:64]: Error occurred in UserLogin: can't import user , error: duplicate_mailbox

Also tried various combinations of case to check for case-sensitiveness.

@gavinbunney
Copy link

gavinbunney commented Apr 19, 2017

Note: Anyone else facing this issue, don't do this 🥇 - just attempting to find the cause

As an attempt to fix this, I tried to delete an affected user from the mysql database, and it then allows the user in (sort of). The user record created has no username - after you logout and back in, the user then assumes the role of an admin.

Prior to delete:

mysql> select user_id, username, email, realname, comment from user;
+---------+-------------+---------------------------+----------------+-----------------------+
| user_id | username    | email                     | realname       | comment               |
+---------+-------------+---------------------------+----------------+-----------------------+
|       1 | admin       | [email protected]         | system admin   | admin user            |
|       2 | anonymous   | [email protected]     | anonymous user | anonymous user        |
|       8 | gbunney     | [email protected]      | gbunney        | registered from LDAP. |
+---------+-------------+---------------------------+----------------+-----------------------+

After delete and relogging in:

mysql> select user_id, username, email, realname, comment from user;
+---------+-------------+---------------------------+----------------+-----------------------+
| user_id | username    | email                     | realname       | comment               |
+---------+-------------+---------------------------+----------------+-----------------------+
|       1 | admin       | [email protected]         | system admin   | admin user            |
|       2 | anonymous   | [email protected]     | anonymous user | anonymous user        |
|       9 |             | [email protected]      | Gavin Bunney   | from LDAP.            |
+---------+-------------+---------------------------+----------------+-----------------------+

This illustrates the fact of the ldap adapter not retrieving the username correctly.

Note: this was an upgrade from 0.5 to 1.1.

@ericallen
Copy link

ericallen commented Apr 19, 2017

It looks like they are limited down the ldap attributes that are returned back to uid, cn,mail,email. So if you are using anything else it will not be able to look it up.

harbor/src/common/utils/ldap/ldap.go
line 34
var attributes = []string{"uid", "cn", "mail", "email"}
then are only checking those variables in 204-222 they are checking those values to match them against the internal user.

for _, ldapEntry := range result.Entries {
		var u models.LdapUser
		for _, attr := range ldapEntry.Attributes {
			val := attr.Values[0]
			switch attr.Name {
			case ldapConfs.LdapUID:
				u.Username = val
			case "uid":
				u.Realname = val
			case "cn":
				u.Realname = val
			case "mail":
				u.Email = val
			case "email":
				u.Email = val
			}
		}
		ldapUsers = append(ldapUsers, u)
	}

	return ldapUsers, nil

Using anything other than one of those attributes will end up failing because it never has ldap return those attributes.

@roldancer
Copy link
Author

@gavinbunney I have the same problem ....

@reasonerjt
Copy link
Contributor

We will have a fix for this issue.

@fduranti
Copy link

Same problem here and also a strange behaviour. If I remove an user from being admin he still get the admin permission (and when logging in the user see itself as admin in the right corner).
Any idea when a fix will be officially available?

@reasonerjt
Copy link
Contributor

@fduranti are you using AD?
Are you seeing the admin permission issue with non-ldap setting?

@fduranti
Copy link

tried only with ad. I've logged on with an ad user and it was not administrator.
added admin right to that user, logged back and in the right corner i see admin (not the user name)
removed admin right, loggeb back in and the user was still admin
Could be related to the fact that username is not imported into the database?

@stuclem
Copy link
Contributor

stuclem commented Apr 20, 2017

Proposed release note entry:


  • LDAP authentication issue after upgrading from version 0.5 to 1.1. #2034
    If you upgrade from Harbor 0.5 to version 1.1, and if you use LDAP authentication to manage user access, some existing users can no longer log in. VMware is working to resolve the issue.

@reasonerjt does this cover it? Thanks!

@reasonerjt
Copy link
Contributor

reasonerjt commented Apr 20, 2017

"If you use AD as LDAP server, you may have issue logging in" @stuclem

@stuclem
Copy link
Contributor

stuclem commented Apr 25, 2017

@reasonerjt apologies for the delay, I was on vacation. It looks like you updated the release note already.

@reasonerjt reasonerjt added this to the Sprint 7 milestone Apr 26, 2017
@reasonerjt
Copy link
Contributor

The issue has been fixed and please use 1.1.1-rc1

@cbarzu
Copy link

cbarzu commented Apr 27, 2017

I confirm that 1.1.1-rc1 solved the problem for us !

@gavinbunney
Copy link

Validated this is working on my end as well - thanks!

39bee4f33728e1f54402d858540d373c-weekend-update-high-five

@stuclem stuclem removed the kind/note label May 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants