locked
Clients in untrusted forest which can't directly communicate RRS feed

  • Question

  • We have an existing management infrastructure. We are deploying a new isolated  tenant in our environment which will have servers in the data centre and laptops in remote rooms. I can control communication through the firewall well but I'm only allowed hops from the data center servers through to the management platform, not direct from the clients.

    So.... any ideas if I can put an MP type server into an untrusted forest and if so what needs to be open between it and the primary site server(s)? Presumeably it would need SQL / SMB access which isn't going to be overly well received by our accreditors to pass through.

    What I need is a SCOM gateway type setup where it collects everything in one central point within the untrusted domain and then forwards it in a single connection, but just for SCCM.

    All that we're planning on using SCCM for is patching and Endpoint Protection.

    Thanks, Tom

    Wednesday, December 2, 2015 8:50 AM

Answers

  • For what you've described, a site system in that forest hosting DP, MP, and SUPs roles is sufficient (to be very clear though, not a secondary site). Clients will prefer the MP and SUP in their own forest and will use the DP based upon boundary groups (as of R2 SP1/SP2 clients can also locate MPs based on boundary groups also but that shouldn't really be needed here because of the default affinity behavior).

    As for ports, they are well documented on TechNet: https://technet.microsoft.com/en-us/library/hh427328.aspx

    Why would your accreditors care about traffic between two specific systems? This is effectively no different than what a gateway in OpsMgr is doing.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Proposed as answer by Frank Dong Monday, December 28, 2015 6:09 AM
    • Marked as answer by Frank Dong Thursday, January 7, 2016 4:17 AM
    Wednesday, December 2, 2015 12:51 PM

All replies

  • For what you've described, a site system in that forest hosting DP, MP, and SUPs roles is sufficient (to be very clear though, not a secondary site). Clients will prefer the MP and SUP in their own forest and will use the DP based upon boundary groups (as of R2 SP1/SP2 clients can also locate MPs based on boundary groups also but that shouldn't really be needed here because of the default affinity behavior).

    As for ports, they are well documented on TechNet: https://technet.microsoft.com/en-us/library/hh427328.aspx

    Why would your accreditors care about traffic between two specific systems? This is effectively no different than what a gateway in OpsMgr is doing.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Proposed as answer by Frank Dong Monday, December 28, 2015 6:09 AM
    • Marked as answer by Frank Dong Thursday, January 7, 2016 4:17 AM
    Wednesday, December 2, 2015 12:51 PM
  • Thanks Jason,

    Unfortunately I can't go into why the two forests need isolating, but I do need a single point within the new forest which can act as a single point of contact for all SCCM clients and therefore I can control communications back to the core SCCM from a single point.

    So if I have ExistingForest which has SCCM installed, and then NewForest, the DP / MP / SUP would sit on the NewForest subnet/VLAN, but be joined to the ExistingForest Domain? Or on the NewForest domain and then just connect back to the ExistingForest SQL where the CM DB is using a stored credential? And all files would be distributed via SMB to the DP / MP / SUP in the NewForest?

    Thanks,

    Tom

    Monday, December 7, 2015 2:40 PM
  • The site system should be a member of the forest where it is managing clients for best results -- this will require a connection account and an installation account. Using a normal DP, yes SMB is used however it could be a PullDP in which case the content is pulled via HTTP. There are multiple additional ports required also but these only need to be opened between the site system and site server as described in the link I posted.

    As a side note, I wasn't questioning the forest isolation, I was questioning this statement: "Presumeably it would need SQL / SMB access which isn't going to be overly well received by our accreditors to pass through" as this is no different than have an OpsMgr gateway. Why does it matter how many or what ports are open between two specific systems? Traffic is traffic, a port is simply meta-data.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, December 8, 2015 2:47 PM
  • That's great. Really helpful - thank you Jason!

    With regards to the port lockdown, the SCOM gateway is self-sufficient and needs only a single port through to the SCOM management server to pass the data. This is easier for us to monitor and also doesn't natively allow much breach between two environments. By opening up an SMB route between two servers there's more chance that people could push / pull other files without much complication between the two servers which cannot be allowed to happen. So if I can get away with not allowing 445 then all the better!

    Thursday, December 10, 2015 9:10 AM
  • A pull DPs itself does not need SMB for daily operations (download from a DP is done via http(s)), but I *think* that you have to open SMB ports for the Installation of the the pull DP as the site server has to copy files to the server.

    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, December 10, 2015 9:32 AM
  • That's fine - temporarily opening it up for the purpose of install is no problem.

    So the pull DP - that can be used to function as the AV deployment / WSUS / Endpoint definition update provider for the machines in that forest? Do I need to implement a downstream WSUS instance alongside the pull DP or would that all be handled within SCCM?

    Thursday, December 10, 2015 11:19 AM
  • Its a mistake to think that SMB file transfers can only happen over port 445. A port is simply meta-data and in no way controls data. Application security is an application layer function. For SMB, that means share and NTFS permissions.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, December 10, 2015 3:29 PM
  • You need more than just a DP for a segregated network segment though so even if you use a PullDP, that is only part of the problem. The link I posted above has all of the details. From memory, you will need 445, 135, 1433, and 8530 to support the three roles on the remote site system.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, December 10, 2015 3:30 PM