Video Screencast Help

Backup systems with skewed clocks

Created: 20 Jun 2012 | 7 comments

Hi there,

 

We run two systems we need to back up with backup exec 2010 R3 which delibrately have incorrect hardware clocks which are not synchronised with our backup server due to the two systems being test environments for bespoke software. We get the normal 'Backup exec cannot creater a trust relationship with the remote agent' error due to this, and I need to get around the clock check to backup these systems. How would I do this?

 

Thanks!

Comments 7 CommentsJump to latest comment

CraigV's picture

...are you sure you don't have a firewall possibly blocking beremote.exe in this case?

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Simkill's picture

Yeah, I am sure. We have 3 other servers with exactly the same configuration with correct clocks and we have no issue connecting to those. The system specifically complains that it can't set up a trust relationship to this one machine due to it having an unsychronised clock. Symantecs resolution to the issue is 'Synchronise the clocks and try again' but this isn't a viable solution due to the server requirements.

Ken Putnam's picture

As long as these are physical servers, you can setup TimeSrv or connect to NIST using their app,

Preferably it would be the same time source that your media server is getting it's time hacks from

If this response answers your concern, please mark it as a "solution"

Colin Weaver's picture

Hmm kind of unusual requirment. If it is the certificates then you can see what happens if you disable them, however

a) this coudl open you up to a man-in-the-middle security breach

b) if it works you will have to disable certificates on all servers

c) it may not work as the skwed clocks might affects other communication requirments, not just the communciation security 

 

Info on security certificates:

 

 

These certificates were introduced in Backup Exec 2010 R3 after 3rd party specialists in IT security analysis notifed Symantec of a potential for a type of security breach between a media server and a remote agent that is known as a "Man in the Middle" attack.

You can disable this functionality with a registry change, however if you do this you will open up a potential security flaw so will need to take other steps to ensure that your security is not compromised. As such it becomes a "use at your own risk" option and should really only be used as a short term workaround for an issue that Symantec are already investigating. If you use it for an issue we are unaware of then obviously we will never fix the issue. We are aware of current problems with the TLS Handshaking that is affecting publishing and other functionality with Backup Exec, as part of

http://www.symantec.com/docs/TECH168154

As such if any customer uses the details provided below as a workaround,  the changes should be undone once notification of a full solution of the issue has been made public. 

 

WarningIncorrect use of the Windows registry editor may prevent the operating system from functioning properly. Great care should be taken when making changes to a Windows registry. Registry modifications should only be carried-out by persons experienced in the use of the registry editor application. It is recommended that a complete backup of the registry and workstation be made prior to making any registry changes

 

Create a DWORD value in

HKLM\SOFTWARE\Symantec\Backup Exec For Windows\Backup Exec\Engine\Agents

called

Security Disabled

Set the value to 1

 

This must be done on media server and remote server and the Backup Exec services on the servers will need restarting after the change

Stringo's picture

We are having the same problem with a Linux system, so we are unable to make the registry changes you have mentioned. How would we work around this issue on Oracle Linux 6.2?

Colin Weaver's picture

I think a similar entry can be made inside teh RALUS.CFG on linux systems. However is your version of Linux on our SCL?

Simkill's picture

No it isn't, but we also have it running fine on OEL 6.2 with the correct time configured.