Failure Reason: Unknown user name or bad... Expand / Collapse
Author
Message
Posted 12/7/2011 10:51:08 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: Forum Members
Last Login: 12/7/2011 10:19:40 AM
Posts: 3, Visits: 0
We are constantly receiving event log errors that the authenticated account we use with Arcserve has a bad password or something. I have 10 servers with Arcserve installed on it and 5 of them are reporting this error at the top of every hour. They all use the same authentication account.
12/07/2011 09:00:34 AMLogName=SecuritySourceName=Microsoft Windows security auditing.
EventCode=4625
EventType=0
Type=Information
ComputerName=SERVERDC3.OurDomain.local
TaskCategory=Logon
OpCode=Info
RecordNumber=70984967
Keywords=Audit Failure
Message=An account failed to log on.
 
Subject:
Security ID:S-1-5-18	
Account Name:SERVERC3$	
Account Domain:	OurDomain	
Logon ID:0x3e7
Logon Type:4
Account For Which Logon Failed:	
Security ID: S-1-0-0	
Account Name:causer	
Account Domain:	SERVERDC3
Failure Information:	
Failure Reason:	Unknown user name or bad password.	
Status:	0xc000006d	
Sub Status: 0xc0000064
Process Information:	
Caller Process ID: 0x1434	
Caller Process Name:	C:\Program Files\CA\SharedComponents\ARCserve Backup\UniAgent\UnivAgent.exe
Network Information:	
Workstation Name:	SERVERDC3	
Source Network Address:	-	
Source Port:		-
Detailed Authentication Information:	
Logon Process:		Advapi  	
Authentication Package:	Negotiate	
Transited Services:	-	
Package Name (NTLM only):	-	
Key Length:	0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. 
This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network). 
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. 
Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

=====

next error for the same server:

12/07/2011 09:00:34 AM
LogName=SecuritySource
Name=Microsoft Windows security auditing.
EventCode=4776
EventType=0
Type=Information
ComputerName=SERVERDC3.OurDomain.local
TaskCategory=Credential Validation
OpCode=Info
RecordNumber=70984966
Keywords=Audit 
FailureMessage=The computer attempted to validate the credentials for an account.
Authentication Package:	MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:	causer
Source Workstation:	SERVERDC3
Error Code:	0xc0000064


We have multiple servers with Arcserve, this error is occuring on a number of the servers, but not all of them.

The account used is a domain authenticated account and is used for all the servers with Arcserve installed. So we're trying to identify

why this error is occuring.

Version of ARCserve and OS:

OS is Windows server 2008 R2 with SP1, Arcserve version is 15R build 6222

Any suggestions are appreciated.

Roger

Post #868
Posted 12/8/2011 8:10:24 AM
Expert

ExpertExpertExpertExpertExpertExpertExpertExpert

Group: Administrators
Last Login: 4/20/2009 7:57:33 AM
Posts: 326, Visits: 0
But I assume your backups are running fine?  My thought is that it is first trying to service the logon as a local user account instead of a domain account, then it must try it as a domain account?  Do you see successful logon as "causer" with your domain name as the account domain shortly after these 2 events?  Note that the "account domain" in the 4625 you sent me is your computer's name, not the domain.  that backs up my theory. 
Post #869
Posted 12/8/2011 3:31:53 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: Forum Members
Last Login: 12/7/2011 10:19:40 AM
Posts: 3, Visits: 0
RandyFranklinSmith (12/8/2011)
But I assume your backups are running fine?  My thought is that it is first trying to service the logon as a local user account instead of a domain account, then it must try it as a domain account?  Do you see successful logon as "causer" with your domain name as the account domain shortly after these 2 events?  Note that the "account domain" in the 4625 you sent me is your computer's name, not the domain.  that backups my theory. 

yes, the backups are running fine. Yes, there are successful logins for the user account "causer" before and after these errors.  The cumputer name vs domain name issue seems to be consistant in the series of error messages. causer is a valid domain account with rights to log into all our servers that CA applications are installed to.

We have 10 servers plus a primary server with Arcserve installed. We were seeing this error consistantly on the beginning of every hour on 5 of the servers till Monday. This past Monday (at CA's request) we installed SP1 on the primary server and one of the servers at was having the error messages. Now, I'm seeing the same error messages on all the servers with CA app installed. Argh!

I had a support call with them this AM. They enabled PKI in the ConfigSRM PKI section and added a registry key for SRMReportTime.

Now several hours after the call, I'l still seeing the same messages. I'm going to wait till tomorrow to call them again.

Post #870
Posted 12/12/2011 9:04:49 AM
Expert

ExpertExpertExpertExpertExpertExpertExpertExpert

Group: Administrators
Last Login: 4/20/2009 7:57:33 AM
Posts: 326, Visits: 0
I think it's just what proposed above.  Nothing to worry about.  A hurdle in learning how to live with the security log is to accept that there will be noise events like this.  Backups are working and there's no security issue.  move on
Post #871
Posted 12/16/2011 4:16:31 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: Forum Members
Last Login: 12/7/2011 10:19:40 AM
Posts: 3, Visits: 0
Well, we seem to have stopped the errors. Not sure if the issue is resolved however. At present time, we've gone 4 hours with no further errors detected in the event logs on all affected servers.

The solution appears to have been to disable the SRM client from all the servers (primary and secondary) via the Central Agent Admin. We then restarted all the CA services on all the machines.

Hopefully this is a workable fix and doesn't bite us somewhere else in the future.

Thanks for your suggestions.

Roger
Post #877
« Prev Topic | Next Topic »


Permissions Expand / Collapse

All times are GMT -5:00, Time now is 9:51am