1

Since May, our reporting tools are showing lots of failed authentication attempts against some of our DCs, for an account named host (which does not exist).

Event Viewer shows those failures as ID 4768 events:

A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:       host
    Supplied Realm Name:    CONTOSO.COM
    User ID:            NULL SID

Service Information:
    Service Name:       krbtgt/CONTOSO.COM
    Service ID:     NULL SID

Network Information:
    Client Address:     ::1
    Client Port:        0

Additional Information:
    Ticket Options:     0x40810010
    Result Code:        0x6
    Ticket Encryption Type: 0xFFFFFFFF
    Pre-Authentication Type:    -

Certificate Information:
    Certificate Issuer Name:        
    Certificate Serial Number:  
    Certificate Thumbprint:

Sometimes, multiple are logged within the same second, then there's a "break" of a few minutes before it starts again - it's not a fixed schedule.

Uninstalling KB5014692 and KB5014805 on one of the DCs had stopped the errors occuring there. That's obviously not a solution, though.

Where could this originate from?

Edit: Suddenly, some of these events don't originate from ::1 anymore, but from the on-premise exchange server - but not on all DCs. We are counting 25.000 failed authentication attempts a day because of this.

Edit 2: After spending months with M$ techsupport, their final statement is (quoted verbatim directly from a M$ support mail):

Disable/Stop Event ID 4768

You can disable or stop the audit Event 4768 by removing success and failure audit of Kerberos Authentication Service subcategory by using the following command.

auditpol /set /subcategory:"Kerberos Authentication Service" /success:disable

and also, it can be safely ignored and for some scenarios enable everything in the advanced auditing will generate a tons of unnecessary logs

This is the second time M$ support has suggested this.

To me, this is not a solution at all! Enhanced audit logging wasn't even enabled before we started noticing this exact issue.

Panki
  • 163
  • 2
  • 10

1 Answers1

1

We experienced the same issue. Please see this article for a possible resolution:

https://support.microsoft.com/en-us/topic/may-19-2022-kb5015019-os-build-14393-5127-out-of-band-8548dfda-38ba-4fb6-a7a3-42b86ac2cc81

In our case, we are still waiting for Microsoft to release a patch for this issue as their OOB patch does not work for the June release (which should have included it but does not appear to fully resolve the issue).

enforcer-99
  • 11
  • 2
  • Did you get any news regarding this? I've been in contact with M$ support aswell, I've added their answer to the question. – Panki Nov 30 '22 at 14:00
  • Yes. In our case, the issue ended up being related to our RADIUS server configuration. The solution was to set the Framed-MTU setting in our Network Policy Server to 1344. Apparently there was fragmentation of those RADIUS auth packets occurring which was causing the large number of RADIUS authentication failures. – enforcer-99 Dec 01 '22 at 15:56