0x19 KDC_ERR_PREAUTH_REQUIRED in my event log

So I have a server, and every time a user or service account logs on to the machine, an error event is generated in the System log:

A Kerberos Error Message was received:
 on logon session DOMAIN\serviceaccount
 Client Time: 
 Server Time: 12:44:21.0000 10/9/2012 Z
 Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
 Extended Error: 
 Client Realm: 
 Client Name: 
 Server Realm: DOMAIN
 Server Name: krbtgt/DOMAIN
 Target Name: krbtgt/DOMAIN@DOMAIN
 Error Text: 
 File: e
 Line: 9fe
 Error Data is in record data.

So of course I Googled this, and the only information I'm getting for it is that "it doesn't necessarily indicate a problem and you can usually ignore it."

Well, gee, that's great, but these errors are spamming my System log about once a minute and I'd really like to make them stop. Any ideas?

From the Microsoft AskDS blog:

KDC_ERR_PREAUTH_REQUIRED

If you see this error in the trace, it does not indicate there is a problem at all. The client requested a ticket but did not include the pre-authentication data with it. You will typically see the same request sent again with the data and the domain controller issuing the ticket. Windows uses this technique to determine the supported encryption types.

I can't help you stop them; I'm afraid I'm a Linux person. I can at least explain them. Understanding this message requires a bit of a digression into how Kerberos authentication works.

The basic Kerberos authentication process is for the client to request an encrypted TGT from the KDC, which it then decrypts with its local key. However, naively implemented, this allows an attacker to download the TGTs for every user in your realm and then try to decrypt them via brute force attacks at the attacker's leisure. Kerberos therefore added a mechanism called preauthentication.

The way preauthentication works is that the KDC, when it receives the TGT request, sends back a preauthentication challenge rather than just sending back the TGT. The preauthentication challenge can take various forms, but the most common asks for the client to send the current time encrypted in the client's key. The KDC then confirms the client can do that (which indicates some knowledge of the client key) before sending the TGT.

However, in part because preauthentication was added on and in part because the client doesn't know what preauthentication challenge will be sent, the client always sends the basic TGT request and the KDC then always rejects it with a preauthentication challenge. Those log messages are Active Directory logging the fact that it got a TGT request without preauthentication and sent back a challenge.

Your guess is as good as mine on why it bothers to log this, since it's a normal part of the protocol and not horribly interesting, but all the Linux-based KDCs do the same thing.

I was having the same problem on my server and it was filling my server with errors. I found this registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters ) in Microsoft Support knowledge base (https://support.microsoft.com/en-us/kb/262177) and removed it and now it seems to be working great.

KDC_ERR_PREAUTH_REQUIRED is returned on the initial Kerberos AS request. By default, the Windows Kerberos Client is not including pre-authentication information in this first request. The response contains information about the supported encryption types on the KDC, and in case of AES, the salts to be used to encrypt the password hashes with.

Recommendation: Always ignore this error code.

https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging

While the question has already been answered by user @Tony, it is not clear enough about the actual reason:

One day someone turned on verbose logging of Kerberos events on the server. And to disable it you should delete the following registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Registry Value: LogLevel
Value Type: REG_DWORD

In fact, completely removing the specified registry key will also work but it's not the best idea.

At first, it may contain any other important settings that can be critical in some cases (for example, MaxTokenSize, which solves authentication issues when user account are member of a very large number of domain groups).

But the main reason is that this registry key exists in clean Windows install, although it does not contain any values in it. Therefore it is best idea to leave it in its original state (empty) rather than deleting it. Being empty and being non-existent are definitely not the same thing.

I'm 99% sure that removing this particular key will not cause any trouble in future, but neither you and even neither developers themselves never know how the things can turn after you perform something unexpected :)