[SERVER-17459] Users can't authenticate with authenticationMechanisms=MONGODB-CR Created: 04/Mar/15  Updated: 14/Jul/16  Resolved: 01/Apr/15

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 3.0.0
Fix Version/s: None

Type: Bug Priority: Critical - P2
Reporter: Jose Luis Pedrosa Assignee: Andreas Nilsson
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Operating System: ALL
Participants:

 Description   

Hi all,

Starting a server (from scracth) in 3.0 and authenticationMechanisms=MONGODB-CR and auth enabled makes impossible to login with that mechanism.

I've traced it a little bit: when users are created (even with this auth mechanism) the credentials created are only for "SCRAM-SHA-1".
see Sample:

{
        "_id" : "admin.admin",
        "user" : "admin",
        "db" : "admin",
        "credentials" : {
                "SCRAM-SHA-1" : {
                        "iterationCount" : 10000,
                        "salt" : "FPnmqmCI04KHJVZunfaI2Q==",
                        "storedKey" : "i+jvORcFsnx6CXt0Bd924e2f804=",
                        "serverKey" : "PQHG8nYYcJTjFEClqjFRZ8PTLTA="
                }
        },
        "roles" : [
                {
                        "role" : "userAdminAnyDatabase",
                        "db" : "admin"
                },
                {
                        "role" : "root",
                        "db" : "admin"
                }
        ]
}

But if I go to a 2.6 server create the same credentials, then update the 3.0 server user document credentials with the MONGODB-CR it can successfully log in.

{
        "_id" : "admin.admin",
        "user" : "admin",
        "db" : "admin",
        "credentials" : {
                "SCRAM-SHA-1" : {
                        "iterationCount" : 10000,
                        "salt" : "FPnmqmCI04KHJVZunfaI2Q==",
                        "storedKey" : "i+jvORcFsnx6CXt0Bd924e2f804=",
                        "serverKey" : "PQHG8nYYcJTjFEClqjFRZ8PTLTA="
                },
                "MONGODB-CR" : "8aab8902fd862afad8064b73bd149d00"
        },
        "roles" : [
                {
                        "role" : "userAdminAnyDatabase",
                        "db" : "admin"
                },
                {
                        "role" : "root",
                        "db" : "admin"
                }
        ]
}

There's still a lot of code/programs (as admin UIs robomongo, nosqlmanager and so on) that still is not ready to the new auth schema and makes impossible to login, even if I specify the MONGODB-CR auth.

I think that the credentials created for a new user need to include also the auth mechanism enabled, this will possible a softer transition, for us right now means a lot of user collection manual hack or don't upgrade.

Thanks!



 Comments   
Comment by Baris Gomleksizoglu [ 06/Jun/16 ]

db.grantRolesToUser ( "root", [

{ role: "__system", db: "admin" }

] )

This will give you access to update version

Comment by Andreas Nilsson [ 25/May/16 ]

This looks like a permission setup problem on the config server. For setting up access control I would refer to https://docs.mongodb.com/manual/core/authorization/

A question like this involving more discussion would be best posted on the mongodb-user group. See also our Technical Support page for additional support resources.

Thank you,
Andreas

Comment by Dharshan Rangegowda [ 25/May/16 ]

Yes. I tried that. Getting authorization error - are there special permissions required? I am running as "root" user.

mongos> db.getSiblingDB("admin").system.version.update({ _id: "authSchema" },{ $set: { currentVersion: 3 } });
WriteResult({
        "writeError" : {
                "code" : 13,
                "errmsg" : "not authorized on admin to execute command { update: \"system.version\", updates: [ { q: { _id: \"authSchema\" }, u: { $set: { currentVersion: 3.0 } }, multi: fal
se, upsert: false } ], ordered: true }"
        }
})

Comment by Andreas Nilsson [ 25/May/16 ]

dharshan_r@yahoo.com you need to do it on the config servers and not mongos. No user documents are stored on mongos.

Thanks,
Andreas

Comment by Dharshan Rangegowda [ 25/May/16 ]

Will this approach work on a sharded cluster? db.version does not appear writable on a sharded cluster.

Comment by Andreas Nilsson [ 04/Jun/15 ]

Brent, let me try to clarify:

  • you only need to downgrade the schema to create MONGODB-CR users. Once they are there the old drivers will work regardless of the value of authSchemaVersion. However if you run authSchemaUpgrade to change from "3" to "5" the users will obviously be upgraded.
  • My comment regarding new users was that if you have existing SCRAM users and change the schema manually to "3" the user documents won't be consistent with the new schema. This is not enforced however but the SCRAM users will still work for any driver supporting SCRAM.

Let me know if this answers your questions.

Regards,
Andreas

Comment by Brent Barker [ 04/Jun/15 ]

Andreas, we just created a mongo 3.0 server and have created a few users and now one of our vendors is requesting us to perform the steps that Jose mentioned above. If I were to change the schema.currentVersion to 3, create their users and then change it back to 5 would it cause issues? Or does it need to remain set to 3 until they upgrade their driver? Currently we have 3 databases on this server and theirs is the only one requesting this change. I will also need to create additional users on the other databases. Will you explain a bit more about what you meant by "New users however will be created with MONGODB-CR credentials resulting in a mixed, inconsistent set." Thanks.

Comment by Andreas Nilsson [ 04/Mar/15 ]

Ok sounds good.

Just as an FYI if you change the authSchemaVersion to "3" while having SCRAM-SHA-1 users in the system auth will still work for them. New users however will be created with MONGODB-CR credentials resulting in a mixed, inconsistent set. Running authSchemaUpgrade on such a system will work fine and only upgrade the credentials of the MONGODB-CR users to SCRAM.

Comment by Jose Luis Pedrosa [ 04/Mar/15 ]

Hi Andreas

I've applied the change you suggested
1) Start 3.0 without auth enabled
2) Run (on admin db):

> var schema = db.system.version.findOne({"_id" : "authSchema"})
> schema.currentVersion = 3
> db.system.version.save(schema)

3) restart with auth enabled.

Software with new drivers (only tested csharp driver) and legacy software works fine.

Comment by Jose Luis Pedrosa [ 04/Mar/15 ]

HI Andreas

Up to now i've tested: Robomongo and Nosql Manager, none of them worked, in case of Nosql manager is really funny, because they already have the options to play with the storage options that is only available in 3.0 , but you can't log to it if auth enabled.

I would suggest that some tester from mongodb goes through the listed UIs in the mongo documentation and maybe test if they can connect to 3.0 to understand how broad is the impact of this approach. http://docs.mongodb.org/ecosystem/tools/administration-interfaces/
For my internal components I already upgraded to the appropriate version and had no issue. (I'm right now testing the tweak you mentioned)

Thanks for your speed.

Comment by Andreas Nilsson [ 04/Mar/15 ]

jlpedrosa could you also provide a list of tools that you have tried that currently does not work with SCRAM-SHA-1 and we will investigate the best course of action short- and long term.

Comment by Andreas Nilsson [ 04/Mar/15 ]

First of all it is my sincere hope that author's of the third party tools will either utilize our drivers (which all support SCRAM-SHA-1) or implement the new auth protocol. The drivers delivered with 3.0 all use SCRAM-SHA-1 by default when talking to a 3.0 server and MONGODB-CR when talking to a < 3.0 server.

Regarding the authMechanisms flag I agree that it is slightly confusing. The flag is rather used to enable external mechanisms like Kerberos and LDAP and is controlling which mechanisms it's possible to authenticate with. By default MONGODB-CR, SCRAM-SHA-1 and MONGODB-X509 are enabled.

If we would have chosen to start 3.0 in mixed mode, and required an authSchemaUpgrade to use SCRAM we would start the server in a less safe mode, and require users who are upgrading directly from 3.0->3.2 to run an authSchemaUpgrade all though there is no real reason for it. Our assessment was that this would cause more user troubles then starting clean 3.0 servers incompatible with non-updated third party tools.

Changing the authSchemaVersion manually is functionally equivalent to doing it in code when starting up. So as long as you haven't created any users yet it will keep the system consistent. We should possibly add this to the docs page referenced above.

Comment by Jose Luis Pedrosa [ 04/Mar/15 ]

Hi Andreas

Thanks for your (extremely fast) explanation. Indeed I saw the page you mentioned, but I not realized this involved different commands and third parties are affected.
I fully understand your approach and I think it's an excellent choice for an smooth transition when you want to deprecate something, my "concern" is that I think the user/companies needs still some time to be able to migrate all the components, I think that the behavior is a little bit misleading, because I'm still able to specify this authMechanism, but it does not work if I use it (I think do you understand where I'm going).

I think that showing a warning on startup if this schema is used (informing about that it will be deprecated) and actually make it work would be better.
Actually if I follow your instructions (Changing the authSchemaVersion from "5" to "3") is at the same time a discouraged action, but required to operate 3rd party components. In my opinion, enabling MONGODB-CR should imply that the credentials are generated, and when the user upgrades the auth (with the guide) then the SCRAM-SHA-1 should be the only one.

Long story short: I'm allowed to put an option that is only partially used and blocks all longings which is strange.
Think about the options I have
1) Don't migrate to 3.0
2) Do a not recommended action.

Thanks again!

Comment by Andreas Nilsson [ 04/Mar/15 ]

jlpedrosa thank you for your report and detailed investigation.

This behavior is by design, see http://docs.mongodb.org/v3.0/release-notes/3.0-scram/ The behavior is determined by the authSchemaVersion field in the admin.system.version collection.

If you upgrade an existing 2.6 installation MONGODB-CR credentials will still be present in the user documents and SCRAM-SHA-1 and MONGODB-CR can be used in parallel. SCRAM credentials will be generated on the fly based on the MONGODB-CR credentials. The authSchemaVersion is "3".

If you start a clean 3.0 node it starts in authSchemaVersion "5" and only SCRAM credentials will be generated as you correctly noted. The purpose of this hard cut are several:

  • Start the server with secure defaults.
  • Make a transition to 3.2, where MONGODB-CR most likely will be entirely removed smooth.

It is possible to retain the mixed behavior by

  • Upgrading from a 2.6 system with existing users.
  • Changing the authSchemaVersion from "5" to "3" in admin.system.version manually. In general we don't recommend changing internal configuration parameters in the system.* collections.

Does this address your concerns regarding the third party tools?

Best Regards,
Andreas Nilsson

Comment by Jose Luis Pedrosa [ 04/Mar/15 ]

By the way, the error you get in the log if the credentials are not created is:
Failed to authenticate admin@admin with mechanism MONGODB-CR: AuthenticationFailed MONGODB-CR credentials missing in the user document

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