locked
HTTPS Communication with second MP and DP in untrusted domain RRS feed

  • Question

  • Hi,

    Trying to get some clarification on configuring MP and DP's on machine in untrusted domain.

    We have changed our base communication on MP's and DP's to HTTPS.

    Since we cant issue Config Manager Client certificates in the non trusted domain without configuring CEP/CES web service, we have decided to place a second DP/MP in the non trusted domain.

    When configuring settings for this second DP/MP we have to also choose https.

    my question is do the clients that communicate to this second DP/MP in the untrusted domain, have to have certificates installed as well or can they authenticate with Kerberos in the untrusted domain while the communication from the 2nd MP/DP back to the primary DP / MP is done with the certificates?

    thanks in advance.


    Thanks Lance

    Wednesday, March 5, 2014 4:48 PM

Answers

  • First note that there are alternate methods of installing certs besides just the web page -- the web page is certainly pretty easy, but there are other methods like using certutil and PowerShell to name a couple. You could even stand up another CA for that untrusted domain and issue certs from it to the clients in the domain.

    No, you do not have to enable additional MPs or DPs for HTTPS client communication -- this has nothing to do with your forest/domain structure in any way. 

    The clients that communicate with HTTPS enabled MP or DP must have a client auth cert, yes.

    ConfigMgr generally does not care about AD domains or trusts for client management -- that's why it uses certs and no it can't use kerberos in place of the certs, that would require domain membership.

    MPs/DPs don't communicate with each other.

    So, first question is why have you enabled HTTPS client communication?

    Next, I'm assuming the non-trusted domain is in its own forest, correct?


    Jason | http://blog.configmgrftw.com

    • Proposed as answer by Joyce L Thursday, March 6, 2014 5:32 AM
    • Marked as answer by Joyce L Tuesday, March 18, 2014 1:29 AM
    Wednesday, March 5, 2014 6:28 PM
  • OK on the Mac support, you don't really have a choice there then, but it's certainly not about security.

    I've addressed all of your other points though. There are many ways to issue certs besides the web site including standing up a new CA -- it could even be sub-CA.

    CA and cert trust ultimately has nothing to do with ConfigMgr. There's no reason to stand-up a second MP/DP either if you want to address the issue by getting certs to those other systems. The only reason you'd want to stand-up another DP/MP is if you didn't want to issue certs.


    Jason | http://blog.configmgrftw.com

    • Proposed as answer by Joyce L Thursday, March 6, 2014 5:32 AM
    • Marked as answer by Joyce L Tuesday, March 18, 2014 1:29 AM
    Thursday, March 6, 2014 2:29 AM

All replies

  • First note that there are alternate methods of installing certs besides just the web page -- the web page is certainly pretty easy, but there are other methods like using certutil and PowerShell to name a couple. You could even stand up another CA for that untrusted domain and issue certs from it to the clients in the domain.

    No, you do not have to enable additional MPs or DPs for HTTPS client communication -- this has nothing to do with your forest/domain structure in any way. 

    The clients that communicate with HTTPS enabled MP or DP must have a client auth cert, yes.

    ConfigMgr generally does not care about AD domains or trusts for client management -- that's why it uses certs and no it can't use kerberos in place of the certs, that would require domain membership.

    MPs/DPs don't communicate with each other.

    So, first question is why have you enabled HTTPS client communication?

    Next, I'm assuming the non-trusted domain is in its own forest, correct?


    Jason | http://blog.configmgrftw.com

    • Proposed as answer by Joyce L Thursday, March 6, 2014 5:32 AM
    • Marked as answer by Joyce L Tuesday, March 18, 2014 1:29 AM
    Wednesday, March 5, 2014 6:28 PM
  • First note that there are alternate methods of installing certs besides just the web page -- the web page is certainly pretty easy, but there are other methods like using certutil and PowerShell to name a couple. You could even stand up another CA for that untrusted domain and issue certs from it to the clients in the domain.

    No, you do not have to enable additional MPs or DPs for HTTPS client communication -- this has nothing to do with your forest/domain structure in any way. 

    The clients that communicate with HTTPS enabled MP or DP must have a client auth cert, yes.

    ConfigMgr generally does not care about AD domains or trusts for client management -- that's why it uses certs and no it can't use kerberos in place of the certs, that would require domain membership.

    MPs/DPs don't communicate with each other.

    So, first question is why have you enabled HTTPS client communication?

    Next, I'm assuming the non-trusted domain is in its own forest, correct?


    Jason | http://blog.configmgrftw.com

    Hi Jason,

    We had to enable https to allow MAC's to be included into config manager.

    Non trusted domain is a separate forest (DMZ set of machines).

    All of these machines were working (active clients) before we moved to HTTPS.

    We have machines in this domain (which does not have a CA) and they now need certificates to communicate to primary DP/MP unless we implement second MP/DP in this other domain.

    Our IT guys cant get to implementing CEP/CES to enroll machines from other domains/ workgroups.

    My thoughts were to use another DP/MP in the other domains and configure CM Client, CM Distribution Point and Web Server Certs based on template in CA in domain where Config Manager Server sits.

    THere doesnt seem to be much in the line of documentation for this approach (HTTPS and 2nd DP/MP in another domain)


    Thanks Lance

    Wednesday, March 5, 2014 10:12 PM
  • OK on the Mac support, you don't really have a choice there then, but it's certainly not about security.

    I've addressed all of your other points though. There are many ways to issue certs besides the web site including standing up a new CA -- it could even be sub-CA.

    CA and cert trust ultimately has nothing to do with ConfigMgr. There's no reason to stand-up a second MP/DP either if you want to address the issue by getting certs to those other systems. The only reason you'd want to stand-up another DP/MP is if you didn't want to issue certs.


    Jason | http://blog.configmgrftw.com

    • Proposed as answer by Joyce L Thursday, March 6, 2014 5:32 AM
    • Marked as answer by Joyce L Tuesday, March 18, 2014 1:29 AM
    Thursday, March 6, 2014 2:29 AM