Zen, if I remember correctly, you wanted to look into this, right?

We probably should add KRB5_TRACE=/dev/stderr evn var for kinit to see more info.

KRB5_TRACE seems like a good idea, though we might need to sanitize the output as it may contain user names (and possibly other sensitive stuff).

I managed to reproduce only when "use kerberos des encryption types for this account" checkbox is set for the user.

Not much in the kinit trace.
1485193225.340113: Getting initial credentials for weak@CHROME.LAN#012
1485193225.344347: Sending request (148 bytes) to CHROME.LAN#012
1485193225.345600: Resolving hostname winmain.chrome.lan.#012
1485193225.347048: Sending initial UDP request to dgram 100.107.70.142:88#012
1485193225.348162: Received answer (132 bytes) from dgram 100.107.70.142:88#012
1485193225.348674: Response was not from master KDC#012
1485193225.348854: Received error from KDC: -1765328370/KDC has no support for encryption type#012
1485193225.348944: Retrying AS request with master KDC#012
1485193225.348956: Getting initial credentials for weak@CHROME.LAN#012
1485193225.349023: Sending request (148 bytes) to CHROME.LAN (master)#012

According to [1], "Use Kerberos DES Encryption types for this account" disables all ciphers except DES.  Under this condition failing to authenticate is expected and correct behaviour.

Miguel & Miguel, can you still repro authentication failure for the Administrator@CHROMEOSDEMO.LOCAL account?  If yes, could you please look whether there's something relevant in the "Application, Security, and System logs", especially under the Microsoft-Windows-Kerberos-Key-Distribution-Center source? [2]

[1] https://blogs.msdn.microsoft.com/openspecification/2011/05/30/windows-configurations-for-kerberos-supported-encryption-type/
[2] https://support.microsoft.com/en-us/help/977321/kdc-event-id-16-or-27-is-logged-if-des-for-kerberos-is-disabled

Closing. I think we've figured out encryption types.