Rocket.chat: No admin user after activating ldap
Hi,
After ldap is enabled and the (local) admin logs out there is no way to log in again with administrator privileges. (as local users are disabled when ldap is activated)
The local admin probably would need to grant the admin role to an ldap user before he logs out but if he doesn't I think the only way is to grant it through database.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Tharnas
All 16 comments
:+1:
ninja-
on 12 Oct 2015
+1
Theaxiom
on 12 Oct 2015
Some kind of hard to ignore warning before you enable the feature would be good. One that contains instructions, or links to some, would definately help. A good starting point could be a warning at the top of the LDAP wiki page, with how to fix it if you screw up would be a good start.
emcguinness
on 13 Oct 2015
Absolutely or at the very least always allow initial admin to login unless the account is deleted (which only an admin could do)
geekgonecrazy
on 13 Oct 2015
So, how do I change a user to be admin if this happened? I'm the docker image...
hameno
on 22 Oct 2015
@hameno
If you're locked out you can change your user to be an admin in mongo db directly.
Dbzman
on 22 Oct 2015
Yeah, figured that out. Wasn't easy or documented though, the wiki article is also outdated, as it shows an "admin" field while I had to change the roles.
For reference:
- docker exec into rocketchat_db
- mongo
- then follow https://github.com/RocketChat/Rocket.Chat/wiki/Creating-the-First-Admin except when updating you should change the roles, search for the first user for reference how the role should look like
hameno
on 22 Oct 2015
Thanks for pointing that out, @hameno . Could you please update the mentioned wiki article in order to reflect up-to-date, reproducible steps?
gmsecrieru
on 22 Oct 2015
While following the above step, while executing meteor, its building application and stopping at,
Errors prevented startup:
While processing files with templating (for target web.browser):
bundle/programs/web.browser/app/fonts/fontello.html:1: Expected one of:
bundle/programs/web.cordova/app/fonts/fontello.html:1: Expected one of: , ,
While processing files with templating (for target web.cordova):
bundle/programs/web.browser/app/fonts/fontello.html:1: Expected one of:
bundle/programs/web.cordova/app/fonts/fontello.html:1: Expected one of: , ,
even though if i change the file and add the DOCTYPE still it stuck here, and am not able to disable LDAP. Because of this not able to edit any admin settings.
saigop
on 24 Dec 2015
Hi,
Somehow i fixed this. From the mongo command line, I disabled the ldap "db.rocketchat_settings.update( { _id: "LDAP_Enable"}, { $set: {value: false} } )"
And logged into the general authentication, post gave ADMIN rights to one of the LDAP user, finally again activated LDAP settings from the web console.
:)
saigop
on 24 Dec 2015
Maybe we can add support for an environment variable? Something like DISABLE_LDAP=true or DEBUG_LDAP=true that would enable the site admin still.
geekgonecrazy
on 28 Dec 2015
Yes, that would be nice, And the second time, have done something like this, in the chrome browser I have created the first admin user and left intact as logged in. In parallel i activated the LDAP.
And from the windows client, I logged as LDAP user, and went back to the browser where first logged in, there i marked the LDAP user as admin. So now without going to mongodb I did something like this.
It will be useful for some one viewing this.
Thanks.
saigop
on 29 Dec 2015
Does Meteor support multiple authentication schemes? i.e. check LDAP first then check local.
rwakida
on 29 Dec 2015
@rwakida That's a great question... If not this maybe an improvement / hack worth looking into.
geekgonecrazy
on 30 Dec 2015
engelgabriel
on 25 Jan 2016
rmdes
on 8 Nov 2016
Related issues
neha1deshmukh
路
3Comments
amayer5125
路
3Comments
royalaid
路
3Comments
Buzzele
路
3Comments
sta-szek
路
3Comments
Most helpful comment
Hi,
Somehow i fixed this. From the mongo command line, I disabled the ldap "db.rocketchat_settings.update( { _id: "LDAP_Enable"}, { $set: {value: false} } )"
And logged into the general authentication, post gave ADMIN rights to one of the LDAP user, finally again activated LDAP settings from the web console.
:)