Hi. I just wondered whether samba really needs to use heimdal Kerberos, or whether MIT could be used as well. Reason is, MIT kerberos seems to be kinda default in Debian (I personally don't have anything in favour of either one or the other). Most "standard tools", e.g. ssh and much more is built again MIT Kerberos. Now Samba uses Heimdal, and everthing that pulls in samba (even libsmbclient) will pull in much Heimdal stuff as well. One example being gnome-control-center and therefore all GNOME. Cheers, Chris.
^ I suspect you're actually using Samba 4 rather than 3? The samba 3.x packages don't link against Heimdal. The Active Directory domain controller support in Samba 4 relies on Heimdal, and the functionality it depends on is not available in MIT Kerberos. There is an effort by RedHat to get Samba4 to work with MIT instead of Heimdal, but that project isn't complete yet: http://k5wiki.kerberos.org/wiki/Projects/Samba4_Port http://wiki.samba.org/index.php/Samba4/MIT_KDC Providing a custom source package with binary packages of Samba's client code linked against MIT Kerberos would be an option, but also a significant chunk of work. Cheers, Jelmer
notfound 726459 2:3.6.19-1 found 726459 2:4.0.10+dfsg-2 stop Ooops,.. sorry,.. forgot to adapt the Version field. Okay I see,... well than either close the bug, or keep it open for the records until RedHat has finished (I guess you might want to switch back then[0]). Well I guess you're right and that's overkill. Cheers, Chris. [0] Again, I have nothing pro/con Heimdal or MIT ... I just think it's best if Debian uses mostly the same... if MIT should be replaced by Heimdal for the later being generally better,... that should be a general discussion at d-d.
Hi, Most of this was done in Samba 4.8, but we still build with Heimdal in Debian. There are two reasons: - missing features [1] - fear to break things (especially on upgrade) I hope that the feature gap will decrease in 4.9 and later, but we probably won't migrate before buster+1 (i.e next-next stable) Regards
Hi, Most of this was done in Samba 4.8, but we still build with Heimdal in Debian. There are two reasons: - missing features [1] - fear to break things (especially on upgrade) I hope that the feature gap will decrease in 4.9 and later, but we probably won't migrate before buster+1 (i.e next-next stable) Regards
The missing features needs to be evaluated really, - how relevant these actually are these days. For example, "Computer GPO's are not applied" listed in that wiki pages seems to work fine. Things are easy to break indeed. But from the same wiki page it *seems* a switch is actually easy - the only thing needed is to create /var/lib/samba/private/kdc.conf file. I dunno how much this is true. How about buster+4? :)) Anyway, I implemented a build profile, pkg.samba.mitkrb5, to build whole samba (with the experimental ad-dc support) with mit-krb5. Dunno how it will go.. Thanks, /mjt
This is good to hear. That one scared me, not because breakage was unexpected, but because we couldn't tell why or how. We now have a much, much better testsuite that covers things pretty well, and know what tests the MIT KDC still fails. I don't really expect much breakage honestly, given the testsuite. That testsuite is why we were happy to upgrade the Heimdal version, which was just as much of a change and risk. There is no particular effort to address the lack of RODC support for the MIT KDC, and efforts to close the gaps shown by the testsuite are sporadic. It is also much harder to develop for the MIT KDC, as there isn't a standard vendored copy we can apply patches to and then filter to upstream (which is the process for Heimdal). These are fixed. This is the big one. Plus just other differences that may or may not matter as much. Andrew Bartlett
I'm currently working on getting FreeIPA into Debian, and this is one of the semi-blocking things for getting AD trust support into it. FreeIPA has a hard requirement on MIT Kerberos, so I'd be keen on hearing if there's been any news on this. As I understand it, RODC is still not available (as are claims), which I understand would be a problem. Is there any chance we could build two packages, one with Heimdal and one with MIT? That would be beneficial for testing and an eventual transition, letting package maintainers and system administrators transition over in a controlled manner.