LDAP Channel Sync Works For 1st User, Breaks Subsequent


We have ldap authentication and user imports working 100% but when we tell it to sync groups and then make role and channel maps we have an issue where it will import the first user and assign them to the channel they need to be in based on the security group we have assigned to that channel in AD. Then after that it will import the next user without a full name but with a username and then not assign them to any channels and stop importing anyone after that. We see in the server logging included below that when it creates the channel it can add the first user to it that is not the owner of the channel but after that on the next person it tries to add it looks to see if the channel exists and believes it does not exist and then disconnects from trying to do anything further. Any assistance you can provide would be amazing and greatly appreciated.

Server Setup Information

  • Version of Rocket.Chat Server: 3.0.7
  • Operating System: Red Hat Linux
  • Deployment Method: Manual Install (CentOS)
  • Number of Running Instances: 1
  • DB Replicaset Oplog: ???
  • NodeJS Version: v12.14.0
  • MongoDB Version: 4.0.17
  • Proxy: nginx
  • Firewalls involved: Yes.

Any additional Information

I20200413-07:53:07.574(-5) server.js:204 LDAPSync ➔ info Syncing user data
I20200413-07:53:07.575(-5) server.js:204 LDAPSync ➔ debug user { email: undefined, id: ‘XXXXXXXXXXXXX’ }
I20200413-07:53:07.575(-5) server.js:204 LDAPSync ➔ debug ldapUser undefined
I20200413-07:53:07.580(-5) server.js:204 LDAPSync ➔ debug User role exists for mapping RCNetworking -> admin
I20200413-07:53:07.584(-5) server.js:204 LDAP ➔ Search.info Search result count 1
I20200413-07:53:07.585(-5) server.js:204 LDAPSync ➔ debug SECONDUSER is in RCNetworking group.
I20200413-07:53:07.586(-5) server.js:204 LDAPSync ➔ info Channel ‘IS_Networking’ doesn’t exist, creating it.
I20200413-07:53:07.589(-5) server.js:204 LDAPSync ➔ error errorClass [Error]: A channel with name ‘IS_Networking’ exists [error-duplicate-channel-name] at getValidRoomName (app/utils/lib/getValidRoomName.js:17:12) at createRoom (app/lib/server/functions/createRoom.js:48:9) at createRoomForSync (app/ldap/server/sync.js:280:15) at app/ldap/server/sync.js:320:12 at Function.
.map._.collect (/opt/Rocket.Chat/programs/server/npm/node_modules/underscore/underscore.js:205:24) at mapLDAPGroupsToChannels (app/ldap/server/sync.js:312:4) at syncUserData (app/ldap/server/sync.js:349:23) at app/ldap/server/sync.js:565:6 at SynchronousCursor.forEach (packages/mongo/mongo_driver.js:1107:16) at Cursor. [as forEach] (packages/mongo/mongo_driver.js:887:44) at sync (app/ldap/server/sync.js:555:10) at MethodInvocation.ldap_sync_now (app/ldap/server/syncUsers.js:24:3) at MethodInvocation.methodsMap. (app/lib/server/lib/debug.js:67:34) at maybeAuditArgumentChecks (packages/ddp-server/livedata_server.js:1771:12) at packages/ddp-server/livedata_server.js:719:19 at Meteor.EnvironmentVariable.EVp.withValue (packages/meteor.js:1234:12) at packages/ddp-server/livedata_server.js:717:46 at Meteor.EnvironmentVariable.EVp.withValue (packages/meteor.js:1234:12) at packages/ddp-server/livedata_server.js:715:46 at new Promise () at Session.method (packages/ddp-server/livedata_server.js:689:23) at packages/ddp-server/livedata_server.js:559:43 { isClientSafe: true, error: ‘error-duplicate-channel-name’, reason: “A channel with name ‘IS_Networking’ exists”, details: { function: ‘RocketChat.getValidRoomName’, channel_name: ‘IS_Networking’ }, message: “A channel with name ‘IS_Networking’ exists [error-duplicate-channel-name]”, errorType: ‘Meteor.Error’ }
I20200413-07:53:08.585(-5) server.js:204 LDAP ➔ Search.info Idle
I20200413-07:53:08.586(-5) server.js:204 LDAP ➔ Connection.info Disconecting
I20200413-07:53:08.587(-5) server.js:204 LDAP ➔ Search.info Closed

Also here is my group filter in case that is set up wrong:

Other than a user filter and group filter the rest of the settings like Unique Identifier Field and User Data Field Map have been kept to defaults and can be provided if helpful.

I would report this issue on the GitHub repo. There are open tickets there related with LDAP and I think there might be one which is same as this one.