[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)
Linux: 2.6.32-358.6.2.el6.x86_64


Issue Links:
Duplicate
duplicates SERVER-17390 HTTP Interface does not work with SCR... Closed
Related
related to SERVER-17527 Add startupWarning if server started ... Closed
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:
destination: file
path: "/foo/logs/mongodb.log"
logAppend: true
processManagement:
fork: true
net:
http:
enabled: true
RESTInterfaceEnabled: true
port: 6646
storage:
dbPath: "/foo/db"

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 SERVER-17390

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 SERVER-17527 to warn at startup if you're running in this type of configuration.

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,
Your observations are correct, the web console does not support authenticating with SCRAM-SHA-1 users. This is noted in the 3.0 release notes here. Please note that the http interface is not held to the same security standards as the main server code and as such it is our recommendation that any security-sensitive deployments disable the http interface.
Can I ask what you are hoping to use the web console for? Perhaps I can recommend another way to get access to whatever information you are currently getting from the web interface, for instance by using MMS or some other monitoring tool (munin, nagios, etc.)

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:

http://servername:7646/

but you can connect with

http://localhost:7646/

Maybe it's just connecting remotely that is now prevented?

Generated at Thu Feb 08 03:44:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.