working long-term with the MIT KRB5 codebase in the AD DC

Andrew Bartlett abartlet at
Tue Nov 14 23:24:35 UTC 2017

On Tue, 2017-11-14 at 17:54 +0100, Stefan Metzmacher wrote:
> Hi,
> I tend to hope that with the next import of heimdal, we would have been
> able to use a system Heimdal.
> But the work I had to do in the last weeks shows to me that it's not
> that easy :-(

Thank you very much for this mail. 

> As we don't have tests to show our KDC behaves exactly like a Windows
> DC, we're so far away of being able to rely on a more or less fixed
> system version of a KDC.

I strongly agree. 

> The actual problem was a customer with a complex web application
> using IIS on Windows 2012, which makes use of S4U2Proxy in order to
> communicate between frontend and backend servers.
> It took a week comparing traces between Windows and Samba in order
> to eleminate the differences in the generated Kerberos tickets
> (including the PAC) in order to finally find that we hit the
> timestamp mismatch between ticket and PAC problem again.
> Kerberos might not be as complex as SMB1, but it's not far from that.
> Which means we need real low level tests to prove we're implementing
> things correctly, without relying on kerberos client libraries
> or manual testing with Windows, we're basically where we were with SMB1
> 15 years ago.

Indeed.  The only start we have is the krb5.kdc and krb5.kdc-canon
tests, which still use the client libs but assert packets.  This isn't
nearly enough, and even then they are not been run cross-implementation 
between the MIT and Heimdal builds.

> Unless we have the prove that we're really compatible with a Windows
> DC, we'll have to rely on having custom versions of the KDC code we use,
> in order to provide a ready to use version of a KDC.

> I'm fine with moving heimdal to third_party, after the next import
> and then maintain our known good state in the lorikeet-heimdal repo
> where we can rebase it more easily on heimdal master and try to
> keep the patchset minimal (0 patches if possible).

I'm still hopeful I can complete the upgrade, but even our minimal
testsuite here has shown up issues, so this is taking much longer than
I had hoped.

> In order to have a tested KDC with MIT I'd propose to have it also
> under third_party, every other option is not useful for the near future,
> until we can really rely on having a stable code base in the upstream
> Kerberos projects (maybe only MIT in future).

I agree.  I realise it creates great difficulties for the enterprise
distribution model, but this needs to come second to 'we know and can
prove this works'.

> The fact that we need to implement a lot of new Kerberos features soon,
> in order to keep up with Windows 2012/2016 makes it even more problematic.
> I hope to find the time to create the start for low level
> kerberos tests, using pyasn1 and some python bindings for
> the krb5_crypto_* apis. Then we're hopefully be able to
> build something similar to the dcerpc raw protocol tests.

The other thing we can do is run the Microsoft tests more
systematically.  Garming is working on automating those in a way that
is compatible with Samba development practices. 

> For the reference, here're the bug reports I've recently opened:

Thanks for taking the time to write, I strongly agree with everything
you mention here, and thanks for all the hard work on this difficult

Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team
Samba Development and Support, Catalyst IT

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the samba-technical mailing list