SEC 5.0 Backup/Restore

Hello tomerb,

to backup should AFAIK contain the necessary credentials (haven't tested lately). As for SophosUpdateMgr - it is used for writing to the share(s) and also in the updating policies (unless you have specified a different user). You can change the password if necessary so even if it would not haven been backed up there should be a major problem.

Christian

The problem with SophosUpdateMgr is, that the clients use this to connect to the server for updates. So, if the password changes, that most likely won't work any more. In a new installation I can set the password to a value known to me before any clients are installed, but this won't work for existing installations. So far I haven't found a way to make either the clients or the server tell me the password - even though they both "know" it.

Hello tomerb,

So far I haven't found a way to make either the clients or the server tell me the password

so obfuscation is effective - at least for you :smileywink:. Seriously - the password is transferred with the updating policies, as long as management works you just set the new password in the policies. There's the UpdateManagerHelper.exe tool to change the password (and/or if you want the name) of the Sophos Update Manager account. Note that the credentials are applied to all policies which reference the SUM's default share (\\SUMServer\SophosUpdate).

Christian

I'd be somewhat disappointed, if the password was only obfuscated. ;-)

If the password is transferred with the updating policies and updating doesn't require that password (which makes sense, because otherwise there'd be a chicken-egg-problem everytime the password is changed) then I'm just fine.

So, to come back to my original question:

After a complete re-installation on a fresh server the DataBackupRestore-Tool will produce a state where existing clients and the new server "talk" to one another. Therefore the clients automatically receive a new update policy including any (possibly changed) credentials for the SophosUpdateMgr account and updates work just as before.

Is that correct?

Thomas

Hello Thomas,

a chicken-egg-problem

I always take the knowledge of the architecture as granted. I'll try to make it short without omitting the essential details:

RMS

Whether you use protect computers, install manually (might also be scripted) from the share/CID or use a package built from the share the RMS component is configured from mrinit.conf. From this RMS gets the management server's "address" (one or more of IPv4, IPv6, FQDN or NetBIOS name), the "address" of the (RMS)router it should connect to (which is the same as the server unless you use message relays) and several keys which are used to verify and set up the communication partners. Once RMS has been initialized the client will only communicate with the server which presents the correct certificate (more on this later). RMS is used to pass policies and requests to and messages from the client - no credentials (e.g. SophosUpdateMgr) are involved. For further reading see Explanation of Sophos Endpoint Security and Control exceptions required for PCI compliance and Remote Management System: components and significant files.  

Updating

The client updates from the UNC or HTTP location (which is not necessarily the management server) specified in the policy. The host can be identified by FQDN, NetBIOS name or IP address. Usually credentials are required. They can either be set locally on the client or sent with an updating policy. 

New (or restored) server

• Clients can update from a new server if the applicable attribute matches the host identifier in the updating policy and the credentials allow access to the share. If they are different a new policy must be sent to the clients.
• Clients can communicate with the server if it has the same "address" and "identity" as the old one. For the latter it is important that you import the certificate registry keys (DataBackupRestore exports them to CertificationManager.reg) before you install SEC (see chapter 7 in the migration guide). 

(the following applies to Windows clients only)

If the clients can update and the server has the same identity but a different "address" RMS can be "redirected" by configuring the CID.

Whether the clients can update or not - if the new server has a different "identity" you have to reprotect (or otherwise reinstall RMS on) them in order to establish RMS communication (please see also How to redirect Windows endpoints to a new management server).

So, to answer your original question:

Read the Server to server migration guide carefully - a restore is in principle a migration (provided you have a valid backup) - and don't skip chapter 7! Some steps could be omitted if you are using domain accounts and/or the server has been set up with the same name. Nevertheless you should review them.

If you are familiar with SEC installation and the various file system and registry locations it probably takes less time to get SEC on the server up and running (including client communication) than it took for writing this post :smileywink: - but it isn't just install/restore/run.

Does this answer your question?

Christian

I always take the knowledge of the architecture as granted.

I used to have some vague ideas - most of which were in fact right, but I just wasn't confident. Your explanation made things quite a bit clearer.

So I've read the migration guide and I think I can work with it. I'm still lacking some understanding, but this is only for _why_ certain things have to be or can't be done. But as long as I know _how_ to do it, that doesn't really matter.

As soon as I find the time, I'll try it in a test scenario...

So thanks for the help and the good explanation!

Thomas

Hello Thomas,

don't mention it ! 

_why_ certain things have to be or can't be done

Feel free to ask (although I can't promise an answer - I'm far from being omniscient  :smileywink:) and if in doubt please ask before trying something on a life system (and if you fear your question could be considered silly by the general public you can always PM me).

Christian

Asking - or refraining from doing so - has nothing to do with me feeling silly or so, it's more a matter of time and priority. First, it's not always easy to get some thoughts from my mind to my fingertips in a way that's understandable for somebody else. Second, I don't really _need_ to know certain things as long as everything works. But since you're asking for it:

Chapter 7 describes copying certificate registry keys. This should be done using the registry editor, even though a DataBackupRestore dumps the very same key. This key then needs to be imported _before_ the installation of SEC. Finally, the restore involves three steps: Restore database, restore registry, restore Private Store. Restoring the registry includes the certificate registry key imported before the installation. Furthermore, there are quite a few things that need to be done between those three steps - most of which I think could be automated.

Why does DataBackupRestore not inlcude the table_router.txt and the envelopes, why isn't the SQL-statement automated and why can't everything be restored in one step?

:smileyhappy:

most of which I think could be automated. ... copying certificate registry keys

The problem with automation is to take all possible combinations into account. DataBackupRestore is a recently added tool which combines several actions which previously had to be done manually. Its description tells you where it will work and where not. The certificate keys pose a chicken-and-egg problem: DataBackupRestore is part of the install but the keys have to be imported before that. 

In principle the procedure could be made smart enough to make the necessary edits - but then, it has to be watertight (note that the worst case would be that it seems to have worked and you notice problems only after several days) and there might not be enough demand to justify the development effort. Not every migration satisfies all assumptions, and of those which do only some are a restore scenario (you might use the opportunity to change some settings, clean up or prune the database). I'd say if there is enough interest (and feedback) there will be further development.

Christian   

I just found http://www.sophos.com/en-us/medialibrary/PDFs/migration/sec_51_mgeng.pdf and glanced over it quickly in the hope that things might just become easier... Oh well...

For now I have only one question:

Right at the beginning of the document it says that

Name (and IP address) must differ from the old identity but domain must be the same.

I can only hope the author assumed that both servers will at some time be in the same network, because apart from that I can't think of any other reasons for not being able to use the same identity. Did I miss something?

What disappoints me a bit is that Backup/Recovery doesn't seem to be an issue at all. The second assumption in the migration guide is that the old system is up and running, which could be considered quite cynical for a document that's supposed to help me out after a system crash. (Okok, I know that I'm supposed to read that document before the crash occurs... ;-))

In my dreams there is another document called "Backup/Restore guide", which assumes to have an up and running system plus a backup share at one time and a backup share plus a new system (most likely with the same identity) at another time.