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.
Next, I’d like to mention that there might be a few good arguments to keep the port on 8443. First of all, depending your network setup and infrastructure, you might need to reserve port 443 for another service. In more basic network environments you might get in trouble with forwarding port 443 to your Jamf Pro server, if you don’t have more advanced routing or proxy functionality in place. One example could be the Jamf AD CS connector, which also requires an inbound 443 connection for instance. Running multiple services on the same port behing your firewall will bring in the need of more advanced setups like reverse proxies.
Another reason might be the fact that the Jamf Community, which is so awesomely active in creating and sharing additional tools, scripts and workflows (have a look at the amount of GitHub projects related to Jamf), is assuming Jamf Pro to communicate over 8443. This means that you might put yourself in a situation where you’ll have to review all 3rd party scripts and tools to make it work over a custom port.
Sometimes I read or hear that keeping Jamf Pro on the standard 8443 port gives you a tiny security advantage. While I wouldn’t go anywhere near calling this a security feature, the fact that SSL communication is by default assumed to go over port 443, keeping Jamf Pro on port 8443 might give you a very tiny advantage indeed. Only people who intentionally try to reach your Jamf Pro URL will know that they have to try on port 8443. Keeping it on 8443 reduces the odds of someone hitting the HTTPS Jamf Pro URL by coincidence. But again, I would only call this a small extra advantage, calling this a security measure would put a lot of security experts on their high horse.
In general, if you don’t have a very solid argument to do otherwise (like putting Jamf Pro behind a load balancer and/or terminate SSL), I’d say leave it on port 8443.
That said, there might indeed be reasons forcing you to change it anyway, so let’s have a look at how you would change the port if you really want to.
For the purpose of this exercise I’ll assume we want to change 8443 to 443, but changing it to another custom port would give us the same workflow. Unless you want to use a port above 1023.
As we know all ports below 1024 are privileged ports, so depending the OS you are running Jamf Pro on, changing port 8443 to 443 might be a problem.
For Windows, it should be straight forward. Just change the connector port in the server.xml (C:\Program Files\JSS\Tomcat\conf\server.xml – see the Ubuntu workflow below for the change to make), restart Tomcat, add a firewall rule if you have Windows Firewall (or any 3rd party firewall) enabled, and you should be good to go. Unless you are already running other services on port 443 of course, like IIS… which would again be a good reason to keep it on 8443.
Linux is a different story however… as binding to privileged ports on Linux is a root-user privilege.
If you are running Jamf Pro on RHEL, your options are going to be limited. You either change the Tomcat user to root, or you configure Apache as a reverse proxy in front of Tomcat. Using root to run Tomcat is something I’d really like to avoid (security wise), and setting up Apache as reverse proxy in front of Tomcat, on the same machine, is possible, but allow me to leave this discussion for another time.
If you are running Jamf Pro on Ubuntu however, you are in luck, as there is something called AuthBind to make this happen (without running Tomcat as root). “Authbind allows a program which does not or should not run as root to bind to low-numbered ports in a controlled way.”
Note: The following workflow is valid for Jamf Pro 10.x and Tomcat 8.
The first thing to do is to backup the Jamf Pro server.xml. Do it! Never touch the server.xml without creating a backup, even if you know 100% what you’re doing, one typo could bring the server down. Good luck finding the little typo in the XML syntax 🙂
Let's first elevate our privileges to make the necessary changes:
$ sudo su
(will ask for your password, the account your are using must be sudo enabled)
Change the working directory to where the server.xml is located:
$ cd /usr/local/jss/tomcat/conf
Create a backup copy of the server.xml file:
$ cp server.xml server_backup.xml
Use a text editor to tweak the file (I'll use nano here and keep the vim versus nano discussion for... well, no, let's not go there 🙂 )
$ nano server.xml
Change the 8443 port in the connector to 443. You should see a line starting with: <Connector port="8443" executor="tomcatThreadPool" SSLEnabled="true"
Just change the 8443 port to 443 and save the file ( ctrl-x to exit and 'Y' to save). Done? No, there is actually more to do!
We need to allow Tomcat 8 to own port 443.
This brings us to "Authbind to the rescue"! So let's install Authbind:
$ sudo apt-get install authbind
And change the permission for Tomcat to own port 443:
$ sudo touch /etc/authbind/byport/443
$ sudo chmod 500 /etc/authbind/byport/443
$ sudo chown jamftomcat /etc/authbind/byport/443
Finally we'll tell Tomcat to use AuthBind:
$ sudo nano /etc/init.d/jamf.tomcat8
Find the "# Define other required variables" and Add AUTHBIND=yes:
# Define other required variables
Save the file (ctrl -X and 'Y' to save).
And stop the super-user privileges:
Finally, one more thing to do! Don’t forget to update the URL in the Jamf Pro settings! Log in to your Jamf Pro server, go to Settings – Global Management – Jamf Pro URL and change the URL to reflect the port change… or just the URL without port if you changed it to 443).
Restart TOMCAT, and you should now have your Jamf Pro server on https://yourjamfURL without having to add the port (unless you changed it to a custom port other than 443).
Note: Changing 8443 to another port above 1023 does not require any service to run as root, or the use of Authbind. Just change the port in the server.xml connector and restart Tomcat.
That’s it folks!
But again, do not change the port on a production server with enrolled devices, see above, and check if you have other options before changing the Jamf Pro port. Subject to your network infrastructure there might me easier and more appropriate ways to achieve your goal.
As usual, if you liked this post, hit the like button, tell your friend about this blog and leave a comment below. Don’t hesitate to make suggestions, or corrections!