cancel
Showing results for 
Search instead for 
Did you mean: 

BERemote failed logins using odd credentials

BillClark22
Level 4

New install of Backup Exec 2014, have installed the Windows Agent on a VMware virtual server.  Last 3 nights we have been receiving the following error in the Security Event log:

Event 4625

An account failed to log on.

Subject:
    Security ID:        SYSTEM
    Account Name:        <LOCAL SERVER>
    Account Domain:        <OUR DOMAIN>
    Logon ID:        0x3e7

Logon Type:            4

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:        <ESX Admin account>
    Account Domain:        

Failure Information:
    Failure Reason:        Unknown user name or bad password.
    Status:            0xc000006d
    Sub Status:        0xc0000064

Process Information:
    Caller Process ID:    0x140
    Caller Process Name:    C:\Program Files\Symantec\Backup Exec\RAWS\beremote.exe

Network Information:
    Workstation Name:    <LOCAL SERVER>
    Source Network Address:    -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:        Advapi  
    Authentication Package:    MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
    Transited Services:    -
    Package Name (NTLM only):    -
    Key Length:        0

Here's what I don't get.  The <ESX Admin Account> that is being used is setup properly in the Backup Exec Media Server under logon accounts, but it is used for accessing the ESX hosts themselves, not the guest servers.  That account exists only on the ESX servers, not as a user account in the local domain.  The guest server should be using a domain account setup specially just for the Backup Exec system and that is also setup as the default logon account.  This server, <LOCAL SERVER>, is actually backed up at 7PM and displays no errors and is successful.  The above error occurs about 4 hours later and no active jobs involving this server are running.  I have seen this same issue on 3 other servers, doing the exact same thing.  Any ideas on what is going on?

Note that this issue is not preventing jobs from being ran, but it is showing up in our security logs as a failed attempt for a "special access account" and our auditors see this and are questioning why it is happening.  This is the reason I need this resolved.  Thanks.

8 REPLIES 8

CraigV
Moderator
Moderator
Partner    VIP    Accredited

Hi,


1. Make sure you're running BE 2014 SP2 if you aren't already.

2. Remove the RAWS agent from the server in question, and run a push-install again from the media server.

Then report back here with an update.

Thanks!

VJware
Level 6
Employee Accredited Certified

Would you pls confirm if the BE account has all the rights per this KB - http://www.symantec.com/business/support/index?page=content&id=TECH129645

Secondly, is File/Folder or Application GRT enabled for the VM backup ? If yes, does disabling it get rid of the 4625 events ? Thanks.

BillClark22
Level 4

I am running BUE2014 SP2 on the media server.  I did check the remote agent on the trouble machines and removed any traces of communication with the old BUE2010 server, then I re-established the trust relationship.  This doesn't appear to have made a difference.  I'm going to try and remove the agent, then reinstall.

 

Also, it isn't a right's issue(I don't think).  It's an issue of the agent trying to use the wrong credentials and odd times.  For example data from a virtual server "Server1" that is joined to the domain, running the agent for Windows, is setup to go to disk at 7:00pm, it finishes by 7:15pm, then at 7:30pm it goes out to tape and it is done for the night by 8:00pm.  Why then do I get these failed login attempts trying to use the ESX "root-level" account hours later?  And it appears to be random.  So far 6 different servers are seeing this exact issue.

VJware
Level 6
Employee Accredited Certified

If its occuring outside the backup hours, it could be the automatic credentials check.

Click on the BE button - Configuration & Settings - BE settings and choose Logon Accounts on the left-side. Have a look @ the test settings on the right-pane.

BillClark22
Level 4

VJware: I do remember turning that feature completely off shortly after the initial installation.  I looked at the BUE details for each server that was experiencing this issue, and they all had the checkbox labeled "Include this server in the scheduled check for logon accounts" checked.  So I went ahead and unchecked that box for each and every server, and I've received no alerts over the weekend.  I will watch tonight to see if they appear or if they are truly gone.  Will post back with results.

BillClark22
Level 4

Seems to be no rhyme or reason to this event, and it's spreading.  Just got a failed logon notice for another server that originally had the BUE Agent installed on it last Friday.  It has done multiple backups and just last night at a time when it wasn't active, the BEREMOTE.EXE logged a failed logon attempt trying to use the "root" account.  The latest hotfix and BUE Agent update don't help.  Any ideas?

VJware
Level 6
Employee Accredited Certified

If it's outside the backup window and if the global setting about credentials check is off, I would recommend you to log a formal support case for an engineer to have a look @ your setup and figure out what's going wrong.

Smartpros
Level 1

I realize this is an older thread but I came across it while researching exactly the same issue within our environment and was wondering if there were any developments or resolutions to this behavior. We have a ticket logged with Veritas support, but it has been of no help.

Environment Summary

  • Backup exec 2016: media server is member of 'domain1'
  • mixed domain environment (no trust between the domains)
  • We have BE logon accounts used for both domain1 and domain2 remote servers 
  • media server correctly backs up remote servers, whether they are members of domain1 or domain2. 
  • We get multiple 4625 errors logged on each remote server (in domain2) every 4 hours. The media server is attempting to logon to domain2 servers using domain1 credentials.

(We have disabled all logon account checking and 'discover data to backup' features)