On the Direction of Kerberos Support in libtdeldap #6

Basic information

TDE version: Development - master
Distribution: Any with krb5 installed by default
Hardware: In theory, any.

Description

This is more of a direction of travel issue than a specific fault.

I would point out that my knowledge of LDAP, Kerberos and SASL is rather limited and what I do know is based on what I have dug up, so if my assumptions are wrong, then that's the reason.

Version 14.0.8 of libtdeldap builds fine on my system. The 'master' development version does not due to the fact that the code appears to have been made dependent on heimdal being installed to the exclusion of the krb5 implementation of Kerberos V. Now this is not restricted to being a product of the homebrew nature of my installation; my understanding is that Redhat/Fedora/CentOS install krb5, BSD installs krb5 by default and there appears to be an option for both under Ubuntu.

From past experience, I know that krb5 and heimdal do not get along, they certainly mess with the other's files when installed in the same directories, and the general word seems to be that they are not binary compatible (i.e. you cannot just plug krb5 in-place of heimdal, or vice versa, and expect the software using it to work).

Making libtdeldap dependent on heimdal therefore presents a problem to those distributions/installations where krb5 has been installed. Now you could just skip build/installation of libtdeldap on those systems, however, tdebase now tests for krb5 and makes use of libtdeldap in the development version. If libtdeldap were to become a mandatory dependency for tdebase, then tdebase would effectively become unbuildable on systems using krb5.

I have made modifications to the cmake files to force a build against krb5, but some of the API calls used appear to be heimdal-specific and therefore cause problems linking with the krb5 libraries. This includes functions for HDB, the heimdal backend database.

As I have said, I do not know a huge amount about LDAP/Kerberos and therefore do not really understand what the modifications made in master actually do, but I would suggest that libtdeldap needs to be agnostic to the Kerberos implementation being used. If it is to be made dependent on heimdal, then consideration needs to be included for heimdal being installed in a separate location intended to prevent it colliding with krb5.

The impression that I get is that Kerberos elements in libtdeldap are more about access control rather than the specifics of using LDAP. The OpenLDAP documentation appears to suggest that the security mechanisms used are under the control of the administrator and are not intrisically linked to Kerberos. There is also the suggestion that SASL can be used, which would appear to be confirmed by my own build logs that show cyrus-sasl being linked into the OpenLDAP binaries.

My reading of the situation is that if SASL is involved that it can handle interactions with LDAP servers that rely on Kerberos, i.e. that it can function as an abstraction layer for the Kerberos functionality. If this is the case, then perhaps there is the opportunity to use SASL rather than a specific Kerberos implementation and allow the SASL library to handle the Kerberos side of things. It may also provide support on LDAP servers where a non-Kerberos access control solution is being used.

## Basic information - TDE version: Development - master - Distribution: Any with krb5 installed by default - Hardware: In theory, any. ## Description This is more of a direction of travel issue than a specific fault. I would point out that my knowledge of LDAP, Kerberos and SASL is rather limited and what I do know is based on what I have dug up, so if my assumptions are wrong, then that's the reason. Version 14.0.8 of libtdeldap builds fine on my system. The 'master' development version does not due to the fact that the code appears to have been made dependent on heimdal being installed to the exclusion of the krb5 implementation of Kerberos V. Now this is not restricted to being a product of the homebrew nature of my installation; my understanding is that Redhat/Fedora/CentOS install krb5, BSD installs krb5 by default and there appears to be an option for both under Ubuntu. From past experience, I know that krb5 and heimdal do not get along, they certainly mess with the other's files when installed in the same directories, and the general word seems to be that they are not binary compatible (i.e. you cannot just plug krb5 in-place of heimdal, or vice versa, and expect the software using it to work). Making libtdeldap dependent on heimdal therefore presents a problem to those distributions/installations where krb5 has been installed. Now you could just skip build/installation of libtdeldap on those systems, however, tdebase now tests for krb5 and makes use of libtdeldap in the development version. If libtdeldap were to become a mandatory dependency for tdebase, then tdebase would effectively become unbuildable on systems using krb5. I have made modifications to the cmake files to force a build against krb5, but some of the API calls used appear to be heimdal-specific and therefore cause problems linking with the krb5 libraries. This includes functions for HDB, the heimdal backend database. As I have said, I do not know a huge amount about LDAP/Kerberos and therefore do not really understand what the modifications made in master actually do, but I would suggest that libtdeldap needs to be agnostic to the Kerberos implementation being used. If it is to be made dependent on heimdal, then consideration needs to be included for heimdal being installed in a separate location intended to prevent it colliding with krb5. The impression that I get is that Kerberos elements in libtdeldap are more about access control rather than the specifics of using LDAP. The OpenLDAP documentation appears to suggest that the security mechanisms used are under the control of the administrator and are not intrisically linked to Kerberos. There is also the suggestion that SASL can be used, which would appear to be confirmed by my own build logs that show cyrus-sasl being linked into the OpenLDAP binaries. My reading of the situation is that if SASL is involved that it can handle interactions with LDAP servers that rely on Kerberos, i.e. that it can function as an abstraction layer for the Kerberos functionality. If this is the case, then perhaps there is the opportunity to use SASL rather than a specific Kerberos implementation and allow the SASL library to handle the Kerberos side of things. It may also provide support on LDAP servers where a non-Kerberos access control solution is being used.

Hi @aneejit1, excellent summary.

Yes, krb5 and heimdal have issues working together, we know that as well. The dependency to heimdal was introducded by Tim some years ago and so I am not sure what or why that is necessary.

Nevertheless, one of the open point for the release of R14.1.0 is to make the dependency on heimdal optional, together with the related code. That is it should be on a separate package that the user can install if he wants to, but not mandatory.

It would be even better if we had support for either heimdal or krb5, but that would require even extra work. Feel free to work on that, we can integrate the result in the code.

I was having similar problems until last year, when with good advise from Michele and Slavek I setup the repository properly.

Since then no issues with krb5 or heimdal. It might be @aneejit1 has to setup the installation properly too.