Prerequisites for Internet-Based Client Management (IBCM) in Configuration Manager

Overview:

I often find myself talking to customers about the requirements to setup Internet-Based Client Management (IBCM) in Configuration Manager. There are a decent amount of prerequisites that need to be configured for IBCM.

In this post, I’m going to go over the prerequisites and considerations when implementing IBCM.

Prerequisites:

  • Public DNS Name
    • You will need a public DNS name e.g. (ibcm.contoso.com) for the site system that will be accepting communication from internet clients
  • Public Key Infrastructure (PKI)
    • We need a PKI that can create and issue the required certificates for Configuration Manager
    • I highly recommend using a Microsoft PKI since it makes issuing and renewing the client certificates very easy
  • Trusted Root CA between Site System and Client
    • Internet-based clients must trust the Root CA of the internet-facing management point’s web server certificate
    • Internet-facing management point must trust the Root CA of internet-based client’s client authentication certificate
  • Internet Connectivity
    • The site system accepting connections from internet client will need connectivity to the internet
    • Any internet-facing client will need internet connectivity to communicate with the Internet-facing site system
  • Ports
    • From the Internet:
      • MP/DP/App Catalog: 443
      • Software Update Point: 443 or 8531
      • Fallback Status Point (If Used): 80
    • Internal / DMZ:
      • If the internet-facing site system is in a DMZ network, you will need to ensure the following ports are open between the internet-facing site system and internal resources: Ports required for DMZ site system 
  • Domain Joined
    • The internet-facing site system must be domain joined. It can be joined to a untrusted domain in a DMZ. If the internet-facing site system is joined to an untrusted domain, user based policy is not supported from internet-based clients.

Firewalls / Web Proxy Servers:

It’s unlikely and definitely not a good practice to have your internet-facing site system directly exposed to the internet. You will probably have sometype of firewall or web proxy server such as (TMG / F5 / Netscaler etc.)

When using a web proxy server for IBCM, you can configure it to use SSL bridging, SSL tunneling or Port forwarding. SSL bridging is the most secure method. If you are only using a Firewall, you may have to configure SSL tunneling unless the firewall supports SSL bridging. Port forwarding is the lest secure and should only be used in a home lab for basic IBCM testing.

  • SSL Bridging

    • Packets from the Internet are subject to inspection before they are forwarded to the internal network
    • The proxy web server authenticates the connection from the client, terminates it, and then opens a new authenticated connection using a client authentication certificate to the Internet-based site systems
    • When Configuration Manager clients use a proxy web server, the client identity (client GUID) is securely contained in the packet payload so that the management point does not consider the proxy web server to be the client
    • Slower performance since packets are inspected but much more secure than SSL tunneling
  • SSL Tunneling

    • It is a less secure than SSL bridging because the SSL packets from the Internet are forwarded to the site systems without SSL termination, so they cannot be inspected for malicious content
    • The certificate is checked, but then the packet is forwarded through the tunnel without allowing any ability to inspect the data
    • When you use SSL tunneling, there are no certificate requirements for the proxy web server (If used)
    • Fast performance and easy to setup
  • Port Forwarding
    • Least secure of the 3 options
    • Simply forwards traffic coming from the internet to a server on the internal/dmz network
    • Shouldn’t be used in production environment if possible
    • Useful in a home lab for a quick setup for testing
    • Fastest performance and easiest to setup

See Adam Meltzer’s blog “Firewalls and IBCM” for a little more detailed information on the Firewalls with IBCM.

Certificates:

We need certificates on both our internet-facing site system and any client that will support IBCM.

  • Certificates for the Internet-facing site system:
    • Web Server Certificate:
      • This certificate is used to secure client communications into IIS such as connections to the management point or distribution point
      • See the “Deploying the Web Server Certificate for Site Systems that Run IIS” section in this TechNet doc: https://technet.microsoft.com/en-us/library/gg682023.aspx for step-by-step instructions on creating and issuing this certificate to your internet-facing site system
    • Client Certificate:
      • This certificate is used by the MPControl component to ensure the management point is online and accepting connections
      • See the “Deploying the Client Certificate for Windows Computers” section in this TechNet doc: https://technet.microsoft.com/en-us/library/gg682023.aspx for step-by-step instructions on creating and issuing this certificate to your internet-facing site system
      • Note: I use the client certificate rather than the distribution point certificate since this internet-facing distribution point will not be used for operating system deployment. The client certificate does not require the private key to be exportable
  • Certificates for the Internet-based clients:
    • Client Certificate:
      • This certificate is used by the the client when it communicated with the internet-facing site system
      • See the “Deploying the Client Certificate for Windows Computers” section in this TechNet doc: https://technet.microsoft.com/en-us/library/gg682023.aspx for step-by-step instructions on creating and issuing this certificate to your windows clients

Certificate Revocation List (CRL) Checking:

CRL checking is performed by both clients and the site system.

  • The client: will verify its certificate and the web server certificate of the internet-facing site system is not revoked.
  • The site system: IIS will check to verify the certificate from clients are not revoked.

Certificate Revocation List (CRL) Distribution Point:

If you want to enable CRL checking (Which you should), the internet-based clients will need to be able to access the CRL distribution point when the client is internet connected. By default a Microsoft CRL distribution point will publish its CRL to active directory only, and the CRL can only be accessed via LDAP. See the screenshot below for an example internal CRL distribution point from a client certificate:

image

This is obviously an issue since an internet-based clients will not be able to access this CRL DP. The solution here is to use a HTTP CRL distribution point. This will ensure clients on the internet as well as the internet-facing site system (If in DMZ or Untrusted forest) will be able to access the CRL distribution point without any issues. Here’s an example of a client certificate issues with a HTTP CRL distribution point:

image

The process for creating a HTTP CRL distribution point is available at the ConfigMgrTeamBlog here:  https://blogs.technet.com/b/configmgrteam/archive/2009/05/01/how-to-publish-the-crl-on-a-separate-web-server.aspx

Challenges:

  • Internet-based clients are not location aware so if you have multiple internet-facing site systems the client will randomly choose between them

  • Unsupported feature for Internet-Based Clients

    • Automatic site assignment
    • Network Access Protection (NAP)
    • Operating system deployment. However, you can deploy task sequences that do not deploy an operating system; for example, task sequences that run scripts and maintenance tasks on clients.
    • Remote control
    • Out of band management
    • Software deployment to users unless the Internet-based management point can authenticate the user in Active Directory Domain Services by using Windows authentication (Kerberos or NTLM). This is possible when the Internet-based management point trusts the forest where the user account resides.
  • Prior to Configuration Manager 2012 R2, the client would not automatically receive the internet management point it would need to be defined using the CCMHOSTNAME install property or set via VBScript like below if an existing client:

     On Error Resume Next
    Dim IBCMServer, SMSClient ' Variables
    IBCMServer = "ibcm.contoso.com" ' Enter IBCM FQDN here
    Set SMSClient = CreateObject ("Microsoft.SMS.Client") ' Create the SMSClient COM object
    SMSClient.SetInternetManagementPointFQDN IBCMServer ' Set IBCM Server
    

Additional Resources for IBCM: