Rocket.chat: No login possible after upgrading to 0.59.3 / LDAP pagination error

[mottobug]

Description:

Server Setup Information:

• Version of Rocket.Chat Server: 0.59.3
• Operating System: Linux
• Deployment Method(snap/docker/tar/etc): docker
• Number of Running Instances: 1
• DB Replicaset Oplog:
• Node Version:

Steps to Reproduce:

After upgrade no new login is possible. Trying to login with valid credentials results in this error message:

I20171201-10:01:28.101(0) LDAP ➔ Search.info Searching user xxx
I20171201-10:01:28.102(0) LDAP ➔ Search.debug searchOptions { filter: '(&(&(objectclass=inetorgperson)(uid=#{username}))(sAMAccountName=xxx))', scope: 'sub', sizeLimit: 1000, paged: { pageSize: 250, pagePause: false } }
I20171201-10:01:28.104(0) LDAP ➔ Search.debug BaseDN ou=users,dc=xxx,dc=xxx
I20171201-10:01:28.136(0) Meteor ➔ method UserPresence:online -> userId: xxx , arguments: {}
I20171201-10:01:28.254(0) rocketchat_logger rocketchat_logger.js:375 LDAP ➔ Search.error { [PagedError: missing paged control] name: 'PagedError' }
I20171201-10:01:28.256(0) rocketchat_logger rocketchat_logger.js:375 LDAPHandler ➔ error { [PagedError: missing paged control] name: 'PagedError' }

We are using LDAP wich worked fine until the update from 0.57.x to 0.59.3.

We've tried changing several of the new pagination options without success.

Expected behavior:

Actual behavior:

Relevant logs:

[alexmsierra]

+1

[graywolf336]

@rodrigok has this issue been fixed? As I know there was some recent work on the LDAP pagination.

[alexmsierra]

I have updated to 0.59.4 and I can confirm that the issue is still there.

[rodrigok]

@mottobug and @alexmsierra can you show me your LDAP pagination config? The Search Page Size and Search Size Limit located under User Search section.

[alexmsierra]

Hi @rodrigok,

[rodrigok]

@alexmsierra Can you test pass 0 to Search Page Size to disable pagination?

[alexmsierra]

@rodrigok

This seems to solve the issue at hand but I have to see how I solve the new error.
Also, I notice that the memberOf LDAP filters that I had, are missing after the upgrade.

Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAPHandler ➔ info#033[39m Init LDAP login <username>
Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAP ➔ Connection.info#033[39m Init setup
Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAP ➔ Connection.info#033[39m Connecting ldap://127.0.0.1:389
Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAP ➔ Connection.info#033[39m LDAP connected
Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAP ➔ Bind.info#033[39m Binding UserDN cn=xxx,dc=xxx
Dec  6 13:18:33 <hostname> rocketchat: {"name":"ldapjs","component":"client","hostname":"<hostname>","pid":7141,"clazz":"Client","ldap_id":"288__ldap://127.0.0.1:389","level":20,"msg":"connected after 1 attempt(s)","time":"2017-12-06T12:18:33.154Z","v":0}
Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAP ➔ Search.info#033[39m Searching user <username>
Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAP ➔ Search.info#033[39m Search result count 1
Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAP ➔ Auth.info#033[39m Authenticating cn=xxxx,ou=xxxx,ou=xxxx,ou=xxxx,ou=xxxx,dc=xxx,dc=xxx
Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAP ➔ Auth.info#033[39m Authenticated cn=xxxx,ou=xxxx,ou=xxxx,ou=xxxx,ou=xxxx,dc=xxx,dc=xxx
Dec  6 13:18:33 <hostname> rocketchat: #033[34mLDAPHandler ➔ info#033[39m User does not exist, creating
Dec  6 13:18:33 <hostname> rocketchat: rocketchat_logger rocketchat_logger.js:375 #033[31mLDAPSync ➔ error#033[39m Error creating user { [Error: Email already exists. [403]]
Dec  6 13:18:33 <hostname> rocketchat: isClientSafe: true,
Dec  6 13:18:33 <hostname> rocketchat: error: 403,
Dec  6 13:18:33 <hostname> rocketchat: reason: 'Email already exists.',
Dec  6 13:18:33 <hostname> rocketchat: details: undefined,
Dec  6 13:18:33 <hostname> rocketchat: message: 'Email already exists. [403]',
Dec  6 13:18:33 <hostname> rocketchat: errorType: 'Meteor.Error' }
Dec  6 13:18:34 <hostname> rocketchat: #033[34mLDAP ➔ Search.info#033[39m Idle
Dec  6 13:18:34 <hostname> rocketchat: #033[34mLDAP ➔ Connection.info#033[39m Disconecting
Dec  6 13:18:34 <hostname> rocketchat: #033[34mLDAP ➔ Search.info#033[39m Closed

[rodrigok]

@alexmsierra Where that filter was located? In group filter? Can you share more information, like if the configuration is missing in your configuration, or if it's configured correctly but is not been executed as expected?

[alexmsierra]

It was a user search filter.

It seems that it is not missing since I found this in the database:

{ "_id" : "LDAP_User_Search_Filter", "type" : "string", "enableQuery" : "{\"_id\":\"LDAP_Enable\",\"value\":true}", "group" : "LDAP", "section" : "User Search", "packageValue" : "(objectclass=*)", "valueSource" : "meteorSettingsValue", "hidden" : false, "blocked" : false, "sorter" : 17, "i18nLabel" : "LDAP_User_Search_Filter", "i18nDescription" : "LDAP_User_Search_Filter_Description", "ts" : ISODate("2017-12-01T09:37:45.303Z"), "_updatedAt" : ISODate("2017-12-01T15:50:00.667Z"), "createdAt" : ISODate("2017-12-01T09:18:54.442Z"), "value" : "(&(objectCategory=person)(objectclass=user))", "meteorSettingsValue" : "(&(objectCategory=person)(objectclass=user)(|(memberOf=CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx)(memberOf=CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx)))" }

My user search filter was (&(objectCategory=person)(objectclass=user)(|(memberOf=CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx)(memberOf=CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx))) and it was configured in the web interface when rocket.chat was installed.

Somewhere between the update from 0.58.X to 0.59.3 or 0.59.4 it went missing from the web interface.
Also, I am certain that the filter is not applied since we now have in rocket.chat users from Active Directory that are not part of the specified security groups.

This is what I have now as a user filter in the web interface.

[rodrigok]

Can you change your filter to the old value? Seems it was a migration problem. That solves your problem?

[alexmsierra]

Changing the filter in the web interface solved the issue.

[alexmsierra]

I also noticed that with the default value for Username Field under Sync / Import which by default is sAMAccountName, the sAMAccountName value from LDAP is not mapped to the username field in rocket.chat.

This is the log:

Dec  6 15:36:24 <hostname> rocketchat: #033[34mLDAP ➔ Search.debug#033[39m BaseDN dc=local
Dec  6 15:36:24 <hostname> rocketchat: #033[34mLDAP ➔ Search.info#033[39m Search result count 1
Dec  6 15:36:24 <hostname> rocketchat: #033[34mLDAP ➔ Auth.info#033[39m Authenticating cn=xxxx,ou=xxxx,ou=xxxx,ou=xxxx,ou=xxxx,dc=xxx,dc=xxx
Dec  6 15:36:24 <hostname> rocketchat: #033[34mLDAP ➔ Auth.info#033[39m Authenticated cn=xxxx,ou=xxxx,ou=xxxx,ou=xxxx,ou=xxxx,dc=xxx,dc=xxx
Dec  6 15:36:24 <hostname> rocketchat: #033[34mLDAPHandler ➔ debug#033[39m userQuery { username: '' }
Dec  6 15:36:24 <hostname> rocketchat: #033[34mLDAPHandler ➔ info#033[39m User does not exist, creating
Dec  6 15:36:24 <hostname> rocketchat: #033[34mLDAPSync ➔ debug#033[39m user.name changed to: Alexandru Marinescu
Dec  6 15:36:24 <hostname> rocketchat: #033[34mLDAPSync ➔ debug#033[39m New user data { email: '[email protected]' }
Dec  6 15:36:24 <hostname> rocketchat: rocketchat_logger rocketchat_logger.js:375 #033[31mLDAPSync ➔ error#033[39m Error creating user { [Error: Email already exists. [403]]

As you can see the debug#033[39m userQuery { username: '' } username field is blank.

The workaround I found for this was to leave the Username Field empty, so the username entered when authenticating in the web interface is used by rocketchat.

I realize this might not work for people who authenticate with email address or other LDAP fields.

[rodrigok]

@alexmsierra That log indicates that wasn't possible to get the username from your LDAP user as you can see here.

Are you sure that field sAMAccountName exists in your LDAP records?

[alexmsierra]

Yes, I checked and it exists and it has the correct value.

This is the result of the ldapsearch

dn: cn=xxx,ou=xxx,ou=xxx,ou=xxx,ou=xxx,dc=xxx
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: USER
cn: xxx xxx
sn: xxx
c: xxx
l: xxx
INSTANCETYPE: 4
WHENCREATED: xxx
WHENCHANGED: xxx
displayName: xxx xxx
USNCREATED: xxx
MEMBEROF: CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx
MEMBEROF: CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx
MEMBEROF: CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx
MEMBEROF: CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx
USNCHANGED: xxx
co: xxx
DEPARTMENT: xxx
COMPANY: xxx
name: xxx
OBJECTGUID:: xxx
USERACCOUNTCONTROL: xxx
BADPWDCOUNT: x
CODEPAGE: x
COUNTRYCODE: xxx
BADPASSWORDTIME: xxx
LASTLOGON: xxx
SCRIPTPATH: xxx
PWDLASTSET: xxx
PRIMARYGROUPID: xxx
OBJECTSID:: xxx
ACCOUNTEXPIRES: xxx
LOGONCOUNT: xxx
SAMACCOUNTNAME: POPULATED
SAMACCOUNTTYPE: xxx
USERPRINCIPALNAME: [email protected]
LOCKOUTTIME: 0
OBJECTCATEGORY: CN=Person,CN=Schema,CN=Configuration,DC=xxx,DC=xxx
mail: [email protected]

[rodrigok]

Can you try to change your sAMAccountName to uppercase (SAMACCOUNTNAME) at your settings and try again?

[alexmsierra]

Switching to uppercase (SAMACCOUNTNAME) did the trick.

[rodrigok]

Awesome, so the issues here seems to be configuration issues only.

I'll close this issue, let me know if you still have problems and we open it again.

Thanks