[PATCHSET] Samba AD with MIT Kerberos

Andreas Schneider asn at samba.org
Mon Mar 13 21:59:28 UTC 2017


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




More information about the samba-technical mailing list