Installing a SCCM DP/MP/SUP in an untrusted domain

Stephane FaubertSCCM6 Comments

There may come a time in your SCCM administration days where some special needs may arise. I had such a case recently. Long story short, in our company, we have a windows domain where no trusts exist with our primary domain where SCCM resides. The problem with that is since there is no visibility in between the two domains, how do you get the servers or workstations managed?

  • Default settings?
    • Such as a default Windows Update setup. Nah, I like to have some degree of control over who does what and when.
  • Install a standalone WSUS server?
    • Yes, this is a viable option where you can set and forget it. But it probably doesn’t fit with your SCCM setup.
  • Install a completely separate SCCM infrastructure?
    • Sure this works. But… Do you like doubling all your work? I surely don’t.
  • Install a DP in that zone?
    • This does indeed work. But… If you want to don’t want agents poking back to your internal primary site, you will need to add components to this. Such as? A Management Point. What if it is a zone with no internet access? How do you get your patches? Install a Software Update Point as a downstream server to your internal WSUS.

Requirements for a DP/MP/SUP in an untrusted domain

The first step, you will need to go over the supported configurations for Configuration Manager. Assuming that you are going for a regular setup such as a Windows 2012/2016 server, there is one thing you need to make sure you have.

All System Center 2012 Configuration Manager site systems must be members of a supported Active Directory domain. This requirement includes site systems that support Internet-based client management in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).

So, if you are planning any SCCM role type, you will need a functioning Active Directory in that zone. If not, make sure you have that before coming back here.

Next, let’s look at the required firewall ports we need. You will most likely need to have these opened by your firewall administrators. Microsoft has done quite a good job in documenting pretty much all firewall ports that are required for SCCM to work. However, since you are here, I’m guessing you are looking for the TL;DR version.

I am assuming here you are using the default ports.

Management Point <-> Site Server

These ports are required for your new management point to “talk” with your primary site.

DescriptionUDPTCP
RPC Endpoint Mapper135
RPCDynamic ports
SMB445

Management Point -> SQL Server

Your management point will also need to be able to communicate with your SQL database. This could either be the same IP as your primary site if both are residing on the same windows server, or the IP of the dedicated SQL server.

DescriptionUDPTCP
SQL over TCP1433

Notice that I didn’t include Client -> Management Point. This is because the clients are within the same domain as the new MP you are installing so unless your windows firewall is enabled on the new MP, it won’t be needed.

Site Server -> Distribution Point

This one is essentially used to distribute packages to your DP, amongst other things.

DescriptionUDPTCP
SMB445
RPC Endpoint Mapper135135
RPCDynamic ports

Site Server <-> Software Update Point

DescriptionUDPTCP
SMB445
HTTP80 or 8530
HTTPS443 or 8531

This one is for your site server to communicate with your SUP. Note that you will need either HTTP or HTTPS. You won’t need both. Not sure? One very easy way to find out is by opening the WUAHandler log on any one of your SCCM clients. Look for the keyword:”Existing WUA Managed server”

Installing SCCM DP MP SUP Untrusted Domain

As you can see, I’m currently set in HTTP. So I’ll keep going that way.

Software Update Point <-> Upstream WSUS Server

DescriptionUDPTCP
HTTP80 or 8530
HTTPS443 or 8531

You will also need to have some sort of name resolution to your primary site and SQL server. This could either be via DNS with TCP/UDP 53 opened, via host file, etc.

So that’s pretty much it for firewall requirements.

Next? Actual permissions. Obviously, in a typical setup, your primary site server is usually a local windows administrator of the server itself where it’s installed. However, in this case, the primary site server can’t be a local administrator of the new management point since there is no trust. Not a problem. Create a service account on the destination domain (which will essentially be a Network Access Account for that domain) and put it as a local administrator of your new MP.

What about SQL? Well, in my primary domain, we already have a NAA that does all that work. Let’s keep it. I’ll show you how to set it up when we do the installation.

One last piece of information as this one caused us quite a bit of a headache. If your domain has anything above the normal set of hardening rules, you could have a problem. Make sure that your NTLM settings are set up to allow authentication. The traffic will be initiated by your Primary Site -> New MP -> DC to authenticate. If you are denying NTLM traffic, you will most likely need to setup an exception to allow authentication for that new MP.

Preparing the Windows Server

Since this will be a DP and SUP, we will need to install WSUS and IIS on the server. Fire up your Powershell console. Head over to Requirements and Recommendations before installing SCCM 2012R2 in the Roles and features section.

Go ahead… I will wait! 😉

Ok, so that’s done. Now let’s install WSUS.

Installing SCCM DP MP SUP Untrusted Domain

  • Select WSUS Services and WID, click Next

Installing SCCM DP MP SUP Untrusted Domain

  • Check Store updates, and set your WSUS location

Installing SCCM DP MP SUP Untrusted Domain

  • Press Install

Now, as you probably know our external SUP will need to communicate with the upstream server. Let’s go ahead and set that up.

Launch your WSUS console which will most likely prompt you to complete the installation.

  • Press Run if prompted.

Installing SCCM DP MP SUP Untrusted Domain

  • Press Close when complete.

Installing SCCM DP MP SUP Untrusted Domain

  • When the WSUS Configuration Wizard starts, click Cancel

Installing SCCM DP MP SUP Untrusted Domain

  • Head over to Options and choose Update Source and Proxy Server

Installing SCCM DP MP SUP Untrusted Domain

  • Enter the Server Name of the Upstream server you will be using. Press Ok.

Installing SCCM DP MP SUP Untrusted Domain

Installation of the SCCM roles

As stated in the documentation, by default, communication between the site server and site systems is bi-directional. The site server initiates communication to configure the site system, and then most site systems connect back to the site server to send status information. Reporting service points and distribution points do not send status information. If you select Require the site server to initiate connections to this site system on the site system properties, after the site system is installed, it will not initiate communication to the site server. Instead, the site server initiates the connections and uses the Site System Installation Account for authentication to the site system server.

How do we implement this? Here’s how.

  • Start by browsing to Administration – Site Configuration – right click Servers and Site System Roles and choose Create Site System Server

Installing SCCM DP MP SUP Untrusted Domain

  • Next, enter the FQDN of your new MP (1). Enter the Site Code (2) and finally instead of using the Site Server Account to install, since this server is in our untrusted domain, give him the service account which is local administrator of the server (3)

Installing SCCM DP MP SUP Untrusted Domain

  • In the proxy tab, leave the options default, press Next

Installing SCCM DP MP SUP Untrusted Domain

  • On the System Role Selection, choose Distribution Point, Management Point, and Software Update Point

Installing SCCM DP MP SUP Untrusted Domain

  • On the Distribution point tab, check Install and configure IIS if required by Configuration Manager, press Next

Installing SCCM DP MP SUP Untrusted Domain

  • On the Drive Settings, set your values as per your environment. Press Next

Installing SCCM DP MP SUP Untrusted Domain

  • On the Pull Distribution Point tab, press Next

Installing SCCM DP MP SUP Untrusted Domain

  • On the PXE settings, we will just press Next since we won’t be doing any PXE in that environment

Installing SCCM DP MP SUP Untrusted Domain

  • On the Multicast tab, press Next

Installing SCCM DP MP SUP Untrusted Domain

  • On the Content Validation tab, set your schedule and press Next

Installing SCCM DP MP SUP Untrusted Domain

  • On the Boundary Groups tab, set your boundaries. Press Next

Installing SCCM DP MP SUP Untrusted Domain

  • On the Management Point tab, select HTTP. Press Next

Installing SCCM DP MP SUP Untrusted Domain

  • On the Management Point database, under connection account, press Set and choose your internal NAA account. Press Next

Installing SCCM DP MP SUP Untrusted Domain

  • On the Software Update Point tab, if you are setting up your server on 2012 or 2016, set your option to 8530 or 8531 and press Next.

Installing SCCM DP MP SUP Untrusted Domain

  • Finally, on the Proxy and Account settings, press Next

Installing SCCM DP MP SUP Untrusted Domain

  • Complete the wizard

And if all went well, you should now have a completely functional SCCM infrastructure in your no-trust active directory. As you may have noticed, the SCCM installation portion of this guide stays mostly the same. What changes the most is the requirement part that is tweaked a bit and the accounts we used.

Have you setup any similar infrastructure? If so, feel free to share how you went about to do it.

VERIFICATION

You can verify the installation in the following logs:

ConfigMgrInstallationPath\Logs\mpMSI.log – Records details of about the management point installation

ConfigMgrInstallationPath\Logs\MPSetup.log.log – Records the management point installation wrapper process

ConfigMgrSetup\Logs\SUPSetup.log -Provides information about the software update point installation. When the software update point installation completes, Installation was successful is written to this log file

ConfigMgrSetup\Logs\WCM.log – Provides information about the software update point configuration and connecting to the WSUS server for subscribed update categories, classifications, and languages

ConfigMgrSetup\Logs\WSUSCtrl.log – Provides information about the configuration, database connectivity, and health of the WSUS server for the site

ConfigMgrSetup\Logs\Wsyncmgr.log – Provides information about the software updates synchronization process

 

Installing a SCCM DP/MP/SUP in an untrusted domain
5 - 1 vote

IT Enthusiast, SCCM administrator for a few years now. Former packager. Certification obtained in 2013. I just love playing with SCCM and push what I can do with it to the limit.

6 Comments on “Installing a SCCM DP/MP/SUP in an untrusted domain”

  1. Any guidance about issuing this machine MP and DP certs + root trust from a CA, for use with clients in the “trusted” domain?

  2. I have to agree with jason. I have an MP/sup/dp (it’s actually a secondary) on the edge of a untrusted network with no trust. The firewall is open for the clients to talk to the above machine and it works great with just the proper install string (1706) and dns forwarders. Eventually all the untrusted machines will join our domain, but this solution works until then.

  3. Also, this does not go over DNS functioning between the domains either. It seems to assume you can resolve hosts in the untrusted domain. This would not always be the case, especially if the domains are firewalled

    1. It might not be super detailed, but:”You will also need to have some sort of name resolution to your primary site and SQL server. This could either be via DNS with TCP/UDP 53 opened, via host file, etc.”

  4. The problem description here does not fit the solution. The solution presented addresses systems in a segregated network. The fact that these systems are in an untrusted forest is completely irrelevant to the solution that you are proposing because ConfigMgr simply doesn’t care if the systems are in a trusted forest/domain or not.

    1. Hey Jason! I’m glad you decided to chime in since you were a great help while I was troubleshooting this same issue (remember on /r/sccm?) Anyway. A few hours of troubleshooting with Microsoft later, turns out that our problem was the Denying of NTLM trafic.

      That is what basically prompted this post. Since I had never found a post documenting this per se, or even mentioning it. I thought it could be a good idea to leave a trace should it ever be needed eventually.

      However, ConfigMgr might not care if the systems are in a trusted AD or not, but, being in an untrusted domain does still bring it’s share of challenges. It’s not as simple as when you are installing CM in your “core” domain. There’s quite a few things that you need to keep in mind or not forget. That’s what this is about. In this precise case, I know that there are easier implementations that could have been done, but this was the chosen path for us. But in the end you are right, maybe I could tweak my introduction to the issue a bit! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *