[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:
Depends
Documented
Duplicate
duplicates SERVER-74989 Create configuration file option for ... Closed
duplicates SERVER-74999 Create configuration file option for ... Closed
Problem/Incident
Related
is related to SERVER-54136 Make the authenticate command respect... Closed
is related to SERVER-45938 Allow matching O/OU/DC in client x509... Closed
Assigned Teams:
Server Security
Sprint: Security 2020-08-10
Participants:
Case:

 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 SERVER-74989). Alternatively, the newly-added net.tls.clusterAuthX509.extensionValue config option can be used to specify a value that is expected to be present in the connecting client's extension with OID 1.3.6.1.4.1.34601.2.1.2 (see SERVER-74999). With either of these options, customers can use X.509 authentication for intracluster auth and provide member certificates that do not necessarily rely on O/OU being present or identical.

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 SERVER-45938, which was more precisely along these lines. We'll keep this ticket open in order to retain longer discussion about provisioning of cluster identity.

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

 

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