1 Reply Latest reply on Oct 27, 2010 1:26 PM by jstanley

    Agent Handler in the DMZ: Front-End Solutions

      We are in the process of deploying an Agent Handler in our DMZ so that road warriors can connect to our ePO server for updates and policy pushes. However, the current architecture of the AH DMZ solution does not meet our three-tier (web,app,database) requirement for public-facing resources. Basically, we need to put a "web" layer in front of our AH. We were thinking of using some kind of reverse proxy setup with another Apache server or maybe even using Tomcat/mod_jk, and I was wondering if anyone else has a similar setup that has worked for them. In a nutshell, it would look something like this: ReverseProxy -> FW -> AH -> FW -> ePO. Has anyone successfully deployed an AH in the DMZ with this setup? Thanks in advance for any replies.

        • 1. Re: Agent Handler in the DMZ: Front-End Solutions

          ePO is a three tiered application. It is not exactly intuitive but the agent handler in the DMZ would actually be the application tier (as it has no UI and handles detailed processing/logic) while the ePO console itself is the web tier and the SQL database is the data tier.


          Now perhaps we are working on a different definition of exactly what qualifies as a 3 tiered application. As a reference this wiki page has the definition I am familiar with:



          So if you work off of that definition ePO is compliant with the tier3 model as the agent handler is part of the application layer which can work directly with the database.  This can be a bit confusing at first because apache is a web server therefore you may assume its part of the web tier but it is not. The agent handler could not be part of the web tier because it has no user interface.


          If security is a question then be sure to use MA 4.5 with the secure communications port which will encrypt the traffic between the client and the agent handler. Furthermore you can set up your SQL server to accept encrypted connections and then the traffic between the agent handler and the SQL server would also be encrypted. This model is secure because any connection attempt to the public facing agent handler would have to use the correct public encryption key or be rejected.


          I'm not sure if what you are proposing would work or not but I am sure that it would not be supported. Any problems you experience would have to be replicated without the proxy server in the mix for those issues to be supported.



          Message was edited by: Jeremy Stanley on 10/27/10 1:26:19 PM CDT