Exposing an on-premise Jamf instance to the internet?

[jazminepena]

Hi guys,

We've traditionally been on-premise with our Jamf instance and DP restricted to site only but with the landscape changing I've been tasked with getting our Jamf instance exposed to the internet, primarily so that we can ensure Macs are getting patched when off-site.

Migrating to Jamf Cloud is not an option, at least in the short-medium term.

I'm going to work through the document here but wondered if there is anything else I need to consider or any advice you may have?

For instance, our existing instance has a third-party SSL certificate from Quovadis, I'm assuming I will need something similar for the new externally available instance? And going forward, would I be right in saying that I don't need to touch anything on the externally visible installation, and just create new policies and profiles on the internal one?

Our DP is also only exposed to our site, and is hosted on the same server (a Windows Server 2019 VM) as our Jamf instance.

Thanks!

[sdagley]

@jazminepena

You'd install the same SSL certificate on both the internal and DMZ JSS instances as they must have the same DNS name, and that would be the one your existing JSS is using. You'll use split DNS so machines on the internal network will resolve the address to your internal JSS while machines on the public Internet will resolve to your DMZ JSS.

What are your plans for a public facing DP? Hosting the JSS and DP on the same server is not ideal. If you're not using HTTPS for your internal DP now would be the time to create a new VM dedicated as a DP and using HTTPS content delivery (most network security teams will laugh at you if you ask about a public facing SMB server). You could set up a DMZ proxy to that server as your public facing DP, or create a 2nd DP hosted in the DMZ.

[anickless]

I have walked down this road and what @sdagley is mentioning is correct. Alternatively trying to do this was the reason we moved to JAMF Cloud ultimately, yes its more money but since it solved more issues than it created it was worth the cost (only a couple of dollars more per device). We did it a year ago and when Covid-19 hit staff just went home and worked like normal from a JAMF perspective.

[jazminepena]

@sdagley Thanks, I was a bit confused about the certificate part! We do currently use a DNS alias for our existing instance and we specify that as our JSS URL. So, I presume I'll need to specify the same URL in the external instance and then set up the MySQL clustering.

We are indeed using HTTPS for our DP at the moment, but I will look at moving that to a separate VM once I've got things up and running successfully.

[MartinB]

We (K12 International School) had the same situation in March when suddenly all teachers had to work from home and the IT Department had to find a short term solution. In theory I knew how to set that up but I never did it before, now I can confirm that @sdagley 's description is the correct way for a clustered on-premise JSS.
We decided to use an Amazon cloud distribution point for the DMZ machine. Amazon was very helpful and gave us a credit because of the special situation. The setup was a little bit tricky because we wanted to store our packages in the Central Europe Region instead of the default US East one that is created by the JSS, I had to manually create the bucket. Policies and Self Service from cloud DP for home office users are working well for us.

[talkingmoose]

@jazminepena, you may find Jamf's Training Catalog videos about advanced configuration helpful. It includes how to cluster servers like you're wanting to do.

As a customer, you have access to all the videos in the Training Catalog.

https://trainingcatalog.jamf.com/series/jamf-pro-server-advanced-configuration-series

[jazminepena]

Thanks @talkingmoose - I will definitely dive into those tomorrow!

Can I just clarify point 1 in the procedure - do I configure Clustering on the new external server in the DMZ (or the internal one?)

What would you consider to be the optimal limited access setting for the external instance in my case?

[donmontalvo]

@talkingmoose

[sdagley]

@jazminepena You configure clustering on the internal JSS. For Limited Access you definitely want your DMZ JSS set to Computer Access Only if you're only managing Macs (do that after you install the SSL cert though).

[talkingmoose]

Adding to what @sdagley said above, you'll want to follow a procedure like this:

1. On your first Jamf Pro server, enable Use Clustering under Settings > Clustering. Click the radio button to make sure your current server is the Master and save.
2. Install Jamf Pro on your new server.
3. Follow the procedure to point your new server to your MySQL database.

Your new server will automatically connect as a clustered server. You'll see it appear as a second server when viewing Clustering on your Master server.

[dmw3]

Well, we are in the process of allowing our internal JSS to be accessed via https from external computers.

We tried recently to get management to have our Jamf setup in the cloud, but unfortunately no luck. So next thing was to look at having either another JSS in our DMZ or allowing HTTPS request through the firewall to the current on-prem server.

Looking at the posts, it seems that the recommended way is to have a seperate server for external access, any particular reason why? One issue we thought about was the syncing of all the packages between the two severs, currently over 1TB, the other is that we want only some packages to be available to internal facing lab computers.

[bradtchapman]

@dmw3 : it's much safer to have a separate server for security reasons, and to place it in a network segment that doesn't have direct access to your internal network.

If your external server is attacked or compromised in some way, you generally won't lose the entire JSS and the database in one shot. Keep Tomcat + MySQL on the internal server, and install only Tomcat on the external server while opening tcp:3306 to the internal network from that server only. Open the perimeter firewall for inbound connections on tcp:8443 (or tcp:443) from the Internet to the external JSS node.

• Both servers need a matching internal and external DNS entry.
• Both servers need to have an SSL certificate with the same CN and SAN matching the DNS entry.
• Both servers need to have outbound connections permitted to tcp:2195, tcp:2196 and tcp:2197 for APNS.

[jazminepena]

Thanks so much everyone!

Just one final thing I think - do I need to open up port 3306 for MySQL from the external Jamf Pro server to the internal server? Does that port also need to be opened up outbound on the internal instance?

And port 8443 (and 443 for our DP) in and out to/from our external Jamf instance via our border firewall?

[sdagley]

@jazminepena See @bradtchapman's post above for details on ports that need to be opened. The only thing I'd add to it is you'll need TCP ports 139 and 445 open between your internal network and the DMZ DP server if you're going to use Jamf Admin to sync it with your internal DP (if you're planning on using rsync or another synchronization tool they'd require different ports)

[jazminepena]

@sdagley Thanks, for some reason I completely missed @bradtchapman's post initially!

[ianmasterson]

We are attempting to do the same thing, but the network guys tell me that we have no DMZ as such, and split DNS just isn't possible right now. Jamf Cloud is also not an option for us anytime soon.

Does anyone know of any ways around this? Would pointing everything internally and externally to our new external JSS work perhaps?

[sdagley]

@ianmasterson Unless your "new external JSS" has the exact same DNS name and SSL Certificate as your existing internal JSS none of your devices are going to talk to it without being re-enrolled. You really should look at something in the cloud, either Jamf's offering, or running your own infrastructure in AWS.

[Tangentism]

Just one final thing I think - do I need to open up port 3306 for MySQL from the external Jamf Pro server to the internal server?

Have a read of section 5 on this article. You'll need to configure the MySQL to allow incoming connections from the DMZ server.

If MySQL is installed on a server different from where the Jamf Pro web application will be installed, it is important to replace "localhost" with the IP address of the remote server that will be trying to communicate with MySQL (i.e., the Jamf Pro web application server), as in this example:

CREATE USER 'uniquename'@192.168.22.22 IDENTIFIED WITH mysql_native_password BY 'Z9hfB#qta8YfUB{va6K';

[bradtchapman]

@jazminepena : it's been a while. Did you ever finish this?

[blackholemac]

I’m willing to share some of the temporary Band-Aids we did to our environment prior to moving to Jamf cloud, i’m going to play absolute devils advocate here... why is it off the table? In terms of cost, Through heavy negotiation with them I was able to get our cost down pretty doggone close to what we were paying for on prem... Not exactly the same price but about a dollar per iOS device more per year...As for the text side of the house, That too is almost a breeze...I would challenge you to come to my environment and ask a large helping of our staff if they noticed any changes this summer to how Apple stuff is being managed. I don’t think our staff even knows I moved it to the cloud other than the IT director and my team. Cloud distribution point that we got for moving it to Jamf cloud Is much more robust than the lousy distribution plan we spun up in haste when COVID-19 first broke out.

If you absolutely must stay on prem, you have about two or three good options...Host an external distribution point Over https and your DMZ and have fun securing it, write firewall rules, do split DNS tricks and spin up VMs in your DMZ. In short you will bend over backwards and probably get it to work, But then you gained extra servers and firewall exceptions to maintain Making upgrading even more painful.

My suggestion for what it’s worth is to reach out to your Jamf rep and just see what the finance would be to get it moved to the cloud. On the tech side they have talented migrators that can make it near painless. I say that as someone who successfully migrated to the cloud in the middle of a pandemic.

[jazminepena]

@bradtchapman Yes, all good - with a bit of assistance from support, we got our externally facing server all set up and working successfully in our DMZ!

@blackholemac It wasn't really a question of cost, just timing and resource. We hope to migrate to Jamf Cloud next year at the time of our renewal (when we have more time to plan it). The on-premise vs cloud cost difference that we were quoted was nominal.

[tlarkin]

Please do not put a web application in the DMZ, the Tomcat apps have basically full DB credentials, in clear text, located in the DataBase.xml file. Meaning that if an attacker got a hold of these credentials they can straight up do SQL injection into your jamf database. One could then trivially tack on say some curl | bash commands in say policy advanced payloads and now your clients will download malware.

Look at extending some sort of appliance that is internet facing. Load balancers, VIPs, Proxies, WAFs, and so forth. Then slap TLS on that appliance and route authenticated traffic into a set of Tomcats internally that are not exposed to the internet. Even if you patch Java and Tomcat all the time, it is still a pretty big risk to put an entire web app in the DMZ. I highly recommend not doing this from a security standpoint.

[donmontalvo]

I wondered how long it would take @tlarkin to respond to this thread. :)

He is right, I know because I got my butt handed to me for suggesting doing just that at a previous gig.

¯_(ツ)_/¯

At the time our architect @henryxyz was able to put two headless Tomcat instances on the DMZ, using split DNS, load balancing, and some other wizardry.

Security did some penetration testing and found it to be secure. Guessing he might chime into provide more info if he is inclined to.

[bradtchapman]

I'll chime in on this: we have two Tomcat instances behind a "virtual IP address" that functions as a load balancer, and faces the Internet. Only port 443 is allowed inbound to those two nodes and SSL is passed through so the JSS can perform the SSL validation. The Tomcat nodes have unique public IP addresses in order to establish a two-way route with GSX (Apple maintains a whitelist of customer IPs), plus APNS and other permitted services / domains. Everything else outbound must go through a proxy server in the DMZ.

The recent Jamf vulnerability involving exposure of data via Apache JServe Protocol (AJP) on port 8009 was not even an issue for us, because that port was totally unavailable from the Internet.

[bradtchapman]

@blackholemac : You talk as if Amazon S3 didn't exist. We use this for our cloud distribution point with on-prem and it works fine.

[blackholemac]

@bradtchapman You are absolutely right in that from my org's point of view (and many others I've heard of) it doesn't exist. Our management will not pay the cost for S3 as a standalone product period. Had we kept it on campus we would be using my awkward Azure File Sharing DP kludge. Basically we get a sweetheart deal on Azure. As such Amazon or Cloudfront are not allowed to be considered for our IT projects unless they are being provided as part of a service we use. That was secretly one of the benefits I threw into the cost-benefit analysis.

@jazminepena As for planning the move...strangely enough it doesn't take long in theory as long as your JSS is solid in general...basically in our case, my JSS is mostly doing what I wanted, we didn't want to change our URL, we didn't want to re-enroll or have the server appear a lot different...we simply sped up the migration. That project was my number 1 priority this summer. Strangely enough, the actual migration took us less than 2 hours to get up and running and overnight to get our JCDS point seeded.

[blackholemac]

As for @tlarkin 's comment...it's very true and a very ugly scenario...when I was first planning on adding external support years ago, I had a colleague do a simple security audit on our former on prem server design and well he hated that...we solved by putting the tomcat nodes behind the load balancer and made the balancer the sole way in...it was very awkward but doable if interested. I will definitely pitch the cloud though simply because of how smoothly Jamf made our transition.

[tlarkin]

@blackholemac Just curious on the S3, is it a cost thing or is it just cloud storage is a no go? I am wondering since cloud storage is so cheap it is probably cheaper than whatever it cost you to self host the distribution points yourself.

[bradtchapman]

@blackholemac : did you edit your post four times in the space of 10 minutes or so? Jamf Nation alerted me five times via email that I was mentioned in this post.

[blackholemac]

I did but wasn’t trying to be a turd... I have a bad habit of rereading something I write long after I post it I shouldn’t do that I should read it before I hit post but I’m really weird about that. Please forgive

[blackholemac]

@tlarkin I do mean what I said on a 100% cost basis. Microsoft is essentially giving us (a school district) Azure and charging a very trivial amount for bandwidth usage. As such I’ve been advocating for a formal Azure distribution point for years... https://www.jamf.com/jamf-nation/feature-requests/2083/microsoft-azure-support-for-cloud-distributions-points

The short of it is you don’t have to sell me on having a cloud distribution point (whatever vendor provides) because I agree with your position 100%. I merely have to deal with, “Why can’t we do it on Azure instead?” The good news is that this pandemic actually gave me a whole lot ammunition to move our Jamf Pro instance to the cloud...period. Along with it, I get to reap all the benefits of being a Jamf Cloud customer now...(cloud distribution point Included) without having to wait on that feature to be added.

I’m sure all of you have been presented with the comment, “Why can’t we do <whatever it is we are trying to do> with <whatever it is that the org prefers or already has>. I don’t encounter that too often but I do sometimes especially if I want to build something in the DMZ for whatever reason. I actually had a file distribution point working In Azure, but it was very slow, not very effective and not exactly my ideal. With Jamf Cloud, I get a supported solution.

[tlarkin]

@blackholemac ah I see, well Azure is also a very solid cloud platform. We use both Azure and AWS. I misread the whole thing and thought you were not allowed cloud storage because of cloud prices, my bad. Reading and words are hard.

[Will-Kriel-Hart]

Hi. I was wondering if anyone has any clear instructions on what needs to be done, and how for the split DNS setup. Our network team appear to have gone down a certain track, and the results aren’t working. I’ve explained that the internal and DMZ IP addresses need to resolve to the same name, but each time they come back to me, they don’t. Any simple explanations would be great.

[alexjdale]

We have an internal web server and a limited access DMZ web server (behind a load balancer so we can filter traffic to block JSS URLs we don't want available), both using CNAME records that resolve to their appropriate IPs (DMZ server for the Internet, and the internal server from our corporate network). Each web server talks to the MySQL database server. The CNAME is the same for both records, they just resolve differently depending on the network.