RocketChat / RocketChat/Rocket.Chat
LDAP uses user login instead of admin account
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 46.1k
- Forks
- 13.9k
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 130
Description
Description:
Since the last versions of Rocket.Chat, my instance requests LDAP with a normal filter by admin account and after that a new request, logging in by userdn directly. I am not completely confident, but my expectation is, the login should not be with a distinctive user. I my case, my LDAP wasn't allowing that either.
Steps to reproduce:
- login with ldap user
- check ldap debug log
Expected behavior:
Single login with configured ldap administration account should be found in logs. E.g.:
{
"messageID": 2,
"protocolOp": "SearchRequest",
"baseObject": {
"rdns": [
{
"o": "myOrganization"
}
],
"rdnSpaced": false,
"length": 1
},
"scope": "sub",
"derefAliases": 0,
"sizeLimit": 100000,
"timeLimit": 10 ,
"typesOnly": false,
"filter": "(&(&(objectclass=person))(|(cn=person@mail.de)(mail=person@mail.de)))",
"attributes": [],
"controls": []
}
Actual behavior:
This request can be found as well in the logs, in addition to the one above:
{
"messageID": 4,
"protocolOp": "SearchRequest",
"baseObject": {
"rdns": [
{
"cn": "myusername"
},
{
"ou": "users"
},
{
"o": "myOrganization"
}
],
"rdnSpaced": true,
"length": 3
},
"scope": "sub",
"derefAliases": 0,
"sizeLimit": 0,
"timeLimit": 10,
"typesOnly": false,
"filter": "(objectclass=*)",
"attributes": [],
"controls": []
}
Server Setup Information:
- Version of Rocket.Chat Server: 0.70.0
Additional context
I think that the Pull Request #11264 caused the problem. See https://github.com/RocketChat/Rocket.Chat/pull/11264#pullrequestreview-160474523
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the LDAP debug logs and compare the configured administration-account search with the additional user-DN search described in the issue. Review Pull Request #11264 and its discussion; done means logging in with an LDAP user performs only the expected search using the configured LDAP administration account.
Written by the indexing model from the issue text.
Assessment
- Domain
- authentication
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100