For those looking for the ports you need open, this is what I use for a Windows 7 and Windows 2008 R2 DC.
LDAP TCP-in - 389
LDAP UDP in - 389
LDAP for Global Catalog TCP in - 3268
NetBIOS name Resolution UDP in - 138
SAM/LSA TCP in - 445
SAM/LSA UDP in - 445
Secure LDAP TCP in - 636
Secure LDAP for Global Catalog TCP in - 3269
W32Time NTP UDP in - 123
RPC - RPC Dynamic
RPC Endpoint Mapper
DNS - TCP and UDP 53
Kerberos V5 UDP in - 88
Netbios Datagram UDP in - 137
Now for the long story (note that the below solution is conceptual and hasn't been tested in a lab yet. This is just me getting things written down. I'll update more after we put this in place) -
When managing machines that are behind a firewall, you'll need to open ports on the firewall to get them joined to a domain. I have an interesting situation coming up next week where we need to manage machines that are in my customer's DMZ. In the current customer's environment, the machines in their DMZ are workgroup machines that aren't joined to a domain.
From an SCCM Perspective, we can manage workgroup machines. However we still need the ports opened through the firewall to manage these machines. In some cases, network administrators don't want all of their DMZ machines to go through the firewall that separates the DMZ from the internal network. We haven't determined if that's a route we want to take, but I personally feel that the more machines you have that can route through the firewall, the more you increase your attack vector.
My proposed solution would be to build up a secondary SCCM server in the DMZ that can only communicate through the firewall. All of the other machines in the DMZ would communicate through that server. That server doesn't even HAVE to be a secondary site, we could just build one box with an MP and DP (or whatever other site roles you need). The secondary will just allow us to throttle bandwidth if needed.
Below is a diagram that we use for Internet Based Client management, but for managing machines in the DMZ, the process would be the same.
So in our case, since there will be less than one hundred machines in the DMZ that need to be managed, we'll probably put all site roles on one box. We'll then need to open the ports I referenced above to allow the server to join the domain (note that all site system roles MUST be apart of a domain. They don't have to be apart of the same domain as the site server, but they do need to be part of a domain.). Once the server is joined to the domain, we'll need to open either port 80 or port 443 (for HTTPS) outbound to allow for the Software Update Point to communicate through the firewall. The diagram says HTTPS, but we can use HTTP since we'll be in a mixed mode environment. For native mode environments you'd need to utilize HTTPS. We'll also need SMB 445 outbound open to allow the site server to communicate with the other site roles in the perimeter network. We'll also need to create an inbound rule for SQL on port 1433 for the management point to communicate with the SQL DB.
Once we've done all that, we'll need to setup the appropriate rights to allow for site system installation on our server.
Client Configuration (thanks to Chris Stauffer for these tips)
In our scenario, we will be able to map to the MP's client share to install ccmsetup.exe. We can use the ccmsetup.exe /MP:servername /logon SMSSITECODE=XYZ. We'll likely also need to make some adjustments to the LMHosts and Hosts file.
Note that these tips should work if you have the firewall rules enabled for your clients to communicate through the firewall which would be port 80 or any custom port you've allowed SCCM to use.
LMHOSTS file:
Add the SMS information to a LMHOSTS file, which you can copy to each client. Use the following as a guide (WS03DC01 is the SMS server name):
192.168.1.61 ws03dc01 #PRE
192.168.1.61 "SMS_SLP \0x1A" #PRE
192.168.1.61 "SMS_MP \0x1A" #PRE
192.168.1.61 "SMS_NLB \0x1A" #PRE
# "12345678901234567890"
(note that there are 20 characters between the quote marks on each line, and the last line is just to help with spacing – it is not needed)
HOSTS file:
Add the SMS information to a HOSTS file, which you can copy to each client. Use the following as a guide (WS03DC01 is the SMS server name):
192.168.1.61 ws03dc01.domain.lcl ws03dc01
Summary
Build a server in the DMZ
Open the following inbound ports on the firewall to allow the server in DMZ to join the domain
LDAP TCP-in - 389
LDAP UDP in - 389
LDAP for Global Catalog TCP in - 3268
NetBIOS name Resolution UDP in - 138
SAM/LSA TCP in - 445
SAM/LSA UDP in - 445
Secure LDAP TCP in - 636
Secure LDAP for Global Catalog TCP in - 3269
W32Time NTP UDP in - 123
RPC - RPC Dynamic
RPC Endpoint Mapper
DNS - TCP and UDP 53
Kerberos V5 UDP in - 88
Netbios Datagram UDP in - 137
Open the following outbound ports on the firewall to allow SMB and HTTP traffic
SMB TCP/UDP - 445
HTTP TCP - 80
Open the following inbound port on the firewall to allow SQL Traffic from the MP
SQL TCP - 1433
Give rights for the site server on the intranet to the site system server in the DMZ so the site systems can install on the server.
Setup Site Roles (DP, MP, SUP)
Setup a test client and make changes to LMHOSTS and HOSTS file (if needed, not sure if necessary yet).
Install SCCM client with ccmsetup.exe /MP:servername /logon SMSSITECODE=XYZ
Some may say to use an FSP. I don't know that it's necessary. These client installs will be done manually, and i'd rather look at the client logs.
We'll see how well this works this week. I'll post an update by end of week.