DB-level users are currently authorized on the primary shard server (as opposed to the config server with global/admin users). This has implications for targeted queries, as any targeted query with auth would require both the primary shard server and target shard server be available.

Further, when this case is encountered, the error messages can be quite confusing; either indicating that auth explicitly failed, or that a socket exception occurred (without mentioning the remote host):

leaf-linux:~/projects/mongo (v2.0) $ ./mongo --port 27037
MongoDB shell version: 2.0.8-rc0-pre-
connecting to: 127.0.0.1:27037/test
> use shtest
switched to db shtest
> db.auth('a', 'a')
0
> db.auth('a', 'a')
Thu Aug 16 12:21:26 uncaught exception: error { "$err" : "socket exception", "code" : 11002 }
> db.auth('a', 'a')
Thu Aug 16 12:21:38 uncaught exception: error { "$err" : "socket exception", "code" : 11002 }
> db.test.find({_id:ObjectId("502d4710eb0808c27833da2d")})  // this query would work without auth.
error: { "$err" : "unauthorized", "code" : 15845 }

Note this test was run after killing the primary shard server. Test environment is 2 shards with replication, where the targeted document lives on the non-primary shard.

We should probably note this caveat on the Shard Operation Types page until this is resolved.