4771 logs, but no lockout happening.

Question

4771 logs, but no lockout happening. The lockout happens normally, but just with the webpage on using the same account it doesn't, however the logs for 4771 do generated. Want to know can this be application specific that account are not getting locked, but once the evenid 4771(0x18) is generated shouldn't this be locked out.

Need an Inside and help to troubleshoot

Answer 1

Hello,

Thank you so much for posting here.

This event generates every time the Key Distribution Center fails to issue a Kerberos Ticket Granting Ticket (TGT). This problem can occur when a domain controller doesn’t have a certificate installed for smart card authentication (for example, with a “Domain Controller” or “Domain Controller Authentication” template), the user’s password has expired, or the wrong password was provided.

event ID 4771 (0x18) : KDC_ERR_PREAUTH_FAILED means "The wrong password was provided".

Reference: https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4771

If we enter the wrong password, there will be recorded logs 4771. We are wondering whether there are lots of 4771 logs? Is the same account or client address logged on this event 4771?

As mentioned, there are 4771 logs, but no lockout. So the account still could be logged on at last, right?

For any question, please feel free to contact us.

Best regards,
Hannah Xiong

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Thanks for the reply. The lockout threshold is kept as 5. So on entering 5 incorrect password while logging into system, the id does get locked. But if the same id is used in the application or webpage with 5 time wrong password, the ID doesnt get locked. strangely the 4771 event id get generated in the logs.

Answer 3

Hello,

You are welcome. Thank you so much for your kindly reply.

As for the same ID used in the application or webpage, so sorry that we do not have the similar scenario to do the test. I understand that the 4771 event will be recorded when entering the wrong password.

Administrators frequently struggle with repeated unexplained and seemingly spontaneous account lockouts for a given user account. This is frequently due to a workstation where a user account remains logged on after that account’s password been changed elsewhere. But there are many other possible reasons including stored credentials, programs that cache credentials, scheduled tasks, services, persistent track mappings, Active Directory replication problems and disconnected Terminal Services sessions.

Whether an account gets locked out depends on a combination of user account properties and domain account policies.

Thank you so much for your understanding and support.

Best regards,
Hannah Xiong

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 4

Hi,

Looks like you are not able to understand my issue. You are explaining me about lockout which I already know. I am asking why the account is not getting lockout even after multiple 5 attempts(which is set through policy). But this is only from the application or weburl.

Answer 5

Hello,

We still facing the same "issues" . We have the Default Domain Policy which set lock account after 5 invalid logon attemps and reset after 60 minutes.

We detected more than 5 invalid logon in less than 1 hour with Event ID 4771 BUT the account is not locked out ==> No event ID 4740

I m interested also to know why we see a lot of kerb pre auth failed but no auto locked out for this account.

Thanks,