build new Casper environment

I was under the impression that the JSS liked to handle MySQL replication itself and preferred to have the MySQL service running on each JSS Instance. You then limit the individual JSS instance to the functions you want it to perform. If you look at https://jamfnation.jamfsoftware.com/article.html?id=34 for LDAP connections it wants an outbound connection for the clients to connect to the JSS on the LDAP port. Otherwise everything looks okay to me. You may want to change the way you embedded the dropbox link though.

That all looks good. You probably need outbound access to the APNs servers from all JSS. Not sure if all JSS instances need access to your SMTP server, not for automatic reporting but if you send an email through your JSS. Shouldn't be an issue if you intend to have a limited access JSS in the DMZ.

Also, remember that you can cascade you JDS's, they don't all have to pull from the master. This can be really useful to regionally distribute packages and minimize traffic coming all the way back to your JDS master across your MPLS.

@jdziat][/url LDAP traffic goes from the JSS to the AD server, in this case. Client machines authenticate over their interface with the JSS, https (8443 typically), and the JSS passes those credentials to the LDAP server for validation. Also MySQL replication is more of an advanced setup for high availability, definitely not required and definitely not handled through the JSS. And the Tomcat process and the MySQL database do not have to be hosted on the same server. Unless you have a smaller installation with only a couple hundred clients, it is often preferred to separate out those processes.

I would like to see your plan, but I don't see the attachment. Could be an id10t error on my part.

I don't see the plans either.

Maybe it got wiped when the heartbleed fix was put in place?

@ctangora - OT thats an epic beard.

thanks for providing the feedback you guys gave. i updated my initial post, it now shows the proper link and a somewhat edited version of the document :)

@jdziat we are actually implementing LDAPS as we'd like user credentials to be as secure as possible.
by pulling the mysql from the JSS i'm trying to make the basis more scalable for future growth. mysql replication is definitely something that could come in handy in the future. just as load-balancing the JSS webapp would be a definite added value in the future if we need to expand availability.

@Josh_S could you explain why the webapp would need to communicate to the APN? I'm under the impression that the webapp becomes a node that only communicates with clients and all "management" tasks go trough the master JSS. JDS Cascading is definitely something we are looking in to.

@ctangora my url skills were to blame, bleeding heart to admit tough :)

I've had mysql and the JSS running on separate servers for about a year and a half now for much the same reason, and the service has been functioning as excepted.

@Bendelaat I'm not 100%, but I think that it is true that any automatic management tasks are always handled by the master JSS, in order to avoid any duplication. However, if I log into a secondary JSS and issue a manual push command (wipe/lock/remove MDM/blank) I think that the initial communication to the APNs servers will be issued from the JSS I am logged into. For the same reason you may need SMTP access by those other JSS to manually email from the JSS if this might be done by accessing a non-master JSS.

Just tested by sending a blank push to one of my clients from a non-master JSS in my test environment and watched the connections with netstat. There is some communication outbound to Apple's 17.0.0.0/8 address block.

tcp        0    171 ::ffff:xxx.xxx.xxx.xxx:33913 ::ffff:17.149.33.63:2195    FIN_WAIT1   -

[s]However, if all of your management happens only through your master JSS, either by policy or locking down all others as limited access JSS, then you should be fine with just your master JSS having access to those services.[/s] If you only intend to have a master JSS and a single JSS in the DMZ, it's not a bad idea to lock it down like this.

Actually, thinking about this a little more, if one of your client machines checks in with your JSS in the DMZ, and that check-in results in a push command being sent (change in smart group for example), the push command might come from whichever JSS the client is checking in with - the one handling the triggering event. Probably be best to just allow all your JSS access to Apple's APNs servers.

thanks @Reno, nice to here this approach is working for people, always gives confidence.

@Josh_S seems you are right https://jamfnation.jamfsoftware.com/discussion.html?id=6808 franton describes a situation just like you considered. thanks for your thoughts on this. i'll update the drawing.

Hi @Bendelaat,

I know it's an old thread and there could be a lot of changes in your environment up to now.

We are also in progress of setting up clustered JAMF/Casper Suite environment and will need to use DMZ for security reasons, and only DMZ will be allowed to communicate with APNs - so as I understand it will need to be Master one. But can master be with Limited Access or not? Or is it like Master = Full JSS; Child = Limited Access? As it not stated clearly in any of these links:
[https://www.jamf.com/jamf-nation/articles/212/upgrading-the-jss-in-a-clustered-environment](link URL)
[https://www.jamf.com/jamf-nation/articles/420/understanding-master-and-child-web-application-responsibilities](link URL)

Also maybe it would be still possible to share network diagram which you had before? :)

@Rokas

The master should not be in the DMZ. It's more secure to open your firewall to the 17.0.0.0/8 block for the master JSS, than to put it whole in the DMZ.