Security of LDAP connections in FreeIPA

[Kevin Cassar]

Hi,

As I understand, FreeIPA uses the 389 Directory server as its LDAP implementation. I
wanted to know few things about the LDAP connections and whether they are encrypted by
default. I tried googling, but couldn't find substantive documentation regarding
this.

So far, I know that the Directory Server supports a variety of secure connection types,
namely, on port 389 via STARTTLS, LDAPS (port 636) and SASL. However, I'm unsure about
what exact mechanism is used to secure (client --> server) and (server <-->
server) LDAP connections in FreeIPA, and whether I need to enable any attributes like
"Secure bind" for example, on the FreeIPA server.

In case of client --> server connections, I see that the /etc/ldap/ldap.conf has URI
set to LDAPS, but, running TCPDUMP on a client showed all outgoing connections to FreeIPA
server heading towards port 389. Similarly, I grepped the access logs for STARTTLS
connection indicator as defined in the link below, but couldn't find anything:
https://directory.fedoraproject.org/docs/389ds/howto/howto-starttls.html

I'm specifically looking to understand the security of client to server LDAP
connections, and server to server connections (when replication is set up.)

Any help is appreciated.

[Rob Crittenden]

Kevin Cassar via FreeIPA-users wrote:
>  Hi,
>  
>  As I understand, FreeIPA uses the 389 Directory server as its LDAP implementation. I
> wanted to know few things about the LDAP connections and whether they are encrypted by
> default. I tried googling, but couldn't find substantive documentation regarding
> this.
>  
>  So far, I know that the Directory Server supports a variety of secure connection types,
> namely, on port 389 via STARTTLS, LDAPS (port 636) and SASL. However, I'm unsure about
> what exact mechanism is used to secure (client --> server) and (server <-->
> server) LDAP connections in FreeIPA, and whether I need to enable any attributes like
> "Secure bind" for example, on the FreeIPA server.
>  
>  In case of client --> server connections, I see that the /etc/ldap/ldap.conf has URI
> set to LDAPS, but, running TCPDUMP on a client showed all outgoing connections to FreeIPA
> server heading towards port 389. Similarly, I grepped the access logs for STARTTLS
> connection indicator as defined in the link below, but couldn't find anything:
>  https://directory.fedoraproject.org/docs/389ds/howto/howto-starttls.html
>  
>  I'm specifically looking to understand the security of client to server LDAP
> connections, and server to server connections (when replication is set up.) 
Replication uses GSSAPI.

"client" is a rather flexible term.

sssd uses GSSAPI.

ipa-client-install does not use TLS by default during discovery as it's
a bit of a chicken and egg problem. If you have the cert chain you can
pass it to ipa-client-install and it will use it for all non-GSSAPI
LDAPI connections.

The connections that IPA services create to the LDAP server use either
startTLS, GSSAPI or ldapi (unix socket).

Connections from the CA to the LDAP server use TLS.

rob

[Alexander Bokovoy]

On ma, 05 huhti 2021, Rob Crittenden via FreeIPA-users wrote:
> Kevin Cassar via FreeIPA-users wrote:
> > Hi,
> >
> > As I understand, FreeIPA uses the 389 Directory server as its LDAP
> > implementation. I wanted to know few things about the LDAP
> > connections and whether they are encrypted by default. I tried
> > googling, but couldn't find substantive documentation regarding this.
> >
> > So far, I know that the Directory Server supports a variety of secure
> > connection types, namely, on port 389 via STARTTLS, LDAPS (port 636)
> > and SASL. However, I'm unsure about what exact mechanism is used to
> > secure (client --> server) and (server <--> server) LDAP connections
> > in FreeIPA, and whether I need to enable any attributes like "Secure
> > bind" for example, on the FreeIPA server.
> >
> > In case of client --> server connections, I see that the
> > /etc/ldap/ldap.conf has URI set to LDAPS, but, running TCPDUMP on a
> > client showed all outgoing connections to FreeIPA server heading
> > towards port 389. Similarly, I grepped the access logs for STARTTLS
> > connection indicator as defined in the link below, but couldn't find
> > anything:
> > https://directory.fedoraproject.org/docs/389ds/howto/howto-starttls.html
> >
> > I'm specifically looking to understand the security of client to
> > server LDAP connections, and server to server connections (when
> > replication is set up.)
>
> Replication uses GSSAPI.
>
> "client" is a rather flexible term.
>
> sssd uses GSSAPI.
>
> ipa-client-install does not use TLS by default during discovery as it's
> a bit of a chicken and egg problem. If you have the cert chain you can
> pass it to ipa-client-install and it will use it for all non-GSSAPI
> LDAPI connections.
>
> The connections that IPA services create to the LDAP server use either
> startTLS, GSSAPI or ldapi (unix socket).
>
> Connections from the CA to the LDAP server use TLS. 
A bit more on this.

We keep getting these questions for SSSD accessing AD or IPA LDAP all
the time. There is a somewhat glaring hole in public knowledge about
LDAP + SASL GSSAPI/GSS-SPNEGO behavior that most of administrators don't
know about.

If you'd do look into LDAP communication after LDAP bind was
successfully performed with SASL GSSAPI, you can see that the traffic is
encrypted. 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

Same with IPA LDAP communication from RHEL/CentOS/Fedora clients.

This behavior 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 an 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.

This is specific to use of Cyrus-SASL and MIT Kerberos since this commit
in Cyrus-SASL:
https://github.com/cyrusimap/cyrus-sasl/commit/4b0306dcd76031460246b2dabc...

It is part of cyrus-sasl-2.1.27 and backports were done to RHEL/Fedora
at the time.

The only 'problem' that I know about is that there is no enforcement by
default to prevent non-authenticated traffic or a traffic before
STARTTLS / SASL GSSAPI-authenticated request was issued. We keep
non-authenticated access to IPA LDAP enabled by default to allow realmd
clients to probe and discover IPA servers. This was fixed on realmd side
last year with
https://cgit.freedesktop.org/realmd/realmd/commit/?id=b53c3e5fb5c90813ce1...
and we need to complete https://pagure.io/freeipa/issue/7140 but this
particular patch wasn't backported to RHEL 7 and RHEL 8 yet so realmd
clients on those deployments would still fail when non-authenticated
access is blocked to IPA LDAP servers.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland