How to change the default Jamf Pro port to 443… and why you might want to keep it on 8443.

Many people have asked me how to change the default port that Jamf Pro is using for the SSL communication, which is by default 8443. Or even change it to any other custom port (when terminating SSL behind a load balancer for instance).

First off all, and this is very important, do not change the Jamf Pro port in a production environment with enrolled devices. The port is part of the URL that the devices trust for MDM enrollment and management. Changing the port breaks the enrollment and you will have to re-enroll all devices!

Secondly, configuring Jamf Pro behind a load balancer is beyond the goal of this post. For such more complex setups, I’d advise to have a look at the Jamf 350 course. 

Continue reading “How to change the default Jamf Pro port to 443… and why you might want to keep it on 8443.”

Reverse proxy with pfSense and Squid

A quick test running a reverse proxy in my homelab…

Following my previous post on how to make your Jamf Pro server public, I gave it a try in my homelab…

Just note that this is only a proof of concept, as there are many reverse proxies, or load balancers, available for a production environment (both hardware as software). (For Load Balancing my clustered Jamf Pro setup, on another test server, I used HAProxy which has Reverse Proxy functionality as well).

An in depth discussion of how I configured my homelab for testing different scenario’s (both Jamf related as more general) might be for another time, but let’s quickly have a high level look at the following setup.

Continue reading “Reverse proxy with pfSense and Squid”

A public Jamf Pro server, DMZ or Reverse Proxy?

A quick look at how to make your Jamf pro server reachable from the Internet.

For this weeks blog, I’d like to touch the topic of on-premise Jamf Pro installations, and to be more specific, some consideration to make when making your on-prem server reachable outside your network.

First of all: the thoughts and statements in this article are my own. Please feel free to comment, correct and make suggestions, but just remember to refer to docs.jamf.com (and other Jamf KB’s, white papers and tech articles) for official guidance on supported installations of Jamf Pro.

That said, more and more people are choosing for Jamf Cloud over on-premise Jamf Pro installations, and this for multiple reasons. With Jamf Cloud you don’t need to manage your own server, keep it up to date, make it secure, etc… which frees up a lot of time you can use for other things, like managing your devices instead of managing servers or just use the time to enjoy a cold beer, nice cup of coffee or whatever you fancy doing instead of maintaining servers.

But some environments are not ready to move to cloud services (yet), because their type of business doesn’t allow it, or whatever other valid reason. Hosting an on-premise Jamf Pro server might sometimes be the only option. That’s fine, but hosting your own server comes with big responsibilities (which would otherwise be taken care of by Jamf when using Jamf Cloud), and apart from organising the required ressources, keeping your servers up and running, and investing time in maintenance, there are multiple network and security considerations to make.

I’m not going to dive into all the requirements for the Jamf Pro server, as those can easily be found on: Jamf Pro System Requirements

Instead, I’d like to touch one specific part of the on-premise setup: how to allow your devices to communicate with your internal Jamf Pro server, when they are outside your internal network, roaming the beautiful but sometimes hostile internet?

Continue reading “A public Jamf Pro server, DMZ or Reverse Proxy?”