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 <aboko...@redhat.com>
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: 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
--
/ 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 not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
