[SERVER-14655] x.509 certificate authentication requires O,OU to differ between client and server Created: 22/Jul/14 Updated: 15/Apr/23 Resolved: 15/Apr/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 2.6.3 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Mark Helmstetter | Assignee: | Backlog - Security Team |
| Resolution: | Duplicate | Votes: | 6 |
| Labels: | platforms-re-triaged | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Server Security
|
||||||||||||||||||||||||||||||||||||
| Sprint: | Security 2020-08-10 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||
| Description |
|
For x.509 certificate authentication, MongoDB server will consider a certificate with identical subject name properties, a member of the cluster and not a client. For some organizations it may not be possible to obtain certificates meeting this requirement. |
| Comments |
| Comment by Varun Ravichandran [ 15/Apr/23 ] |
|
The requested behavior will be available in 7.0. Specifically, the newly-added net.tls.clusterAuthX509.attributes config option can be used to specify DN attributes and values that must be contained within a connecting client's subject name DN in order to be treated as a cluster member (see |
| Comment by Sanchayan Sen [ 02/Feb/23 ] |
|
Hello Salman,
Thank you for responding. Yes please, we are looking to implement x.509 as an potential alternative to LDAP based authentication and it's showstopper for us. Happy to get on a call to elaborate on this further |
| Comment by Salman Baset [ 02/Feb/23 ] |
|
sanchayan.sen@natwest.com thanks for your comment. We are working on a solution to bring X.509 certs with user defined attributes. Happy to discuss your specific situation directly. |
| Comment by Sanchayan Sen [ 02/Feb/23 ] |
|
Hi
Is there any update on this ? We do have a similar problem and it's showstopper really. We cannot obtain certificates with different attributes and thats stopping us from adopting x.509 authentication |
| Comment by Matthew Rummel [ 06/Jan/21 ] |
|
I have the 4.2.11 version installed and set parameter enforceUserClusterSeparation : false in the mongod.conf which allows me to add an external user with the same O/OU/DC as the server. When I try to login as that external user I get "The provided certificate can only be used for cluster authentication, not client authentication. " |
| Comment by Spencer Jackson [ 11/Aug/20 ] |
|
Here's a quick summary of our understanding of and plans for this ticket. Clusters configured for intracluster X509 authentication validate whether incoming client connections are originating from fellow cluster members by comparing the peer's certificate's subject name against its own certificate's. Clients with certificates corresponding to the cluster are granted internal cluster privileges. These authentication attempts do not require the server to make a disk access. This implies that it would be unsafe to create an unprivileged user whose name would be considered a cluster member: anyone authenticating as it would be granted full internal privileges regardless of its defined on-disk privileges. To prevent this issue from arising, createUser has a guardrail which prevents it from making users with these names. Clusters using keyFile intracluster authentication would be immune from this conflation. However, we support upgrading a cluster from using keyFile intracluster authentication to using X509. Any users created under the old regimen could suddenly gain many powerful privileges after an upgrade. So, createUser's guardrail remains engaged in keyFile mode. There could be multiple solutions for this request. One could involve a general rework to how cluster identities are provisioned, one could be to relax the guardrail for consumers of keyFile authentication. There seems to be enough appetite for a relaxation. I believe that this relaxation should be opt-in via a setParameter, and that we should document the risks of using this mode and that the users' collection should be audited before upgrading to intracluster X509 authentication. I believe that we should re-open and perform this work under |
| Comment by Simon Levesque [ 18/Feb/20 ] |
|
Hi, I would consider that a "bug" ; not a "new feature" since when using keyfile that doesn't make sense at all. Also, it is "Major" since 2014. How can we get some traction on it? We depend on that fix to be able to use some vendor products that do not work with kerberos. thanks
|