My Sharepoint server keeps generating a Kerberos pre-authentication failed.

There may be some service running in the Symantec or Citrix  system using some fixed account and attempting to access SharePoint for some reason or scheduled basis request like back up etc. The Kerberos pre-authentication failure means that the user's password supplied does not match what is stored in database.

for example we had an application that was running reports under stored user credentials, once you've logged on it was using your credentials to run some sort of reports on your behalf with the same credentials forever

So probably the best way to go is to reveal the real client IP as described above and examine that machine what is running on it

there is one instance for Symantec for this error is when password is changed after some re-imaging of the system - see

Situation - When deploying a syspreped image the Altiris account gets locked after the image has been deployed

Cause - If the Altiris password has been changed after the sysprep image is created the original password is retained in the image sysprep.inf file.

https://support.symantec.com/en_US/article.tech170101.html

The SharePoint events are triggered when a user open the Intranet page, so I think all these are independent from one another.  

The question is how can I pin-point what process it trying to authenticate?

The event log states a Process Information section which records both the executable path and process ID. Example:

Process Information:
    Process ID:         0x2a4
    Process Name:       C:\Windows\System32\services.exe

A pre-authentication is just the process used to verify credentials prior to returning a token. There should still be a failure audit on the server attempting authentication which includes the process id. Not straightforward even though you see the id and try to run netstat or task mgr in the system as the id changes...we need to pinpoint if the system is the same one and may be will confirm via the account being lockout using Microsoft’s own LockoutStatus.exe.
https://blog.varonis.com/secrets-active-directory-lockouts-find-apps-stale-credentials/
However, as mentioned, it is not easy to drill to that process automatically, you need to check the batch job and any changes so far in the system and if it occurred during certain hours etc..

I am not able to pinpoint why the Service Name krbtgt/<domainname> it being used with my Administrator account from my SharePoint Server

I am not a sharepoint guru so I am not sure where to look for anything that is using  AD.

When I open the page is using my credentials to authenticate to the site.  When this happens I notice that the Administrator account generates the event id 4771 with a bad password 0x18

Hope this sheds some light on my questions.

I am wondering if your sharepoint is also your primary DC. Will be tough to validate and probably need to trace back event log to see such error occurence prior and after the roll up patch period. If you see your log with Client address having ::1, it is indicative of local machine and it means its service has problem login into the domain or to the PDC.

Note that this error is logged on domain controllers only and only failure instances of this event are logged. The error codes means usually a bad password. There is likely this account of the user that is wrongly set or even may mean your current login account may be doing the login to sharepoint that is not having valid password. You need your sharepoint support to advice you.

May want to see if there are prior event such as below on who has last login and probably that can give some hints or leads for more questioning.

http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4768

This is not a DC.
The event log on the DC's points to the SharePoint server.



This is the event the is generated when a user connects to Intranet Page hosted by SharePoint ,

I am also seeing this error in the system log on DC's.  On the PDC I see the Security Log event for the  Event ID 4771 pointing to the one of the other DC's (round-robin) and I will see the same time stamp for the Event ID 4771 pointing to the SharePoint server.  
Sometimes there are no other DC's involve accept the PDC.
Whatever DC that the SharePoint looks up some credentials of a user I will see the System error  Event ID:      12294 ten minutes earlier.  They are not at the same time, but they do happen frequently.

Log Name:      System

I am thinking how we can drill to process info in sharepoint pls see

Logon events record the process attempting logon. Enable failed logon auditing (Security Settings > Local Policies > Audit Policy > Audit Logon Events) in the Local Security Policy (secpol.msc) then look in the security event log for an event. You can also enable it via Group Policy, if that would be preferable.

There will be a Process Information section which records both the executable path and process ID.

see if we have more info in sharepoint events for security error. Have the account for admin been reset before or expired or recently changed...

I have enabled kerbos logging on the server causing the errors and I am getting closer i think

May want to check any account lockout event as well. For e.g. check for event ID: 4625 "An account failed to logon" that is the one that increments the lockout counter. If that category is actually being logged and you don't see the events, it means that the pre-authentication is failing for some other reason.

this is a Windows 2003 Server that is trying to authenticate.
It is running WSS 3.0.
I thought it might have been the App in the AppPool, but that is not the case that I can see.

I see SYSTEM account generating Security Logon/logoff Audit log at the same time I see the System event log log Kerbos error 3.

Could it be the SPN for this machine?

Error 3 is network logon. I believe it is the SPN but it should be typically for web apps in the form of "HTTP/webapp.fabrikam.com" as shared in the below article.
https://blogs.technet.microsoft.com/askds/2008/06/09/kerberos-authentication-problems-service-principal-name-spn-issues-part-2/
It actually stated in Part 1 a step through in Kerberos error troubleshooting which they are facing due to  duplicate Service Principal Name issues. This may be something you may consider to check further with your support team.

Usually this is when the Administrator has used the SetSPN on different accounts in an effort to get Kerberos Authentication to work. One great example of this is MS SQL. If you install MS SQL as an Administrator of the domain, it will add the MSSQLSVC SPN to the SQL Server’s computer account; later an Administrator changes the SQL Service startup account from Local System to a domain account and Kerberos Authentication starts to fail. Usually we will find that the MSSQLSVC SPN is configured on both the computer account as well as the domain user account that is used to run the service.

It has a follow up in Part 3 on proper Kerberos SPN configuration. It uses a QuerySPN.vbs script to find out what account(s) have the "http/webapp" or "http/webapp.fabrikam.com" SPN defined and is wrongly configured too

So we will use the QuerySPN.vbs script again to find out what account(s) have the http/webapp or http/webapp.fabrikam.com SPN defined. Review KB321044 if these tools are new to you.

As you can see the SPN is on the Web Server computer account. Well, this will just not work; we will need to take it off of this account and add it to the FABRIKAM\KerbSvc account using SetSPN.

NOTE: If we would have found that there were no duplicate SPN’s and that the only SPN registered in the Active Directory forest was correct we would have looked into a possible Active Directory Replication problem that might be causing the issue. You might be asking how could AD replication be causing the issue?

https://blogs.technet.microsoft.com/askds/2008/06/11/kerberos-authentication-problems-service-principal-name-spn-issues-part-3/

I have a DNS entry A RECORD that is inside.domain.com where the server internal entry in the FQDN server01.domian.local

When I run the querySPN.vbs

Class: Computer
CN=XXXXXXWEB02,OU=WU 3:00 Restart,OU=Servers,OU=All computers,DC=XXXXXX,DC=local
User Name: XXXXXXWEB02$
        WSMAN/XXXXXXweb02
        WSMAN/XXXXXXweb02.XXXXXX.local
        HOST/XXXXXXWEB02
        HOST/XXXXXXweb02.XXXXXX.local


Found 1 account

Since inside.xxxxxx.com is the address everyone is hitting when they open IE could it be  that there is no HTTP SPN value for this

How would I leverage Wireshark to assess this.
I all looks like a bunch of mumdo-jumbo to me.

I am sorry, but I am really confused with this.
Let me look at this some more.

As explained on likely issues and advice given for follow up