[Freeipa-users] Re: Force LDAPS and 636 port
On ke, 08 helmi 2023, Алексей Иванов wrote: 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. Since you haven't really specified what FreeIPA or RHEL IdM version you are talking about in the setup above, I'd like to point that in RHEL/CentOS 8+ and Fedora we have crypto policies which make setting up at least (3) and (4) easy at system-wide level. It definitely should not be done on per-application basis. 389-ds already follows the system crypto policy in defining how TLS versions and ciphers get applied. If you need to amend settings by introducing a crypto policies' subpolicy, I'd suggest to consult man pages for 'update-crypto-policies(8)' and 'crypto-policies(7)'. Regards, Alex Ivanov On Tue, Jan 31, 2023 at 6:18 PM Alexander Bokovoy 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/7fcdce70-5205-44d6-9c3a-260e616a2f04 and then https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/895a7744-aff3-4f64-bcfa-f8c05915d2e9 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: 050406ff0262b065c0d8351b29fd1943<80> 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
[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 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/7fcdce70-5205-44d6-9c3a-260e616a2f04 > and then > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/895a7744-aff3-4f64-bcfa-f8c05915d2e9 > > 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: 050406ff0262b065c0d8351b29fd1943<80> > 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: 050406ff0262b065c0d8351b29fd1943<80> > 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
[Freeipa-users] Re: Force LDAPS and 636 port
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/7fcdce70-5205-44d6-9c3a-260e616a2f04 and then https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/895a7744-aff3-4f64-bcfa-f8c05915d2e9 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: 050406ff0262b065c0d8351b29fd1943<80> 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: 050406ff0262b065c0d8351b29fd1943<80> 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 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do
[Freeipa-users] Re: Force LDAPS and 636 port
SSF enforces key length or something else? I didn't quite understand what it is all about. вт, 31 янв. 2023 г., 17:09 Rob Crittenden : > 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. > > IPA requires port 389 and uses startTLS/GSSAPI to encrypt its connections. > > You can try setting minSSF to reject unencrypted requests (except for > the basedn). > > rob > > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Force LDAPS and 636 port
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. IPA requires port 389 and uses startTLS/GSSAPI to encrypt its connections. You can try setting minSSF to reject unencrypted requests (except for the basedn). rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Force LDAPS and 636 port
Use the built-in OS firewall to block port 389 - depending on what distro/version, this could be a number of different firewalls (firewalld, ufw, iptables, etc.) - Y Sent from a device with a very small keyboard and hyperactive autocorrect. On Tue, Jan 31, 2023, 7:34 AM Alex Ivanov via FreeIPA-users < freeipa-users@lists.fedorahosted.org> 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. > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > 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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
