[PATCHSET] Samba AD with MIT Kerberos

[Jeff Sadowski]

Does this mean I'll be seeing a samba-dc that actually has something more
than a readme file in fedora rawhide soon?

On Mon, Mar 13, 2017 at 3:59 PM, Andreas Schneider via samba-technical <
samba-technical at lists.samba.org> wrote:

> On Monday, 13 March 2017 18:40:21 CET Andrew Bartlett wrote:
> > On Mon, 2017-03-13 at 08:29 +0100, Andreas Schneider via samba-
> >
> > technical wrote:
> > > Hello,
> > >
> > > after more than 3 years of work I finally got this:
> > >     ALL OK (14658 tests in 2030 testsuites)
> > >
> > > The testsuite completed for the first time!
> >
> > Congratulations!
> >
> > > The journey started with the cwrap [1] project to make it possible to
> > > test
> > > Samba with the MIT KDC. We already pushed some code upstream
> > > especially code
> > > which not only handles MIT Kerberos but also fixed bugs with Heimdal.
> > > We
> > > discovered a lot of issues while working on this code.
> > >
> > > Attached is the patchset to implement the missing parts and get
> > > everything
> > > working.
> > >
> > >
> > >  46 files changed, 3113 insertions(+), 507 deletions(-)
> > >
> > >
> > > What isn't working yet
> > > ----------------------
> > >
> > > * KDC canon tests are not implemented yet
> > > * PKINIT
> > > * S4U2SELF/S4U2PROXY
> > > * RODC
> > >
> > >
> > > The patches are also available at [2].
> > >
> > >
> > > It requires MIT Kerberos 1.15.1! Packages for Fedora 25 can be found
> > > at [3].
> > >
> > >
> > > Review is much appreciated!
> >
> > I'm really, really impressed.  I'll look again, but I have no
> >
> > objections so far, other than for:
> > > Subject: [PATCH 01/49] s4:torture: Fix the remote_pac test
> > >
> > > All the Kerberos implementation do not expect an order of the pac
> > > buffer. The buffers are not processed in the oder they are sent but
> > > when
> > > required just located.
> > >
> > > I confirmed this with MS at the IO Lab.
> > >
> > > Signed-off-by: Andreas Schneider <asn at samba.org>
> >
> > For this patch, are we sure old Samba versions are not picky?  My gut
> > feeling at 6:30am is that our code there was pretty fragile, but it
> > seems that if so, the additions of LOGON_CREDS and the upn dns info
> > would have broken it anyway.
>
> I didn't find any issue. Also Microsoft doesn't care about the order so we
> would have noticed I guess.
>
> > Very, very well done.  Thank you for your persistence, congratulations
> > and many thanks for meeting the challenges given you, particularly
> > those landed on you (like the horror kdc and kdc-canon test still to
> > go) without much notice.
>
> The KDC tests are already done and I've added new once to confirm that some
> bugs I've fixed are working correctly.
>
> I will look into kdc-canon test soon.
>
> > Finally, from here, what do you see as the procedure to add features to
> > the MIT KDC?
>
> Implement it and create a pull request on github. You get very good
> feedback
> and changes are merged pretty quickly. I've implemented quite some stuff in
> MIT Kerberos to get to this point. The last thing was fixing a KDB issue
> where
> they changed the API and removed the possiblity to free memory. So talloc
> memory was not freed. I've implemented it in a sane way and Greg helped to
> improve it and merged it quickly.
>
> The only issue is that we need to wait for a major release to get new
> features. Greg and I already agreed to work on a libkdc. We need that for
> RODC
> support. I haven't had the time to think about an API yet.
>
>
> >
> > Specifically, about the time you land this, I hope to land the NTLM
> > logging patches Gary is working on, and follow up shortly  with similar
> > patches for Heimdal's KDC, so we spit out a similar JSON structure on
> > failure, and send it over Samba's message bus (that helps us write
> > tests).
> >
> > The hooks we have in Heimdal are not quite good enough for what we want
> > (can't catch unknown user), so we will need to add some more.  Assuming
> > the same applies in MIT, how should we get such hooks, and given
> > Samba's needs remain a moving target, how do you expect the engineering
> > pattern to work long term?   Will we try to support multiple MIT
> > versions with #ifdefs, or just the latest?
> >
> > Will it be OK for features to be Heimdal-only?  (And vice-versa).
>
> I will continue to work on MIT Kerberos support.
>
>
>         Andreas
>
>
>