Understanding Security of port 80 and 389 for Identity Management Topologies

Updated

Concerning the use of port 80 (HTTP). Red Hat Identity Management(IdM) will normally redirect requests that arrive on port 80 to port 443, except for Online Certificate Status Protocol (OCSP) responses and the Certificate Revocation Lists (CRL). Both are digitally signed and therefore secured against man-in-the-middle attacks.

In regards to port 389 (LDAP). There are two types of connections to LDAP: anonymous and bind. Anonymous, as its name suggests, uses an unencrypted communication as it is connecting anonymously and usually has limited access to the LDAP server. Bind utilizes credentials provided by the selected authentication mechanism, typically a username and password, or a Kerberos ticket via the SASL GSSAPI/GSS-SPNEGO mechanism. Red Hat Enterprise Linux(RHEL) IdM clients use SASL GSSAPI authenticated binds to protect their LDAP connections. As a result, the connection is both encrypted and signed (sealed).

This behavior is due to the use of the Cyrus-SASL GSSAPI/GSS-SPNEGO plugin implementation. SASL plugins calculate maximum security strength factor based on the properties of the underlying authentication mechanism. Confidentiality (sealing) is enabled if the maximum SSF is above the external SSF by more than 1. If an application doesn't set an external SSF value, it defaults to 0, while the default Kerberos SSF is set to 112. This behavior is enforced by the Cyrus-SASL GSSAPI/GSS-SPNEGO plugin when using MIT Kerberos implementation.

On the LDAP connection, there is no enforcement of TLS encryption by default to prevent non-authenticated traffic or traffic before the StartTLS / SASL GSSAPI-authenticated request was issued. This configuration is left to allow autodiscovery from older RHEL clients to work as they use an anonymous LDAP connection to discover details of the RHEL IdM deployment. RHEL 8.4 or later IdM clients use StartTLS requests when discovering RHEL IdM over LDAP connection. This particular patch to realm package hasn't been backported to RHEL 7 or RHEL 8.3 and earlier yet so realmd clients on those deployments would still fail when non-authenticated access is blocked to IPA LDAP servers.

RHEL IdM does not use port 636 (LDAPS) as it is not a finalized IETF standard. It was part of an early draft of RFC 2255 but was removed before it was published. Enforcing the use of LDAPS protocol would require the presence of the CA certificate chain information before RHEL IdM client enrollment. This would require more manual work from system administrators to enroll RHEL IdM systems. If such manual work is feasible in a specific customer deployment, then using Kerberos PKINIT to secure LDAP connections with SASL GSSAPI is a reasonable workaround as well. Kerberos PKINIT use also requires advance distribution of the CA certificate chain information.

Disclaimer: Links contained herein to external website(s) are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content.

Reference Information:

Product(s)
Article Type