> On 11 Nov 2020, at 12:17, Matthew Harmsen <mharmsen@xxxxxxxxxx> wrote: > > Everyone, > > I received the following from a community member who is using Dogtag and 389: > > I have 2 questions and 1 note. > > Note: > Here is an interesting thing that I noticed during CA cloning: > When CA to be cloned has secure connection DS enabled, cloning process fails. > None of docs: > • https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_Clone > • https://github.com/dogtagpki/pki/blob/DOGTAG_10_6_BRANCH/docs/installation/Installing_CA_Clone.md > • https://github.com/dogtagpki/pki/blob/master/docs/installation/ca/Installing_CA_Clone.md > is covering this issue. > Solution here is to use > pki_clone_replication_master_port=389 > pki_clone_replication_clone_port=389 > pki_clone_replication_security=None > https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/server/etc/default.cfg#L255 > > > Question 1 (sorry, bit long): > When CA is cloned both DS servers have nsslapd-referral attribute set in dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config entries > so DS on vm-users4.hostname.com > would have > dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsslapd-referral: ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA > and DS on vm-users3.hostname.com > dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsslapd-referral: ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA > I wonder what is the meaning of nsslapd-referral attribute? It's so that while the server is "offline" and receiving data, it can redirect clients to other nodes in the topology. > > The reason I'm asking is that I was thinking that for replication over SSL maybe nsslapd-referral should be modified > from ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA > to ldaps://vm-users4.hostname.com:636/o%3Dpki-tomcat-CA > but when I did this nsslapd-referral attribute was reverted to original value by DS automatically, > so I'm trying to make sure if nsslapd-referral attribute should be left unchanged during enabling of SSL to DS replication? > > Just in case here is a sample of all changes on both DS (hopefully, I didn't miss anything to have properly configured replication over SSL): > vm-users4.hostname.com: > ------------------------------------ > dn: cn=config > nsslapd-security: on > > dn: cn=RSA,cn=encryption,cn=config > nsSSLPersonalitySSL: slapd-vm-users4 > nsSSLToken: internal (software) > nsSSLActivation: on > > dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsslapd-referral: ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA > > dn: cn=cloneAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsDS5ReplicaPort: 636 > nsDS5ReplicaTransportInfo: SSL > > > vm-users3.hostname.com: > ------------------------------------ > dn: cn=config > nsslapd-security: on > > dn: cn=RSA,cn=encryption,cn=config > nsSSLPersonalitySSL: slapd-vm-users3 > nsSSLToken: internal (software) > nsSSLActivation: on > > dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsslapd-referral: ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA > > dn: cn=masterAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config > nsDS5ReplicaPort: 636 > nsDS5ReplicaTransportInfo: SSL I'm not sure here, it could be a bug as we should redirect to TLS ports if possible, but I guess it also depends on how the client connects too ..... Generally a lot of clients don't follow referrals *anyway* so the whole this is a bit moot. > > > Question 2: > DS has so called "SSF Restrictions" (https://directory.fedoraproject.org/docs/389ds/howto/howto-use-ssf-restrictions.html} > which may be configured by setting nsslapd-minssf attribute in cn=config entry. > Default value of nsslapd-minssf attribute is 0. W > Minimum SSF configuration setting can be used to define the minimum level of encryption that is required. > > Do you know what this means? > Should I be concerned? SSF restrictions are a bit of a joke. You probably should leave them alone. They are intended to force connections to require encryption, but they don't actually provide meaningful security improvements since the info disclosures happen *before* the ssf check can kick in due to bind being the first op in any connection. https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html?highlight=minssf A better option if you are security conscious is to set the nsslapd-port to 0 and only use the LDAPS/TLS port (startTLS has similar issues to minssf, and also adds extra latency and should be avoided.). > > By the way, when is set nsslapd-minssf attribute to 128, DS becomes inaccessible and CA is not working. > > Thanks in advance for any answers, > -- Matt — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia _______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
