JAMF Cloud and locally-hosted distribution points

[gb3]

We are investigating switching from our locally hosted JSS to the cloud solution and are trying to work out the best way to handle distribution points.

Or initial plan was to have one external-facing (the goal being HTTPS access only) and one internal-facing but, based on our discussion with our TAM, the JSS would need read/write access to both, which would mean enabling AFP or SMB through our firewall.

How are others handling this? Any tips and tricks to keeping it secure while still giving the cloud JSS the access it needs?

[adamcodega]

Could you clarify what you mean by the JSS needing read/write access? Do you mean Casper Admin needs read/write access to the distribution points?

[gb3]

I asked my TAM "If we have an internal repository and an internal (sic - meant external) one, does the JSS need to talk to both or is it sufficient to only talk to the external JSS through the firewall? And does it need read/write access?"

He answered "The JSS will need to talk to both of them as well as have a User with read/write access."

[rderewianko]

Best practice, your internal REPO would need read/write as thats its the higher bandwidth (in theory) and where you'd manage your repos from. Then from your internal repo it would replicate to your external. Your external wouldn't need write permissions to the internal repo but read permissions. Your Internal repo would definitely need to be able to write to your external.

Alternatively, some sync magic using rsync, btsync etc, should be able to mirror your internal repo for the https one.

[gb3]

But according to our TAM, the JSS does need read/write to both repos.

[drew_duggan]

With your shares, the JSS just keeps the shares information and then when you launch Casper Admin (assuming that's the what you're using to add packages, etc. to the share) the application itself just populates the user/password you have listed in the JSS.

If you're using Casper Admin to replicate your master to your secondary share(s), you WOULD need read/write access on the shares since we're modifying both of the shares. However, you could definitely lock that down a little by utilizing an Rsync script of some kind which then would bypass the JSS needing read/write access to the secondary share.

With security concerns you could also throw in HTTPS into the mix to add the certificate communication requirement. Another option would be the JDS which will use certificate-based communication and webDAV.

But your TAM is correct in that if you're going to use a standard afp/smb share and then just add HTTP/HTTPS on top of that, and then are using Casper Admin to replicate, you'd need to open up access for both of those shares to have r/w privileges.

There are a number of different ways you could have this all set up though. It's just a matter of how locked down you want this to be...

[gb3]

After talking internally it looks like we may just be going with 1 single repo after all, which will be accessible both externally and internally.

What we want to avoid is any need to open more than HTTPS to the outside world. Internally we're okay with SMB being open (because that's how I'll use Casper Admin to add to the repo, for example). If the JSS doesn't actually need access to SMB, we're happy.

[drew_duggan]

You may want to still consider at least having something for failover at least for your internal clients, otherwise, you can get flooded with policy failure messages if the HTTPS share is unavailable. Totally your call though.

If you have HTTP/S enabled, the clients will only attempt to download content from those URLs. You wouldn't see those fail, and then automatically switch over to use SMB, unless your policy is executing with he option to force over AFP/SMB, then that security piece should more or less automatically take place. Failover will only go to a different share...not that singular share using a different protocol. Just something to consider with the failover piece of distribution.

Hope that helps!

[gb3]

Thanks! Very helpful.