[SERVER-7626] Provide configuration option to disable usage of db.auth() Created: 12/Nov/12  Updated: 30/Oct/15  Resolved: 05/Dec/12

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 2.2.0
Fix Version/s: 2.3.2

Type: Improvement Priority: Major - P3
Reporter: Simon Harvey Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 6.2


Issue Links:
Depends
depends on SERVER-7119 Add SASL config option(s) Closed
Related
Backwards Compatibility: Fully Compatible
Participants:

 Description   

Usage of db.auth means a password (often admin) needs to be typed in clear text. However the authentication can be performed on connection to MongoDB so that no password is ever displayed in clear text.

If authentication without using db.auth() is the best practice for a MongoDB user, they should be able to enforce it by setting a configuration option which means that the db.auth() command cannot be used for authentication.



 Comments   
Comment by Craig Wilson [ 12/Dec/12 ]

I mean this in reference to your statement: "You can enable one, both or neither, but if you do neither and have passed --auth as well, you won't be able to log in."

Let's not let them explicitly specify neither if they have passed --auth. If they don't specified authenticationMechanisms at all, then MONGO-CR is defaulted. However, if they specify authenticationMechanisms="", then let's abort startup.

In addition, we should abort startup if they specify authenticationMechanisms by do NOT specify --auth.

Comment by Andy Schwerin [ 12/Dec/12 ]

Do you mean if you specify --setParameter authenticationMechanisms="", or to you mean you totally omitted it? In the latter case, I don't see a strong reason not to preserve the default behavior of using MONGO-CR. Most customers, even subscription customers, will continue to use MONGO-CR in 2.4, and changing the default would require them to change their startup flags.

Comment by Craig Wilson [ 12/Dec/12 ]

If you have specified neither and specified --auth, can we not refuse to startup with a nice error message explaining the problem.

Comment by Andy Schwerin [ 05/Dec/12 ]

In the subscription product, as of 2.3.2 you will be able to specify which authentication mechanisms to support when starting mongod/mongos. The option will be "--setParameter authenticationMechanisms=<comma-separated-list>" MONGO-CR signifies the old-style challenge-response authentication. GSSAPI is for Kerberos. You can enable one, both or neither, but if you do neither and have passed --auth as well, you won't be able to log in.

Examples:

Default, allows only old-style authentication.

mongod --auth

Same as above, but explicitly enables old-style authentication.

mongod --auth --setParameter authenticationMechanisms=MONGO-CR

Only enable GSSAPI/Kerberos

mongod --auth --setParameter authenticationMechanisms=GSSAPI

Enable both

mongod --auth --setParameter authenticationMechanisms=MONGO-CR,GSSAPI

Comment by Andy Schwerin [ 05/Dec/12 ]

Use setParameter to specify supported authentication mechanisms in subscription product.

https://github.com/10gen/mongo-enterprise-modules/commit/28447a97525aad689f3ed8663e4aab09e0b097b3

Comment by auto [ 04/Dec/12 ]

Author:

{u'date': u'2012-12-04T18:14:05Z', u'email': u'schwerin@10gen.com', u'name': u'Andy Schwerin'}

Message: SERVER-7626 Provide a facility for disabling the mongo challenge-response commands in server source.

This patch provides a mechanism for disabling the "nonce" and "authenticate" commands at runtime. A
separate patch, in the subscription codebase, provides a startup parameter for choosing authentication
mechanisms to support.

Related to SERVER-7119.
Branch: master
https://github.com/mongodb/mongo/commit/55bb0f445ee535fd3091b6f0436f4e0ed5c9a19b

Comment by Simon Harvey [ 13/Nov/12 ]

Thanks for the quick update on this Andy.

Regards,

Simon.

Comment by Andy Schwerin [ 13/Nov/12 ]

I intended SERVER-7119 to include this, but the wording is vague. This is a must for 2.3.2.

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