[SERVER-17512] Unable to authenticate with web console with SCRAM-SHA-1 Created: 09/Mar/15 Updated: 14/Apr/16 Resolved: 12/Mar/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | HTTP Console |
| Affects Version/s: | 3.0.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ian Bryson | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
MongoDB: 3.0.0 (standalone) |
||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | Linux | ||||||||||||||||
| Steps To Reproduce: | 1) Startup brand new 3.0.0 mongo: numactl --interleave=all ${MONGO_HOME}/bin/mongod --config ./mongodb.conf mongodb.conf systemLog: 2) Create a user on the localhost: $ mongo localhost:6646/admin > db.createUser( {user: "foo", pwd: "bar", roles: ["userAdminAnyDatabase"]}); 3) Got to http://localhost:7646/ and unable to login. Alternatively. 1) Start using an existing 2.6.x db with 3.0.0 binaries. 2) Login to the web console: http://localhost:7646/. Should work fine. 3) Login to mongo and upgrade the auth: > db.adminCommand( {authSchemaUpgrade: 1}); 4) Go back to the web console (has to be in a fresh browser): http://localhost:7646/ and you are now unable to login. mongo command line tools still work. Looks a bit broken to me |
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
After doing a clean install of 3.0.0 and setting up default users we are unable to authenticate with the web console. The issue also happens after upgrading from 2.6.x -> 3.0.0 and then running a authSchemaUpgrade. It's because it stops working after the authSchemaUpgrade that makes me think the issue is to do with SCRAM-SHA-1. Authentication is turned "off" but it still doesn't work even if this is turned on. Also we can still connect to mongo using the normal mongo command line tool. |
| Comments |
| Comment by Spencer Brody (Inactive) [ 12/Mar/15 ] |
|
Closing as duplicate of |
| Comment by Ian Bryson [ 12/Mar/15 ] |
|
Yes, your correct. That's exactly what happens. |
| Comment by Spencer Brody (Inactive) [ 10/Mar/15 ] |
|
Hi Ian, you're right that even though we do document this change in the release notes, it easy to overlook and we could do a better job calling this out. To that end I filed I suspect that the reason this triggered after migrating to wiredTiger was not actually due to the wiredTiger migration but because as part of that process you deleted and re-created your user definitions, is that correct? Upgrading an existing system with user definitions from 2.6 to 3.0 will initially leave the user definitions in the same format as they were in 2.6, using MONGODB-CR credentials, so the web console would continue to work with those users. Once your users are using the new user format that only works with SCRAM-SHA-1, either because you ran the authSchemaUpgrade command or because the user definitions were cleared out and re-created, then the web console would cease to work. |
| Comment by Ian Bryson [ 10/Mar/15 ] |
|
We use it to see that it's running and you can see what version it is etc, just in case our auto deploy scripts don't work. It's easier hitting a URL then logging in from a command line mongo We don't really need it as all our monitoring stats are elsewhere and I take the point about security. However, it is a bit unexpected it doesn't work. Maybe something in the logs to say it won't work with this security mechanism would be useful? It's especially confusing when you upgrade from 2.6 and it works fine. But moving to wired tiger you need to export your data, clean out everything and then re-import and suddenly you can't use this tool. You just assume your import / export has screwed up your users priivileges somehow or that there is a new role that your users need to use this tool. Anyway, thanks for the quick response. Cheers |
| Comment by Spencer Brody (Inactive) [ 09/Mar/15 ] |
|
Hi Ian, |
| Comment by Ian Bryson [ 09/Mar/15 ] |
|
On the above "Steps to reproduce" it should be the "servername" instead of "localhost". I think the issue may just be to do with accessing from a non localhost. On further investigation ( running on a local windows box ) it appears on 3.0.0 you can't connect to: but you can connect with Maybe it's just connecting remotely that is now prevented? |