Jason Sandys MVP coretech sccm

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

Just knowing the really short and short answers don't help much if you are designing a ConfigMgr implementation in a multi-forest or domain environment so here are some additional details.
[note]Niel Peterson posted a four part series titled Cross Forest Support in ConfigMgr 2012 about five years ago. His series is still relevant and [almost completely] accurate for ConfigMgr Current Branch (CB) so reading it will help you learn how to set up ConfigMgr for common scenarios. His blog post series jumps straight into the scenarios without always explaining the whys though leading many to draw the conclusion that they need to do "something". It also doesn’t focus solely on domains and forests so that’s where this post comes in although I won’t in general cover the details he did there. [/note]

Firewalls and Network Segregation

First, don't confuse multiple forests and domains with network segregation, isolation, or traffic filtering. They are independent constructs. Your organization may have separated domain and forest members from each other by a firewall (or other traffic filtering mechanism) but this is technically unrelated to their forest and domain membership and thus must be accounted for separately and distinctly. For firewalls and segregated networks, you need to open ports and design for network traffic flow which is not the topic of this post.

WAN Separation

Similar to firewalls and network segregation is WAN separation of managed clients and the answer is the same here: they are technically independent and must be planned for separately and distinctly. For WAN separated clients, you typically place distribution points or secondary sites across the WAN link at the remote locations or use a peer-to-peer content solution such as 1E’s Nomad. This is also not the topic of this post, however.

AD Domains and Forests

For AD domains and forests, you need to design for what domains and forests do — hint, it's not network traffic related in any way. Domains and forests are about identity and authentication.
That doesn’t mean that ConfigMgr doesn’t authenticate activity or identity (it most certainly does); it just means that it [mostly] doesn’t use AD for authentication. So, the question becomes “If ConfigMgr doesn’t use the identity or authentication services of AD for client management, what does it use?”
And the answer is … certificates.
When using HTTPS client communication in ConfigMgr, a [unique] client authentication certificate issued from a trusted PKI is required for each managed system. As the type name implies, these certificates are used for authentication; identity is part of authentication, and the certificate serves this purpose as well.
But what about ConfigMgr sites that are not using HTTPS client communication? Well, it’s the same answer. The certificates are slightly different though: they are still client authentication certificates, but instead of being issued from a trusted PKI, they are self-signed (and self-generated). If you open certificates MMC snap-in for the Computer account of any ConfigMgr managed system not using HTTPS client communication, you will see an SMS certificate store. This store contains two certificates as shown in the figure below that the local ConfigMgr client agent uses. (SMS here of course, as always, means Super-wicked-awesome Management Server).

As part of the client registration process, the client sends information about its certificate(s) (PKI or self-signed) to the site. The client then uses these certificates to authenticate with the site roles and identify itself to the site so no other authentication mechanism is needed. Because certificate usage in no way depends upon AD domains or forests, neither does this authentication process by the ConfigMgr client agent.
[note]PKI certificate issuance, trust, and revocation checking may be integrated with AD and must be planned separately from ConfigMgr. Get a PKI smart resource involved ASAP if you need to design a PKI in a multi-forest environment regardless of forest and domain trusts. Also, certificate trust and domain trusts are two completely different concepts even though they both use the word “trust”.[/note]

Active Directory Discoveries

AD discovery is not required to manage client systems. Once the client agent is installed on a system, it will send a heartbeat discovery. Of course, having said that, it’s still nice to discover systems that don’t have the client agent and to discover other AD specific attributes.
Because all Active Directory discovery methods in ConfigMgr are performed by the site server the only thing to configure here is the proper path to discover in the additional domains as well as a valid account in those domains that have permissions to access that path.
See Configure discovery methods for System Center Configuration Manager for details.

Client Agent Push

Client push is also not required but may be an effective way to deploy the client agent to your systems. Keep in mind that there are multiple other effective ways to deploy the client though.
Systems in an additional domain or forest in no way change the requirements for client push though. The site server must still perform the following regardless of AD domain:

  1. Resolve the DNS name of the systems to an IP Address.
  2. Access the admin$ share and connect to WMI on the systems.

The second item above requires a user name and password which you configure in the Client Push Installation settings of the site. For systems in those additional domains, you simply add additional valid credentials for those domains.
See How to deploy clients to Windows computers in System Center Configuration Manager for details.
[note]DNS domains are also often confused with AD. AD heavily relies on DNS, but so does all network operations and activity. Just because DNS is integrated with AD doesn’t mean that DNS and AD are one in the same. Specifically, an AD trust has nothing to do with DNS, so you still need to ensure that DNS name resolution works for all managed systems regardless of their domain membership or the existence of AD trusts.[/note]

Client Service Location

ConfigMgr clients and the client installation process (ccmsetup.exe specifically) can use AD to locate management points; this requires that the site publishes the information to AD. Like the previous two items, the site server is responsible for this action. Thus, all you need is to configure a valid AD account for any alternate forests where you want ConfigMgr to publish its information. You must also extend the AD schema in that forest and create a System Management container in those forests.
Also like the previous two items though, this is not required, and there are alternate ways to provide service location.
One additional point here is that service location challenges created by network separation or segregation can be addressed partly if multiple domains and forests are involved. This is because clients generally prefer the use of site roles within their own AD domain or forest. However, in this case, the infrastructure design is driven by the network separation or segregation and not AD. These are still two distinct design motivations and it's important to realize that.
See Prepare Active Directory for site publishing for details.

Other Caveats

There are always other nuances, exceptions, and idiosyncrasies. For this topic, I already mentioned one in the Short Answer section: user targeted deployments. Users are of course a principal object in AD so it should be clear that to use users for targeting, you also need to involve AD to authenticate the user. If the targeted user(s) are in a trusted forest, then there is nothing additional to do as that’s the whole point of having a trust. If the targeted user(s) are in an untrusted forest, then you must create a site system with the management point role in that untrusted forest as a member of one of its domains. This enables the management point to authenticate the users against the forest where they are members as well as expand user groups and discover user group memberships so that user policy can be delivered to the logged in user.
Operating system deployment (OSD) and the Run program from distribution point deployment option for a package deployment introduce another caveat. Both of these require the use of a Network Access Account to address this caveat.
For OSD, part of all task sequence run in WinPE. A system running WinPE is part of an undefined workgroup which is an untrusted forest. While a system running a task sequence is in WinPE, it has no verifiable identity on the network and thus cannot authenticate when accessing necessary resources. It instead uses the network access account.
[note]A generic client authentication certificate is available to the client, it is not used for authentication or identity purposes because it is, as noted, generic.  This certificate is configured during boot media creation or on the PXE configuration of the distribution point (DP).[/note]
For package deployments configured to run directly from the DP, the client uses SMB to access a traditional Windows file share. This requires a username and password and cannot be done using a certificate. Clients in a trusted domain or forest use their AD computer account for this. Clients in untrusted domains and forests can’t successfully use their AD computer account for this and instead fall back to using a network access account.
[note]Hopefully you’ve disabled SMBv1 by now.[/note]

Conclusion

The biggest item I stress when providing the above answer is not to confuse the design requirements, constraints, and capabilities of these separate constraints. Specifically, don’t confuse AD with network restrictions or bandwidth constraints – these are all independent and drive different solutions and designs. Also, don’t confuse other requirements that have similar terms like DNS and PKI with AD even if they are dependent or integrated.
To properly design a ConfigMgr site, you need to know how to address each of these independently. Keep in mind that a single solution may ultimately address multiple of these challenges, but that doesn’t imply that these challenges themselves are the same. You also certainly may need to add additional infrastructure to overcome network challenges, but those are separate design decisions.
For managing clients in multiple Active Directory domains and forests using ConfigMgr, the only time you need to add any infrastructure is when using user targeted deployments. In that case, you simply need a management point in that forest.

This post was pretty awesome, right? What if we told you that Mr. Sandys will be answering questions and chatting LIVE during the 1E MVP Twitter Party on August 7th? You'd be excited, right? Well now's your chance to RSVP and chat with him and 4 other Microsoft MVPs! 1E is hosting a LIVE Twitter Party with Jason Sandys, Johan Arwidmark, Greg Ramsey, Kent Agerlund, and Brian Mason on August 7th at 3PM EST. Click on the button below to add your Twitter handle. (By adding your handle, you'll be eligible for prizes and we'll be able to tweet with you during the party). Follow along with hashtag #1EMVPchat!