Nico Kadel-Garcia <nkadel@xxxxxxxxx> writes: > Robert Marcano <robert@xxxxxxxxxxxxxxxxx> wrote: >> Nico Kadel-Garcia wrote: >>> Alexander Bokovoy <abokovoy@xxxxxxxxxx> wrote: >>>> On Mon, 02 Sep 2019, Dario Lesca wrote: >>>>> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto: >>>>>> >>>>>> I switched to run Samba DCs on a container with non Fedora / RHEL / >>>>>> CentOS provided RPMs. >>>>> >>>>> Thank Robert for reply. >>>>> >>>>> Then why don't release samba compiled with Heimdal kerberos? >>>>> >>>>> Just change a flag in build time, and all can use it into a production >>>>> environment. >>>> We do not support Heimdal builds in Fedora. It is not possible to reuse >>>> components of Samba built against Heimdal within other applications >>>> compiled against MIT Kerberos. This is, in particular, a show-stopper >>>> for FreeIPA and SSSD integration. >>> >>> My personal experience is that this is not true. sssd in a recent >>> Fedora (Fedora 29 last year) works just fine against an honest-to-god >>> Samba 4.9 domain controller on RHEL 7. I've not tested tested it with >>> samba 4.11rc2 yeat, as I'm still working on that port. sssd also works >>> against a real AD controller. sssd does not rely on a freeipa server. >>> It has genuinely unfortunate behavior of pre-downloading the *entire* >>> LDAP tree, and breaking if it can't complete this, but that's another >>> issue that won't be visible in most small test environments with local >>> domain controllers. >> >> The parent poster is refering to having two Kerberos implementations >> on the same process, not from two different machines. For example, an >> application linking against Samba libraries with Heimdal and at the >> same time linking with system MIT Kerberos for another features of >> that application unrelated with Samba. > > Sorry to sound critical, but this is irrelevant because, to use domain > controller enabled Samba, it compiles its own internal Kerberos. There > are other system libraries which Samba shares, such as libtalloc and > libldb, but for the comain controller. As best I can tell with sssd, > it's not been a problem. I did not run FreeIPA at all after some > failed attempts, and found with Samba compatible completely with AD > and the clients able to work, I had no use for it. So the libraries > did not overlap. > > If FreeIPA were dropped from Fedora, would there remain any reason to > prefer MIT Kerberos over Heimdal Kerberos? It's not that I object to > the MIT Kerberos, I know several of the authors personally as old > friends. But that's not a reason to prefer the software. Hi, your Fedora krb5 maintainer here. I have met and work with several Heimdal developers, and have nothing against them or their project; they generally do good work. Heimdal was until very recently inactive upstream. This resulted in its removal from Debian for a time, and projects like samba relied on *heavy* downstream patching of in-tree Heimdal builds to handle this. MIT krb5 has been the feature leader: plenty of APIs that we wish to use (e.g., the KEYRING ccache type, or gss_acquire_cred_from/store_cred_into) simply don't exist on released versions of Heimdal. You may also be interested to know of our porting efforts: thanks to Andreas's work, most of samba now can run on distro builds of MIT krb5. So if we're going to pick a default to build everything against, we're going to go with MIT krb5. But nothing stops us from having heimdal in Fedora, and indeed we do. Distributions with more robust alternatives systems (e.g., Debian) have had packages build against both; in my opinion this is more effort than it's worth. You end up exposing all the compatibility issues (libgssapi is standardized; libkrb5 is not; the ccache format is ad hoc best effort compatibility; the KDC interlink protocols are different; etc.), and there's no gain. If you find something in Heimdal that you need from MIT krb5, I'm happy to discuss it (over bugzilla); I'm very active in upstream development and standardization work. Thanks, --Robbie -- Robbie Harwood Kerberos Development Lead Security Engineering Team Red Hat, Inc. Boston, MA, US
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
