Rocket.chat: LDAP -> RocketChat user collision

[a-abella]

Rocket.Chat Version: 0.52.0
Running Instances: 1
DB Replicaset OpLog: (Shows disabled but it's initiated at oplog size 1024)
Node Version: 4.5.0

Given two LDAP users named John Smith (domain\jsmith) and John A. Smith (domain\jasmith)
and given a Domain Search User ID value of sAMAccountName
and given a Username Field value of #{givenName}.#{sn}:

Expected behavior:

Authenticate first user's sAMAccountName against LDAP and on first login create a user with a unique _id value, and a username of #{givenName}.#{sn} (john.smith). When authenticating second user, note the different sAMAccountName value at login, and create a new user with a different unique _id value but the same #{givenName}.#{sn}. In most chat systems, two users of the same display name is perfectly valid and it is up to the end user to differentiate between John Smiths on a secondary value such as email or full proper name.

Current behavior:

Authenticate first user's sAMAccountName against LDAP and on first login create a user with a unique _id value, and a username of #{givenName}.#{sn} (john.smith). When authenticating second user, logs second user into existing user account for username of #{givenName}.#{sn}. Second user has complete access to first users account: private channels, direct messages, the whole shebang.

Current workarounds:

-Set Username Field value to sAMAccountName which is guaranteed to be unique.

I do not know how deeply integrated a unique username is in the RocketChat system, but the unique identifying value should really be the user id. An option to show proper names on messages as imported from LDAP instead of usernames would also be preferable to the current behavior.

EDIT: Note this issue occurs with any non-unique LDAP value set to the username. cn, displayName, givenName+sn, etc.

EDIT2: The "Show Real Names" option has proven a good workaround in our organization. Usernames are still samaccountname for the guaranteed unique values, but the usability of full names is now present.

[localguru]

Hi,

same with email address of an LDAP user if "User Data Field Map" is e.g. just set to {"mail":"email"}. I created two LDAP users with the same email address. First user can be created and log in, second user can't. It took me some time to figure that out, because those users were test users and I set the same email address for both of them. I though something was wrong with my LDAP configuration. Evil pitfall :)

Logfile:
[34mI20170301-21:14:55.264(1) [34mLDAPSync ➔ debug New user data { username: 'teamchat02', email: '[email protected]' }
[34mI20170301-21:14:55.364(1) rocketchat_ldap rocketchat_ldap.js:712 [31mLDAPSync ➔ error Error creating user { [Error: Email already exists. [403]] error: 403, reason: 'Email already exists.', details: undefined, message: 'Email already exists. [403]', errorType: 'Meteor.Error' }

Same with local users. You can't create two users with the same email address or name.

I agree with a-abella that the name or email address should not be the unique key for an user account.

Ciao!

[willihelm]

In my company there are many users that share one email address. Please fix this.

[steveyj79]

I would love to see this fixed too, we have sites that allow for multiple sign in's using the same email address.

[a-abella]

The "Show Real Names" option has proven a good workaround in our organization. Usernames are still samaccountname for the guaranteed unique values, but the usability of full names is now present.

The original issue is still a security risk that should be checked for, but Show Real Names helps.

[Garen]

Since this issue was filed in March 1, not sure if the "User Data Field Map" feature was yet available, which can now be used to help display more distinctive info about users.

@a-abella sAMAccountName is only unique within a single domain. For example, you might have "domain1jsmith" and "domain2jsmith" - each of which corresponds to a different person, but both have the sAMAccountName of "jsmith". Each directory type (AD, openldap, ...) should have a globally unique attribute that you can specify in the "Unique Identifier Field" section in the "Administration -> LDAP" area though. For ex, we currently use "objectGUID, objectSid".

Also, FWIW, if using AD, you might find "#{displayName}" more useful than "#{givenName}.#{sn}". For ex, "Robert Smith" may have a displayName of "Bob Smith" or "Bobby Smith" (he prefers to not go by his legal name) which hopefully distinguishes him from the other "Bob Smith" users in the company.

-hth

[marceloschmidt]

We're looking for someone with LDAP skills to help us here.

[rudiservo]

Hi I think that for security purposes there is an issue with LDAP:
i.e. one security measure is to add a few numbers to the user, like john.smith.1234
this is like a nightmare for hackers because it make it much harder to brute force.

also is an issue if the server show every username in the server by simply putting the "@"

Smartphone are a security problem, a big one, there should be a remote way to authenticate a mobile phone without putting your password, like qrcode or remote accept device.

One more issue force sync does not sync usergroups or channels.

I do realize that there is kind of an issue here and it's not easy, I am no LDAP expert i am just hacking my way through implementing it on my company safely and I realize that is really really hard.