locked
How to Install/manage SCCM Clients from 2 different AD forests with no trust RRS feed

  • Question

  • Hi Guys,

    We have 2 AD forests "A" and "B" with no trust between them.

    We have planned to setup primary server in Forest A and manage the computes from both the forest.

    Can we manage the clients in both forests , without having to install a PKI certificate on computers from forest B.

    can we accomplish this by configuring firewall exceptions for computers in forest B to communicate with forest A.

    Please advise.

    Wednesday, February 15, 2017 12:38 PM

Answers

  • Firewall exceptions have *nothing* to do with AD forests or trusts. You have two different items you need to address. Equating where forests with network traffic restrictions is invalid and simply an implementation detail.

    1. AD forests and trusts. ConfigMgr doesn't care about AD forests or trusts whatsoever for client management activities. So this really makes no difference and the requirements don't change in any way. The only additional configuration, which is actually quite standard because of OSD, is to have a network access account configured.

    2. Network traffic. Of course network traffic has to be allowed between the clients and the site systems hosting the relevant roles including MP, DP, SUP, and Application Catalog -- if you don't allow network traffic, how would the client communicate? Magic? As Torsten noted, you can either allow the clients to talk to your main MP, DP, and SUP (which happens to be in forest A but that's really irrelevant) or you can place a new site system hosting the MP, DP, SUP on the same side of the firewall as the clients (which happens to be forest B but once again this is irrelevant).


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

    Wednesday, February 15, 2017 2:22 PM

All replies

  • Hello

    Whether your site actually in native mode?  You don't have to use native mode for your clients in the remote forest to be managed by Configuration Manager.  But if the site is in native mode, then yes, these clients will need PKI client certificates and have installed the root CA certificate.  Also, the native mode site systems will need to be able to access the CRL for the client's subordinate CA.  Are these things in place?

    Also, your remote clients will need to contact a server locator point for site assignment


    Regards, Regin Ravi

    Wednesday, February 15, 2017 12:50 PM
  • No https/PKI needed. You can just place an additional MP/DP/SUP in the remote forest and manage the clients that way. (Or let them access your site systems - depending on the number of clients)

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

    Wednesday, February 15, 2017 1:06 PM
  • We have 90 computers in other forest.

    Can we allow computers in forest B to Access site systems on Forest A, using firewall exceptions.

    Wednesday, February 15, 2017 1:23 PM
  • Firewall exceptions have *nothing* to do with AD forests or trusts. You have two different items you need to address. Equating where forests with network traffic restrictions is invalid and simply an implementation detail.

    1. AD forests and trusts. ConfigMgr doesn't care about AD forests or trusts whatsoever for client management activities. So this really makes no difference and the requirements don't change in any way. The only additional configuration, which is actually quite standard because of OSD, is to have a network access account configured.

    2. Network traffic. Of course network traffic has to be allowed between the clients and the site systems hosting the relevant roles including MP, DP, SUP, and Application Catalog -- if you don't allow network traffic, how would the client communicate? Magic? As Torsten noted, you can either allow the clients to talk to your main MP, DP, and SUP (which happens to be in forest A but that's really irrelevant) or you can place a new site system hosting the MP, DP, SUP on the same side of the firewall as the clients (which happens to be forest B but once again this is irrelevant).


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

    Wednesday, February 15, 2017 2:22 PM