The question of how to manage systems in a multi-forest Active Directory (AD) infrastructure using System Center Configuration Manager (ConfigMgr) comes up quite often in online forums and at customers; this post will summarize and detail the answers I’ve given (over and over again).
The Really Short Answer
It doesn’t matter, and ConfigMgr doesn’t care.
The Short Answer
For client management activities, ConfigMgr neither relies on or requires AD in any way, so multiple domains or forests with or without trusts are irrelevant. If you intend to target users in untrusted domains or forests, then you will need to have a site system with the management point role installed in that untrusted domain or forest to perform authentication and authorization.
The Detailed Answer
See the complete post on the 1E blog site: ConfigMgr/SCCM Client Management, Domains, Forests, and Trusts (Oh My).
Great post. Succinct and concise. I’m curious though with regard to pki integrated sites. Is it as simple as just adding a new issuing and policy to deploy the certs?
Thank You Sam. PKI throws some curve balls into this if you are talking about cross-forst certificate deployment. There are ways of doing PKI cross forest with a Microsoft CA including the following:
– Cross-forest Certificate Enrollment: https://technet.microsoft.com/en-us/library/ff955845(v=ws.10).aspx
– Certificate Enrollment Web Service: https://technet.microsoft.com/en-us/library/dd759209(v=ws.11).aspx
– NDES/SCEP: https://technet.microsoft.com/en-us/library/hh831498(v=ws.11).aspx
Hi Jason, thanks for the post and information. I’m facing a similar situation with a new customer:
3 untrusted domains: PRD, ACC and TST
All SCCM related servers will be installed PRD.
Patching and management of ACC and TST will need to be done by ConfigMgr server in PRD.
Would it be enough to:
* Setup new PKI hierarchy in ACC and TST
* Specify the Root CA of these PKI setups in the “Trusted Root Certification Authorities” under Site Configuration in ConfigMgr
* Add the Root CA of the ConfigMgr servers to “Trusted Root Certificates” on the clients in ACC and TST
Why set up a new PKI hierarchy at all? Why not just create subordinate CAs in ACC and TST? If your PKI was set up properly, then your root CA is offline and not integrated with AD.
Doing what you’ve outlined above will work, although it’s missing deploying the root CAs cert from each CA to the other domains placing it in the trusted root store. Ultimately, what you’re asking about here is more PKI specific than it is ConfigMgr specific and I would never, in general, recommend going this route as you’re just adding complexity.
One question here though: is the ConfigMgr instance configured to use HTTPS client communication today and/or is there some requirement to do so?
Hi there, Does this also apply to the management of bitlocker which was recently introduced? MBAM required a trust to work so wondering if it’s the same with respect to bitlocker and SCCM.
Thanks
Pretty much anything that applied to MBAM still applies to BitLocker Management in ConfigMgr as the functionality was mostly just moved into ConfigMgr. It’s nearly the same client agent and listeners so I would expect a trust is required 🙁
hi Jason, the link to the detailed article is not valid anymore. can you please post the updated link?
thanks
Looks like 1E updated the address for the post; you can now find it at https://www.1e.com/news-insights/blogs/mvp-questions-answered/. I’ve updated the link in post as well.