Good information! Yet another way for readers to be able to determine how users are logging in and authenticating on the network. Thanks!

Scott

Something you may not be aware of that happens with Linux clients - if you enable failure auditing for Account Logon Events, you will get an Event ID 675 Failure Audit preceeding the Event 672. The text of the event will look like this:

Pre-authentication failed:
User Name: adg
User ID: EXAMPLE\adg
Service Name: krbtgt/EXAMPLE.COM
Pre-Authentication Type: 0×0
Failure Code: 0×19
Client Address: 192.168.192.129

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

These errors are logged because the MS Kerberos implementation expects the initial TGT request to contain a ‘preauthentication’ blob which is a time stamp encrypted using the user’s password hash as an encryption key (PA_ENC_TIMESTAMP in Kerberos-speak) - this preauthentication is used to prevent replay attacks. The Linux Kerberos libraries dont send this blob in their initial TGT request. When it receives the TGT without the preauthentication blob, the AD server:
1. Rejects the initial request
2. In the reject response, indicates that Preauthentication is required and hints with a list of acceptable preauthtcation types.
2. Logs the 675 error in the Event log.
On receiving the rejct response, the Linux Kerberos libraries resend the TGT request but this time include the preauthentication blob in the TGT request.

You can disable preauthentication on a per-user basis - in AD Users & Computers, tick the ‘Do not require Kerberos preauthentication’ box in the account properties tab, but it does make the account easier to hack.

The ideal solution would be to patch the Kerberos libraries to offer up a preauthentication blob at the first TGT request but I’ve yet to see any implementations yet - I suspect because this sort of patch could break interop with other Kerberos implementations - you need to declare what type of crypto (RC4, DES-CBC) you are going to use at the outset rather than negotiate between the client & server what type of crypto is acceptable to both.

David G