> On 11 Nov 2020, at 12:17, Matthew Harmsen 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 --
