On Sat, 2017-02-18 at 10:36 +0100, Dario Lesca via samba wrote:> > Centos [6,7]* however does not have into current samba 4.x version > fully support to AD DC (without rebuild the source with some few > changes): > > > [lesca at dodo ~]$ rpm -ql samba-dc > > /usr/share/doc/samba-dc > > /usr/share/doc/samba-dc/README.dc > > [lesca at dodo ~]$ cat /usr/share/doc/samba-dc/README.dc > > MIT Kerberos 5 Support > > ======================> > ...The Samba build in Fedora is using MIT Kerberos > > implementation in order to allow system-wide interoperability > > between > > both desktop and server applications running on the same machine. > > > > At the moment the Samba Active Directory Domain Controller > > implementation is not available with MIT Kereberos. FreeIPA and > > Samba > > Team members are currently working on Samba MIT Kerberos support as > > this is a requirement for a GNU/Linux distribution integration of > > Samba AD DC features. > > > > We have just finished migrating the file server and all client > > utilities to MIT Kerberos. The result of this work is available in > > samba-* packages in Fedora. We'll provide Samba AD DC functionality > > as soon as its support of MIT Kerberos KDC will be ready. > > How do you deploy samba AD DC on Centos? > > Manually rebuild it or ...Yes, or find a package by a third party.> You know that Samba 4.7 will have support to AD-DC with MIT Kerberos?There is still a lot of work to do on that as I understand it, and even then it will require a very modern MIT Krb5, and probably not what is in RHEL. This will remain a long road, sorry. Even with all that, users of Samba as an AD DC often wish to obtain a version (due to bug fixes and new features) that is much more current than shipping when a RHEL freezes, so I wonder if it will really be that much use anyway. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
On Sat, Feb 18, 2017 at 12:58 PM, Andrew Bartlett via samba <samba at lists.samba.org> wrote:> On Sat, 2017-02-18 at 10:36 +0100, Dario Lesca via samba wrote: >> >> Centos [6,7]* however does not have into current samba 4.x version >> fully support to AD DC (without rebuild the source with some few >> changes):There are changes, but they're not outrageous. I've done some work towards it, at https://github.com/nkadel/samba4repo/, but you really wind up building up all the dependencies as well, and revising or replacing the logic around different versions for internally or externally built libraries. The structure there uses "mock" to build all the relevant library RPMs as well, and put them in local filesystem based yum repository. The requirement for gnutls-3.4.7 or later made me throw in the towel for building current releases on CentOS 7. I did not feel I had the time or tools to consider replacing the dependency chain for that critical security component. Recent Fedora releases, have mostly new enough components. The RPM's for Fedora rawhide, or my work, could be a good starting point. Not much other software uses libtalloc or similar libraries, so it may wiser to simply build the RPM with the internal versions. The last time I updated them at all, I restarted my .spec files and patches with those from Fedora rawhide. But the library requirements can be quite difficult to compile an even slightly older RPM based environment. Unfortunately, the last time I worked with it, I got bogged down in getting dnf to successfully use the locally built up dependency yum repository, and finally had to yield for other demands on my time. At this point, if I go back to trying, I'd throw out all the library dependencies and just compile the libraries internally. Since Samba seemed to be the only component using the lobtalloc and similar libraries, they made no sense to me to compile separately, as RHEL and thus CentOS have been doing. This has me looking back into the past. The first time I did a Samba port to new OS was..... for Samba 4.1.2? In 1993, I think? To get file shares and printing working from a Sparc 2 at a lab doing cochlear implant research. I needed to force people to stop using their own personal printing options and get them through a printer queue I could monitor. I also used to get the Windows boxes to write data to something we could back up reliably, since the human medical research data was not repeatable.>> You know that Samba 4.7 will have support to AD-DC with MIT Kerberos? > > There is still a lot of work to do on that as I understand it, and even > then it will require a very modern MIT Krb5, and probably not what is > in RHEL. This will remain a long road, sorry.Yeah. I interviewed for a Red Hat QA role years ago, for the sssd project, and they were interested that I knew personally a bunch of the Kerberos authors and maintainers from my undergraduate days. If any of them are unresponsive to queries from the Samba developers, maybe I can help reach them? I'll mention their names privately if you like, I'm not sure spamming the list with their names would be welcome.> Even with all that, users of Samba as an AD DC often wish to obtain a > version (due to bug fixes and new features) that is much more current > than shipping when a RHEL freezes, so I wonder if it will really be > that much use anyway.See above about gnutls 3.> Thanks, > > Andrew Bartlett
On Sat, 2017-02-18 at 19:47 -0500, Nico Kadel-Garcia wrote:> On Sat, Feb 18, 2017 at 12:58 PM, Andrew Bartlett via samba > <samba at lists.samba.org> wrote: > > On Sat, 2017-02-18 at 10:36 +0100, Dario Lesca via samba wrote: > > > > > > Centos [6,7]* however does not have into current samba 4.x > > > version > > > fully support to AD DC (without rebuild the source with some few > > > changes): > > There are changes, but they're not outrageous. I've done some work > towards it, at https://github.com/nkadel/samba4repo/, but you really > wind up building up all the dependencies as well, and revising or > replacing the logic around different versions for internally or > externally built libraries. The structure there uses "mock" to build > all the relevant library RPMs as well, and put them in local > filesystem based yum repository. The requirement for gnutls-3.4.7 or > later made me throw in the towel for building current releases on > CentOS 7. I did not feel I had the time or tools to consider > replacing > the dependency chain for that critical security component. Recent > Fedora releases, have mostly new enough components.To be clear, we don't require GnuTLS 3.4.7, the check there just means we use an alternate implementation of 'BackupKey' if that isn't available. We do require a GnuTLS version, but not the really recent one. The issue was that the older versions had bugs, but if you (as Red Hat does) wish to avoid Heimdal, you have to use a recent GnuTLS instead.> > > You know that Samba 4.7 will have support to AD-DC with MIT > > > Kerberos? > > > > There is still a lot of work to do on that as I understand it, and > > even > > then it will require a very modern MIT Krb5, and probably not what > > is > > in RHEL. This will remain a long road, sorry. > > Yeah. I interviewed for a Red Hat QA role years ago, for the sssd > project, and they were interested that I knew personally a bunch of > the Kerberos authors and maintainers from my undergraduate days. If > any of them are unresponsive to queries from the Samba developers, > maybe I can help reach them? I'll mention their names privately if > you > like, I'm not sure spamming the list with their names would be > welcome.We have no issues with the communications with Red Hat's staff or the MIT krb5 team, and I probably shouldn't have spoken so authoritatively about the plans of my fellow team members at Red Hat who have put in the work here over around 6 years now. However, my point is that Samba demands a lot from the KDC, and it would shock me if we ever got to a stable spot where a current Samba AD DC happily used a RHEL-stable version of the MIT KDC while still supporting all the features. The two are likely to need to march in parallel, as we have with our internal Heimdal fork. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba