2

I am having trouble figuring out what is causing massive audit failures on a server 2008 system.

the event id is 4771
Account Name: Administrator
Service Name: krbtgt/DOMAIN.NAME
Client Address: ::1
Client Port: 0
Pre-Authentication Type: 2

The log happens in about 5 minute intervals and atleast 30 failure events are recorded.

It seems to be coming from the local machine and is a kerberos authenticaiton issue but I am not sure how to track down / correct the problem.

Services on the machine:

DNS 
Active Directory 
DHCP 
WSUS 
VIPRE enterprise

I have checked all scheduled tasks on the system and everything seems fine. I checked the Password on VIPRE and WSUS for invalid passwords. Not sure what is going on.

Thanks.

ADDITION: This event log appears on both my primary and secondary DC...

  TargetUserName Administrator 
  TargetSid S-1-5-21-2134851818-3285922005-2538191131-500 
  ServiceName krbtgt/JEWELS.LOCAL 
  TicketOptions 0x40810010 
  Status 0x18 
  PreAuthType 2 
  IpAddress ::1 
  IpPort 0 
  CertIssuerName  
  CertSerialNumber  
  CertThumbprint

Process is LSASS.EXE..

Jeff
  • 1,089
  • 5
  • 25
  • 46
  • you should add error or failure code details from the event before anyone can offer any suggestions. – maweeras Dec 23 '11 at 15:53
  • @maweeras that is all the information I have, which is why I am having a hard time solving the issue.. – Jeff Dec 23 '11 at 16:47
  • Are you still having that issue? I'd like to help. Have you tried a process of elimination, such as turning off services? Since it's happening every 5 minutes, this could narrow it down. Have you checked for any processes running that are not services? – Lucky Luke Jan 01 '12 at 03:26
  • @LuckyLuke I started another question that may be part of this problem, not sure 100 (found it in my process of tracking down this issue) http://serverfault.com/questions/346643/dcdiag-verifyenterprisereferences-test-failed-on-pdc – Jeff Jan 04 '12 at 19:33

1 Answers1

3

Finally Figured this out, for anyone who has a similar issue here was my solution:

The server was also a DHCP server. Under the IPv4 properties, the DNS dynamic updates registration credentials had the administrative account saved with the wrong password. Changing the saved password seems to have corrected my issues.

Jeff
  • 1,089
  • 5
  • 25
  • 46
  • Glad you figured this out! That's a pretty unusual thing to happen, how did you end up finding it? Luck? Process of elimination? Something else? Tracking things like this down that originate from a Windows component can be tricky. – Lucky Luke Jan 09 '12 at 02:40
  • @LuckyLuke I found it by luck. I was almost about to give up on this and call an outside support company to help figure it out. I even tried using the Account Lockout Management tools from MS , but it didn't get me to the source. I was double checking some refresh intervals on the DHCP server and discovered the registration credentials option. I didn't think that it was going to work - but then the errors stopped flowing in. Very nice. – Jeff Jan 09 '12 at 14:20
  • 1
    Interesting. I think a process of elimination should have worked in this case though. You mentioned a few services in your original question, and DHCP was one of them. I can only assume that switching off each of them for 15min or so (with the exception of AD, that is hard to switch off :-) ) would have revealed it? I'm only mentioning for the benefit of future, similar questions. This kind of thing happens quite frequently. – Lucky Luke Jan 09 '12 at 21:02
  • I have the EXACT same entry in the event viewer. No services or scheduled tasks use my account. I just updated the credentials for DHCP IPV4 properties to a different account, so hopefully that works for me too. Looks like when you update IPv4 credentials, IPv6 credentials get automatically updated as well. – joshgoldeneagle Dec 19 '17 at 23:51