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

I am seeing from multiple servers that the administrator account is generating Kerberos pre-authentication failed.
Event id 4771
Failure Code 0x18
Service Name krbtgt/<domainname>

It does this from our SharePoint server that host the Intranet page, my Symantec End Point Server and my Citrix XenApp Server indicated in the Event Log > Security

This transaction does occasionally lock the Administrator account out.

Any ideas?
LVL 29
yo_beeDirector of Information TechnologyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
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.
yo_beeDirector of Information TechnologyAuthor Commented:
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?
btanExec ConsultantCommented:
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.
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..
Your Guide to Achieving IT Business Success

The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.

yo_beeDirector of Information TechnologyAuthor Commented:
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.
btanExec ConsultantCommented:
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.
yo_beeDirector of Information TechnologyAuthor Commented:
This is not a DC.
The event log on the DC's points to the SharePoint server.

Kerberos pre-authentication failed.

Account Information:
      Security ID:            XXXXXX\Administrator
      Account Name:            Administrator

Service Information:
      Service Name:            krbtgt/XXXXXX

Network Information:
      Client Address:            ::ffff:
      Client Port:            3546

Additional Information:
      Ticket Options:            0x40810010
      Failure Code:            0x18
      Pre-Authentication Type:      2

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

Certificate information is only provided if a certificate was used for pre-authentication.

Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

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
Source:        Microsoft-Windows-Directory-Services-SAM
Date:          8/1/2016 9:51:11 PM
Event ID:      12294
Task Category: None
Level:         Error
User:          SYSTEM
Computer:      XXXDC02.XXXXXX.local
The SAM database was unable to lockout the account of Administrator due to a resource error, such as a hard disk write failure (the specific error code is in the error data) . Accounts are locked after a certain number of bad passwords are provided so please consider resetting the password of the account mentioned above.

btanExec ConsultantCommented:
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...
yo_beeDirector of Information TechnologyAuthor Commented:
I have enabled kerbos logging on the server causing the errors and I am getting closer i think
btanExec ConsultantCommented:
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.
yo_beeDirector of Information TechnologyAuthor Commented:
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?
btanExec ConsultantCommented:
Error 3 is network logon. I believe it is the SPN but it should be typically for web apps in the form of "HTTP/" as shared in the below article.
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/" 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/ 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?
yo_beeDirector of Information TechnologyAuthor Commented:
I have a DNS entry A RECORD that is 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$

Found 1 account

Since is the address everyone is hitting when they open IE could it be  that there is no HTTP SPN value for this
btanExec ConsultantCommented:
Looks like there is no SPN for as shared and likely there is minimally a need for HTTP/ if there is need to access<webapp>. maybe good to sniff some packet to diagnose as step through in my previous post on the article Part 3
So now let’s look at the network trace of this attempt.

1. We see proper name resolution, for and the DNS server response back with the IP Address of (frames 3 & 4)
2. The machine then makes an http connection to the web server, and gets “401 Unauthorized” (frames 7 -14).
3. The machine then gets a TGT from the domain controller (see the AS-REQ and AS-REP) (frames 15 & 16)
4. The machine then requests and gets a Service Ticket for http/ (frames 17 & 18). As you can see below, the machine was asking for a Kerberos ticket of HTTP/

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
yo_beeDirector of Information TechnologyAuthor Commented:
How would I leverage Wireshark to assess this.
I all looks like a bunch of mumdo-jumbo to me.
btanExec ConsultantCommented:
Pls reference my last post which they run steps looking out for 401 error

6. The machine then attempts to get a service ticket (TGS-REQ / TGS_REP) from the domain controller two more times in the trace, but each time the web server reports the same error of KRB5KRB_AP_ERR_MODIFIED (frames 15-18, 25-26, 34-37). The reason why you are seeing three different TGS-REQ / TGS_REP) requests to the domain controller is because you were prompted three times for user name and password when attempting to access the site before you got the 401.1 unauthorized error from the web server.

We need to do more investigation when you get the KRB5KRB_AP_ERR_MODIFIED. Keep in mind that this error really just means that the Service you are attempting to connect to could not decrypt the Kerberos ticket using its password Hash.

The first thing that we will test is to see if the Service Principal Name is registered to the correct account. If you remember from the previous blog the Web Application pool account that is running the website is Fabrikam\KerbSvc
yo_beeDirector of Information TechnologyAuthor Commented:
I am sorry, but I am really confused with this.
Let me look at this some more.
btanExec ConsultantCommented:
As explained on likely issues and advice given for follow up
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.