[Freeipa-users] Re: Force LDAPS and 636 port

Greetings, Thanks a lot for your explanation. Based on your message and my humble research would it be safe to say that to enforce TLS connections with a specific ciphers to the default FreeIPA deployment one can do these: 1. Require secure bind nsslapd-require-secure-binds=on (will reject all the connections without STARTTLS) 2. Disabling Anonymous Binds nsslapd-allow-anonymous-access=rootdse (to allow read dir info) 3. Set nsSSL3Ciphers to ones we approve 4. Set sslVersionMin to the lower one we support I spoke to my security team and explained to them the situation with 389 and 636 ports. They agreed to comply with your advice but strictly told that it is mandatory to maintain secure communication using TLS and a certain number of ciphers they see as strong.

Regards, Alex Ivanov On Tue, Jan 31, 2023 at 6:18 PM Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote: > On ti, 31 tammi 2023, Alex Ivanov via FreeIPA-users wrote: > >Greetings, > > > >I'm struggling to find a comprehensive guide on how to block LDAP and > >389 port on FreeIPA and force usage of LDAPS and 636 port for all > >clients and connections. I would really appreciate a link or a hint. > > There is no such guide because FreeIPA requires use of LDAP/389, both > TCP and UDP, same as with Active Directory. We enforce encrypted > connections within SASL GSSAPI-authenticated sessions. > > If you have requirements to close done port 389, well, tell those people > to go and learn how domain resolution protocols are done in Active > Directory and similar systems. > > LDAP use of port 636 is not really standardized (it was an RFC proposal > that expired and not made into RFC at all). All the manual work to make > it supported is not going to play well with the fact that Windows > systems still required to talk port 389 for general domain controller > discovery questions: > > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7fc... > and then > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/895... > > If you are using Kerberos and SASL GSSAPI or SASL GSS-SPNEGO (default > configuration for SSSD and RHEL IdM), none of disabling for LDAP 389 > port is needed. This is because RHEL version of CyrusSASL automatically > enables encryption and signing when Kerberos is in use with AES > encryption types. > > We use LDAP SASL GSSAPI/GSS-SPNEGO to actually authenticate to IPA and > AD LDAP resources. Due to how this is implemented in RHEL, such > connections are then encrypted. This works everywhere, for example, > there is no need to switch to port 3269 for Global Catalog traffic. > > From my email roughly three years ago, the same applies to any LDAP > traffic with SASL GSSAPI/GSS-SPNEGO authentication, not just port 389 > but 3268 as well: > > ------------------------------------------------------------------- > We added two important fixes in RHEL 7.4-7.5 timeframe: > - RHEL 7.4: support GSS-SPNEGO in CyrusSASL, with cyrus-sasl-2.1.26-21 > or later installed > (https://bugzilla.redhat.com/show_bug.cgi?id=1421663), > > - RHEL 7.5: support autodiscovery of minimal SSF with > GSSAPI/GSS-SPNEGO, with cyrus-sasl-2.1.26-22 or later installed > (https://bugzilla.redhat.com/show_bug.cgi?id=1431586) > > These should be enough because SSSD uses LDAP with SASL based on > CyrusSASL library and negotiates GSSAPI/GSS-SPNEGO with sealing > (encryption) by default in all new RHEL 7/RHEL 8 deployments. > -------------------------------------------------------------------- > > We keep getting these questions from the customers for SSSD accessing AD > LDAP all the time. Well, that was the case couple years ago, not > anymore, except your email today. > > If you want to see that the traffic is encrypted, try without > GSSAPI_* options in ldap.conf and I can see following with tshark in > LDAP communication after bind was successfully performed. This is > running 'ldapsearch -Y GSSAPI -h AD-DC -b $basedn cn=Administrator' > > Lightweight Directory Access Protocol > SASL Buffer Length: 127 > SASL Buffer > GSS-API Generic Security Service Application Program Interface > krb5_blob: 050406ff00000000000000000262b065c0d8351b29fd1943<E2><80><A6> > krb5_tok_id: KRB_TOKEN_CFX_WRAP (0x0405) > krb5_cfx_flags: 0x06, AcceptorSubkey, Sealed > .... .1.. = AcceptorSubkey: Set > .... ..1. = Sealed: Set > .... ...0 = SendByAcceptor: Not set > > As you can see, we do send encrypted (Sealed bit) traffic. > > AD DCs respond with sealed traffic as well: > > Lightweight Directory Access Protocol > SASL Buffer Length: 127 > SASL Buffer > GSS-API Generic Security Service Application Program Interface > krb5_blob: 050406ff00000000000000000262b065c0d8351b29fd1943<E2><80><A6> > krb5_tok_id: KRB_TOKEN_CFX_WRAP (0x0405) > krb5_cfx_flags: 0x06, AcceptorSubkey, Sealed > .... .1.. = AcceptorSubkey: Set > .... ..1. = Sealed: Set > .... ...0 = SendByAcceptor: Not set > > > This is due to use of Cyrus-SASL GSSAPI/GSS-SPNEGO plugin. In the client > side of the plugin we actually enforce integrity if maximum security > strength factor (SSF) is above external SSF. Confidentiality (sealing) > is enabled if maximum SSF is above external SSF by more than 1. If an > application didn't set external SSF value, it defaults to 0, while > default Kerberos SSF is set to 112. > > Since all IPA systems get configured to default to use SASL > GSSAPI/GSS-SPNEGO methods, we effectively enforce encrypted > communication. > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > >