MIT, Heimdal and Re: [PATCH] Log transaction and authentication durations.

Wed Jun 20 17:23:27 UTC 2018

On Wed, 2018-06-20 at 08:18 -0400, Simo Sorce via samba-technical
wrote:
> On Wed, Jun 20, 2018 at 06:55:55PM +1200, Andrew Bartlett via samba-technical wrote:
> > On Wed, 2018-06-20 at 08:04 +0200, Andreas Schneider wrote:
> > > On Wednesday, 20 June 2018 07:09:54 CEST Andrew Bartlett via samba-technical 
> > > wrote:
> > > > 
> > > > Andreas:  Just a heads-up that this while I've confirmed this builds
> > > > with MIT, you will probably need to take it into account when getting
> > > > the auditing enabled for the MIT KDC.
> > > 
> > > Quoting you from the 'heimdal: lib/krb5: do not fail set_config_files due to 
> > > parse error' thread:
> > > 
> > >     Once patches are in upstream git master (no need to wait for a release)
> > >     they can be back-ported.  This helps for when I get back to updating
> > >     our copy so we don't regress, so the effort is much appriciated.
> > > 
> > > The upstream hdb_auth_status callback takes 3 arguments, the one in the Samba 
> > > code takes 7 arguments!
> > > 
> > > You're obviously already in the Kerberos business and maintain a fork of 
> > > Heimdal! This seems to go in without any Heimdal upstream discussion if this 
> > > feature for testing is worth changing the HDB API or if there are better ways.
> > 
> > Yes, in the short term we have a fork of Heimdal, and clearly I'm
> > asking to do as I say, not as I do.  
> > 
> > What I will say is this:  Patches that either are not submitted and
> > accepted upstream or don't have comprehensive unit tests inevitably be
> > dropped or lost when I next do the upgrade.  Leaving cleanup and
> > similar patches just in our tree is simply asking for them to get
> > missed. 
> > 
> > While hardly a good enough reason, the reason the audit logging wasn't
> > done in Heimdal first is that:
> >  - upstream Heimdal has restructured that area of the code such that a
> > simple forward/backport is not possible
> >  - there is no public testsuite in upstream Heimdal for the hooks,
> > originally added for Apple (I think). 
> > 
> > So, yes, I plan to deal with this element of technical debt when I get
> > back to the re-sync.  While there will still be no upstream test, at
> > least then we can test it by proxy of Samba's tests.  
> > 
> > That is, it is not a hard and fast rule, but the more we follow it the
> > more practical my upgrade job is, so I just ask nicely.
> > 
> > > I think we will just not have auth logging support with MIT Kerberos or as an 
> > > untested feature.
> > 
> > OK, I've added this to the list of what isn't supported in MIT, (our
> > users do ask from time to time):
> 
> 
> Can you stop moving the goal post Andrew ?

No, I don't think this is a fair request.  

The Audit code has never been hooked into the MIT KDC, and in fielding
end-user feedback on the authentication audit code a reasonable request
to include timing information in it was received.  

We only got here because I gave Andreas a heads-up that he may wish to
ensure the hooks he is implementing cover that, or that he adds some
more exceptions to the tests.  

> > https://wiki.samba.org/index.php/Running_a_Samba_AD_DC_with_MIT_Kerbero
> > s_KDC#Known_Limitations_of_MIT_Kerberos_Support_in_Samba
> > 
> > The issue with the 'just ignore some features' approach is that it
> > makes getting out of Heimdal even harder, and so has us remaining in
> > this 'Keberos business'.  
> 
> The solution is to stop trying to add features downstream first, and go
> upstream to have them first, then come back to Samba.
> Yes it takes longer time, but it is the *right* way to do it.

I understand the suggestion, but even the audit hooks all the other
missing features were present and implemented in Samba before the MIT
KDC effort was 'finished'.

Now I will say the Audit code was unfortunate in timing, it landed at
almost exactly the same time as the MIT KDC effort for 4.7.  

But we never agreed, and I don't think we would have agreed, a feature
freeze of changes to the KDC layer while waiting for the MIT KDC. 

> > What we do need is feature parity, comprehensive testing parity and
> > automated testing, as discussed in this thread:
> > https://lists.samba.org/archive/samba-technical/2017-November/123755.html
> 
> No, we need to stop moving the goal post, cut our losses, move to ONE
> implmentation, and work with upstream *first* for anything else that is
> needed.
> 
> Once we are in good shape we get back to add features as, and if *really*
> neeeded (features also are expensive to maintain and Samba is already
> supercomplicated, so adding features should come with higher and higher
> barries.

The big issue from my perspective is that the MIT KDC effort, while a
laudable end-goal was never properly costed, and then was 'accepted'
out of pure exhaustion before it was ready.  If, as the time it was
accepted or in the year since it had come to feature parity, test
completeness and the other things Metze and I discuss in that link I
would be gladly speaking of simply removing Heimdal.  

I remember Volker asking me at SambaXP 2017 if I was looking to
maintain the Heimdal features out of nostalga.  It was a really fair
question, and at that SambaXP I was full of hope that we could really
move on.

However the Samba approach in all things has been gradual change, small
steps to a feature, one patch at a time.  The 'lift and shift' approach
has rarely been accepted, consider for example the NTVFS file server.  

The lift and shift approach for the MIT KDC effort failed in the same
way.  The effort is now, as far as I can tell from the development
pace, unfunded and never got to feature or testing parity:

 - It still isn't in autobuild!
 - It passes less (21 vs 32) of the Windows Protocol Test suites
 - It deliberately skips some of the few tests we have (kdc.canon not
reimplemented or cross-built)

The challenge is where to go from here:  Should we block every changes,
even small development efforts on completing the developer-year or more
of work required to finish the MIT KDC effort?

I continue to seek funding for that BTW, including for the tests to
prove it is safe.  But the numbers in my estimation are huge!

Finally, to be clear, when features are locked in with tests and in
autobuild, of course the MIT KDC should not be allowed to fall behind,
and must be patched to match any new requirements.

But we haven't got there yet.

> My 2c,
> Simo.

Understood.  I sadly can't concur. 

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