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

[Andreas Schneider]

On Wednesday, 20 June 2018 08:55:55 CEST Andrew Bartlett 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):
> 
> 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'.

I don't have time to work on MIT Kerberos support for Samba AD at the moment. 
There are things with higher priority.

> 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

Well, you just add features to Samba Kerberos without any upstream Kerberos 
discussion and you say you might deal with it some day. What are you doing if 
Heimdal says, this change will not be accepted it is not well designed or too 
intrusive?

I can't keep up implementing new features, as I need to deal with MIT Kerberos 
upstream, make a proposal, have a discussion to get a good API which other 
will benefit from too.

If we continue like that we will never get MIT Kerberos or can ever update 
Heimdal which is from 2011! The Heimdal copy in Samba is ~1600 patches behind 
and who knows how many ahead ...


Cheers,


	Andreas


-- 
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at samba.org
www.samba.org