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

[Andrew Bartlett]

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
area!

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba



-------------- 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: <http://lists.samba.org/pipermail/samba-technical/attachments/20171115/5e34af3f/signature.sig>