[SERVER-24402] Auth-Enabled mongo conf, not working with MONGODB-CR Authentication Created: 03/Jun/16  Updated: 14/Jul/16  Resolved: 10/Jun/16

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

Type: Question Priority: Major - P3
Reporter: tilak mishra Assignee: Kelsey Schubert
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Participants:

 Description   

We are using Mongo 3.0.3. As our client .Net driver doesn't support SCRAM-SHA-1 type authentication, had to downgrade the security to MONGODB-CR. The replicaset successfully connects to client and communication takes place.

Below are the proofs:

db.system.version.find()
{ "_id" : "authSchema", "currentVersion" : 3 }
 
{ "_id" : "admin.admin_mongo", "user" : "admin_mongo", "db" : "admin", "credentials" : { "MONGODB-CR" : "0c23321a8e8ffc2377a61eb54fccf4a5" }, "roles" : [ { "role" : "userAdminAnyDatabase", "db" : "admin" }, { "role" : "root", "db" : "admin" } ] }

Recently we implemented Auth-Enabled feature in our Mongod.conf file, since then after restarting Replica set, seeing the below error.

ACCESS [conn253] SCRAM-SHA-1 authentication failed for __system on local from client XXXXXXX ; AuthenticationFailed SCRAM-SHA-1 authentication failed, storedKey mismatch

Used OpenSSL method to generate the keyfile. It's stored with 600 permission in a place where the user running mongod has access.

I have been searching for the solution to this problem, however none is related to my case. what feels me nervous is - in Mongodb documentation it says "Keyfiles use SCRAM-SHA-1 challenge and response authentication mechanism. "

so, if the Keyfiles uses SCRAM-SHA-1 challenge and response, how it's going to work in this case as i have already lowered the authentication mechanism to MONGODB-CR because of the client driver?

And what would be the solution to this problem. Please help.

Thank you,.



 Comments   
Comment by Ramon Fernandez Marina [ 15/Jun/16 ]

tilakmishra, unfortunately we're not able to provide support in this project. Please post on the mongodb-user group as suggested by Thomas for all MongoDB support-related questions.

Thanks,
Ramón.

Comment by tilak mishra [ 15/Jun/16 ]

Thanks Thomas for giving guidance.

I tried again, after regenerating the key file using these commands:
openssl rand -base64 755 > /app/Mongo/mongodb-keyfile
chmod 400 /app/Mongo/mongodb-keyfile

And then, added below entries to mongod.conf file.
security:
authorization: enabled
keyFile: /app/Mongo/mongodb-keyfile

However not sure what's going wrong , i am getting this error when trying to start mongod using security..
invalid char in key file /app/Mongo/mongodb-keyfile

Can you please help and guide? I am really in a very awkward situation, in 3 non environments it worked, dont know why its failing in Prod.

Comment by Kelsey Schubert [ 10/Jun/16 ]

Hi tilakmishra,

It is expected that, even when using the MONGODB-CR authentication mechanism, drivers and clients that support MongoDB 3.0 features will use the SCRAM communication protocol. This behavior is not cause for worry as the client drivers that do not support SCRAM should still be able to authenticate using MONGODB-CR when you downgrade.

The error message you are observing suggests that the credentials are incorrect or misconfigured in some way.

Please note that SERVER project is for reporting bugs or feature suggestions for the MongoDB server. I see that you have already posted on the mongodb-users group and Stack Overflow with the mongodb tag with the same question. These are the best places to receive MongoDB-related support as your question will reach a wider audience. See also our Technical Support page for additional support resources.

Kind regards,
Thomas

Comment by tilak mishra [ 10/Jun/16 ]

Any solution please?
If you need any further info on this,i can provide.
Our Cyber team has been asking us to get a fix for this as soon as possible as customers data reside in this analytics database without security enabled.

Generated at Thu Feb 08 04:06:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.