Multiple ePO Server architecture

[Former Member]

Hi all, I have a relatively complex solution that I need to architect by end of next week. This is for an industrial network, the endpoints that require the definition updates from ePO have no internet connection and are connected to a domainless network. I don't own or control this network, however I need to deliver updates through my controlled network to them as a service.

The way following architecture is roughly what I believe is necessary to route through all the firewalls;

• Enterprise ePO server (top level upstream server with access to internet and on enterprise domain)
• Industrial DMZ ePO server (downstream server from Enterprise, Upstream to Production with no access to internet and on separate industrial domain with no trust to enterprise)
• Industrial Production ePO server (downstream server from Industrial DMZ ePO server, upstream to domainless industrial network)
• Domainless industrial network ePO server sits on network vlan with clients that require updates from ePO

For the above infrastructure I'll need to configure the following:

• Open firewall ports to downstream server (could use some clarification on what would be needed here too)
• Open firewall ports from Industrial DMZ to Production network ePO server
• Open firewall ports from Industrial Production network to Domainless industrial network ePO server

The questions I have are as follows:

• Can this be achieved without configuring domain authentication of any kind? I have no control over the enterprise domain (although I can get assistance from their team), I do have control over the industrial domain, but then the final ePO server and endpoints will be on a domainless network.
• Does the ePO server on the domainless network need to be connected to the upstream ePO servers, or could the definitions and updates be delivered via an SMB file transfer from the last downstream server?
• Is there any way of simplifying this?

Hope this is clear, it's been a tricky one to navigate so far. Thanks all!

[JoeBidgood]

It sounds like the problem is getting content into the final ePO server so that it can then be distributed to the clients - is that right?
If so then it should be possible. You can use a distributed repository owned by one ePO server as the source site for another, which I believe should do what you require. You can configure the distributed repository to not require authentication should that be required, for example HTTP.

KB82581 describes this process - hopefully this helps.

Regards -

Joe

[Former Member]

Thanks for the reply Joe,

Yes that's correct the only goal here is to get update content and definitions down to the final ePO server to distribute to clients.

So would that mean the top level ePO server with connection to the internet is the "Master Repository", and the 3 lower ePO servers are configured as distributed repsoitories? So taking the example from the KB:

ePO-A Enterprise - Master Repository - pulls updates from McAfee servers
ePO-B DMZ - Distributed Repository - pulls updates from ePO-B
ePO-C Production - Distributed Repository - pulls updates from ePO-C
ePO-D Offdomain - Distributed Repository - pulls updates from ePO-D and pushes updates to endpoint clients

Is the above example correct, and is the direction of dataflow correct? Also, what ports are required for replicating the content between distributed repositories - we operate by a least privilege concept for our secure environment, so the less ports we have open the better (particularly between Enterprise and DMZ).

Thanks again for your help!

Edit: Re-Reading step 3, it says the distributed repository must be in a UNC path accessible by the server below, does this mean port 445 for SMB required with authentication? 

[JoeBidgood]

Not quite - each ePO server has its own master repository, and pulls content from a source site. However you do not want to use one ePO server's actual master repository as the source site for another, because you don't want to pull one server's agent packages into another.
So for each ePO server you would create a distributed repository, and configure it to only contain the content you want - in this case I imagine DATs and so on - and then use this as the source site for the next ePO server in line. You're essentially building a chain of source sites, something like this:

ePO-A Enterprise -  pulls updates from McAfee servers, replicates content to local distributed repo A
ePO-B DMZ - pulls updates from distributed repository A,  replicates content to local distributed repo B
ePO-C Production - pulls updates from distributed repository B,  replicates content to local distributed repo C
ePO-D Offdomain - pulls updates from distributed repository C,  provides content to endpoint clients

As far as which ports are open, that will depend on the type of distributed repository you choose. The KB uses UNC as an example but you don't have to use that - in your environment an HTTP repo would probably be easier as it requires no authentication.

Regards -

Joe

[Former Member]

Hi Joe,

Quick question - taking your example, if I have a staging PC in between ePO-D and ePO-C, will it work?

i.e. ePO-C has local repository, staging server replicates the repository files from ePO-C to a local folder which ePO-D can access. Will this work? We have network config that would support this already. Or instead would I need ePO-C's 'local' repository to reside on the staging server so ePO-D pulls from the repository folder directly? If this is the case we'll need to make some changes in network design.

Thanks

[cdinet]

Epo C can set up a distributed repository on any location that it can reach and that epo d can reach.  Epo d would then pull from that distributed repository location.  Keep in mind that you will need to export epo c public repository keys and import them to server d for it to be able to decrypt them.

In other words, if there is a server that is accessible to both servers, that one can be used as the distributed repo for this purpose.

[Former Member]

Hello, 

Sorry I guess I wasn't particularly clear, at the moment there isn't a folder that both servers can access concurrently, however I can replicate the distributed repository via FTP to a folder on a separate server that the off-domain server can access - the off-domain server can't connect directly to the distributed repository folder, just a replication of it - does this matter?

Thanks for all the help so far!

[cdinet]

As long as the off-domain server can access the files, it shouldn't matter how it gets populated, as long as it is in the correct structure that the repository is.