working long-term with the MIT KRB5 codebase in the AD DC
abartlet at samba.org
Tue Nov 14 23:24:35 UTC 2017
On Tue, 2017-11-14 at 17:54 +0100, Stefan Metzmacher wrote:
> 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
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 862 bytes
Desc: This is a digitally signed message part
More information about the samba-technical