Can a single enterprise console support a multi-forest environment?

Hello Oaktree111,

depends on what you expect when saying support. Multiple forests are similar to a non-AD environment and SEC doesn't need AD to manage its clients.

Christian

Ok, thanks Christian.

What I meant by "Support" was that Forest (A) has the Enterprise Console and some servers that have Sophos AV installed. Forest (B) has no Enterprise Console but has some clients and servers which have Sophos AV installed as well but report back to the Enterprise Console in Forest (A).

I know that McAfee for example uses a proprietary protocol "Spipe" which works like HTTP, so no domain information is used when the McAfee Agent downloads new policies from the EPO server. What is Sophos's equivalent protocol?

Sophos' Remote Management System (RMS) uses ports 8192-8194. Ideally it's a two-way connection (client to server's 819x and server to client's 819x). Clients locate the server by either NetBIOS name, FQDN, IPv4 or IPv6. Server tries to connect back to the client's IP. If this is not possible the client-server connection is used for both directions (in which case a policy push is not possible). You can also set up message relays, so for example only the relay at FOrest(B) will talk to the server and all clients in Forest(B) will go through the relay.

Christian

Hi,

The communicaiton (RMS) will not care about the environment as long as the routing is available.  if the SEC server has a static IP, then the clients will attempt to route to it using IP only.

The only problem you may have is deployment from SEC.  When using the wizard, when it prompts for an account, this account needs to be able to be impersonated by the Sophos Management Service, so in effect it needs to be able to logon to the management server.  When running in this context it will then attempt to connect to the remote machines to create a scheduled task to start the install.  

So in a single domain environment, e.g. Test.local, you would specify:

test\administrator

If you are deploying to a machine in a different domain, e.g. Test2.local, the account you specify in the wizard needs to still be able to logon to the management service machine.  E.g. test2\administrator.  I know sometimes, especially if SEC is installed on a DC you may need to permit accounts from other domains to be able to logon to the machine.

If the 2 domains have an admin account with the same passwords, just specifying the account name is worth a try.  E.g. Administrator

The other aspect to consider is the machine name in SEC when you deploy,  It is worth ensuring that the DNS settings under the adapter settings "Append these DNS suffixes (in order)" are correct for all the domains on the managment server, such that \\comp1\ would resolve to the right machine.  

Of course you can also just bootstrap the machines if deployment from SEC isn't working quite right:

http://www.sophos.com/support/knowledgebase/article/12570.html

has the switches you need to parse to the bootrapper to perform installs.

As a tip, if you protect a machine from SEC as a test and monitor the scheduled tasks, you should see the Sophos install task,  If you look at the properties of that you'll see the switches passed and it will have the obfuscation already done for you.

http://www.sophos.com/support/knowledgebase/article/13090.html is a basic example of deploying with AD startup scripts.

I hope this helps.

Regards,

Jak