[SERVER-6936] addUser appears to fail when KeyFile used in a Sharding configuration Created: 05/Sep/12 Updated: 15/Feb/13 Resolved: 05/Sep/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security, Sharding |
| Affects Version/s: | 2.1.1, 2.2.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Blocker - P1 |
| Reporter: | Zoiner Tejada | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | sharding | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows - 7, 2008 R2. On-premise and on Azure. |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
The crux of problem occurs when I try to add the user using a localhost connection to mongos I get: ShardRole1:20000: { errmsg: "need to login", ok: 0.0 }ShardRole2:20000: { errmsg: "need to login", ok: 0.0 }At this point, we are running with security mode enabled (e.g., KeyFile switch), but have not yet added any admin users anywhere. Here are some key details:
Reproducing the Problem: The scripts just need to be copied next to your Mongo binaries. For example, here's how we run it (follow the prompts at the command line for each): RunA.bat is identical to RunB and RunC except that it will also create a MongoS process and attempt to add a user. For comparison purposes, if you just run RunShardInfrastructureWithAuth.bat, it will run everything on a single machine and you will not encounter this error. |
| Comments |
| Comment by Spencer Brody (Inactive) [ 26/Sep/12 ] |
|
You could set up and configure the entire cluster without the --keyFile flag so that there is no authentication checks performed, add an admin user, then restart all the nodes in the cluster to run with --keyFile. I updated the documentation at http://www.mongodb.org/display/DOCS/Security+and+Authentication#SecurityandAuthentication-EnablingSecureMode to make this clearer. |
| Comment by Hays Barrett [ 26/Sep/12 ] |
|
I am experiencing the exact same issue using 2.2 Linux 64-bit. What do you mean when you say "set up the cluster without authentication enabled"? To set up a cluster don't you need to use the keyFile switch, and if you use that switch isn’t auth implied? |
| Comment by Spencer Brody (Inactive) [ 05/Sep/12 ] |
|
The easiest workaround here is to set up the cluster without authentication enabled, add the first admin user, then restart the cluster enabling authentication. |
| Comment by Spencer Brody (Inactive) [ 05/Sep/12 ] |
|
The problem is that in 2.0 all connections between the mongos and the config servers are given full admin access, but in 2.2 commands run on the config servers only have whatever permissions the user has authenticated to against the mongos. Although the mongos recognizes the incoming connection as coming from localhost, and thus having permission to run anything, when the addUser command is sent to the config servers the connection from the mongos to the config servers is not a localhost connection, and since the user has no auth credentials at this point, the command gets denied. There is a ticket open to fix this behavior: |