locked
ConfigMgr 2012 R2 and DMZ Questions RRS feed

  • Question

  • I am working with a client who's security team has been a challenge.  They do not want to open any of the RPC Dynamic Range ports needed for communication between certain roles on the Primary Site server and a server they want setup in one of their DMZ's. 

    They have a domain in the DMZ and all devices are a member of that domain.  We successfully setup a management point but can't publish since the ports from the primary site server to a DC in the DMZ are not open.  We placed a DNS service locator record in the DMZ and when we manually install the clients add the DNSSUFFIX and point to the MP in the DMZ.  The clients are reporting at this point.  However, they are not getting any software updates since the DP can't install and we don't allow failover to any other DP.

    The client has said that there has to be other solutions.  The solution we are using isn't best practice I know that.

    I guess there are three solutions here, correct?

    1.  Open DMZ site ports for clients to communicate only to ConfigMgr Server.  (Not secure)

    2.  Keep current design of MP/DP/SUP in DMZ?

    3.  Put a secondary site in DMZ?

    I have two questions about 2 and 3.  Why should we add the SUP?  Shouldn't the client talk to the Management Point and the management point sends the request to the SUP on the ConfigMgr?   So can't we ditch that extra SUP?  

    Also, even if we put a secondary site in the DMZ, we will still run into port issues since the client is refusing to open RPC Dynamic port ranges?


    Kristopher Turner | Not the brightest bulb but by far not the dimmest bulb.

    Saturday, August 2, 2014 2:18 PM

Answers

  • Yes 3 is out ConfigMgr wise.

    I would not call 1 insecure though. Open ports are not insecure, that's a myth perpetuated by those who don't know what a port is. Network security is about controlling the traffic and securing the endpoints. Ultimately, that may be a battle you won't win though because of political reasons and the perpetuation of myths in network security and the purpose of DMZs.

    Option 2 is what most/nearly all folks go with. If one port is open, you may as well open them all because security wise there is no true difference so any resistance here is ignorance. As long as the traffic is confined to a single endpoint, the port its using makes no difference and the level of security comes down to, as mentioned, the security posture and controls in place on that endpoint itself -- who cares that the traffic has a data field set to 80 or 443 or 1024 as long as the target is well controlled, "secured", and monitored.

    There ultimately aren't any other ways (besides 1 and 2) to accomplish this using only ConfigMgr proper. The ports required are well documented on TechNet so there's no magic to make these go away.

    Another architectural solution however is to use reverse proxy. This is a twist on choice 1 except that all client traffic passes through the reverse proxy instead to reach the internal site systems.


    Jason | http://blog.configmgrftw.com

    Saturday, August 2, 2014 3:07 PM

All replies

  • I might have answered my own question about the secondary site part.  So from the information below it looks like even with a secondary site they will still need ports open for the client to talk to the primary site.  So Number 3 is out.

    SECONDARY SITE: Now have SQL Express to replicate, control the upward flowing traffic, clients can be assigned a local management point (Note: All clients still have to register with a Primary first before they are assigned the Secondary MP, can be used as local SUP. Still has to be managed from primary.


    Kristopher Turner | Not the brightest bulb but by far not the dimmest bulb.

    Saturday, August 2, 2014 2:22 PM
  • So from what I have read.  1 and 3 are out, correct?  I have read that some clients have gone to a Primary site in their DMZ and a CAS to manage both?  This is a little over kill just to manage 50 or so servers in a DMZ?


    Kristopher Turner | Not the brightest bulb but by far not the dimmest bulb.

    Saturday, August 2, 2014 2:26 PM
  • Yes 3 is out ConfigMgr wise.

    I would not call 1 insecure though. Open ports are not insecure, that's a myth perpetuated by those who don't know what a port is. Network security is about controlling the traffic and securing the endpoints. Ultimately, that may be a battle you won't win though because of political reasons and the perpetuation of myths in network security and the purpose of DMZs.

    Option 2 is what most/nearly all folks go with. If one port is open, you may as well open them all because security wise there is no true difference so any resistance here is ignorance. As long as the traffic is confined to a single endpoint, the port its using makes no difference and the level of security comes down to, as mentioned, the security posture and controls in place on that endpoint itself -- who cares that the traffic has a data field set to 80 or 443 or 1024 as long as the target is well controlled, "secured", and monitored.

    There ultimately aren't any other ways (besides 1 and 2) to accomplish this using only ConfigMgr proper. The ports required are well documented on TechNet so there's no magic to make these go away.

    Another architectural solution however is to use reverse proxy. This is a twist on choice 1 except that all client traffic passes through the reverse proxy instead to reach the internal site systems.


    Jason | http://blog.configmgrftw.com

    Saturday, August 2, 2014 3:07 PM
  • Jason,

    So here is a question that is related. I am really trying to convince this client to implement Direct Access to help manage all their remote machines. Their environment includes a lot of clients that don't ever even VPN regularly.   I know IBCM is a solution but Direct Access gives them a whole lot more.

     Couldn't we also manage servers in the DMZ this way as well in theory?  They are all on a DMZ domain that if not trusted can be trusted with their internal domain. 

    Just wondering if you ever went that route?


    Kristopher Turner | Not the brightest bulb but by far not the dimmest bulb.

    Thursday, August 7, 2014 10:01 PM