I happened to have a script I wrote a while ago that allows a user to do just this. In short you use an extension attribute with pre-populated choices of groups they might want to add their computer to. The script pulls these values live every time via the API so you don’t have modify the script every time you want to modify the list of groups the user can choose.

The script then pops up a Tkinter window that presents the user with a drop down list of those choices from the extension attribute, the user makes their choice, and the choice is written back to their computer’s inventory record in the Jamf server.

From there you can create smart groups with criteria that matches specific values in that extension attribute and then scope to machines that fall into those groups.

I’ve added the script and basic directions to github. You can find it here:

When you are in Setup Assistant, you can open Terminal or Console by pressing:

CTL + OPTION + CMD + T (for Terminal)
CTL + OPTION + CMD + C (for Console)

Terminal will then launch as _mbsetupuser which is the user that Setup Assistant runs as.

Now that we have Terminal launched, what can we do with it?

Pretty much anything that doesn’t require elevated privileges.

The most common use would be to get the IP address of the machine while it is at Setup Assistant using either ifconfig or networksetup.

Since Terminal is launching as _mbsetupuser, we can’t do anything that requires root level permissions. But if we enable the root user ahead of time, we can elevate our permissions to do things that are more interesting.

Enabling root on a machine that hasn’t gone through setup assistant

1. Start up your machine into single-user mode.
2. Mount the boot drive as read/write: /sbin/mount -uw /
3. Enable opendirectory: launchctl load /System/Library/LaunchDaemons/com.apple.opendirectoryd.plist
4. Enable root password: passwd root
5. Reboot: reboot

Now when we start up the machine and it is at the Setup Assistant, when we launch Terminal then change our user from _mbsetupuser to root with su.

One interesting thing we could do with this is to take an unconfigured machine with a release version of macOS and upgrade it to a beta version of macOS before it has been configured so, for instance, we could test upcoming changes in DEP enrollment.

Rich Trouton has a very nicely detailed article on using seedutil in High Sierra to enroll a machine into Apple’s macOS beta software update channel that is worth a read. Here I’ll quickly cover how to enroll our un-configured Mac to receive betas from the public beta feed. Assuming you’ve already enabled root in single user mode (and that you are a member of the public beta program):

1. Open Terminal at Setup Assistant
2. Elevate yourself to root: su
3. Enroll in the public beta feed: /System/Library/PrivateFrameworks/Seeding.framework/Versions/A/Resources/seedutil enroll PublicSeed
4. Run softwareupdate to install all updates: softwareupdate -i -a
5. Reboot: reboot

Using Console

You can also launch Console as noted above. One reason you might want to do this is troubleshooting by monitoring the logs for the mdmclient process as you attempt to enroll the machine through DEP, tailing the Jamf log or whatever bootstrap processes you have that might get triggered before the machine has moved passed the Setup Assistant.

But what if you don’t want the Jamf admin console visible to the external world but still want to allow your clients to check in, enroll, or access the API? If you were in a clustered environment you could easily change the Limited Access settings for your externally facing webapp to something other than “Full Access”, but this isn’t possible on a single server setup.

At our org I found myself in this situation with a development Jamf server that I wanted to be available both internally and externally but only use one server in AWS to keep costs reasonable. The server would be behind an AWS load balancer which would handle HTTPS termination and limit exposure to the outside world.

I decided the most obvious way to determine an internal machine vs an external one would be based on IP address. So, is it possible to filter connections to Tomcat based on IP? It is! To accomplish this we need to use a Tomcat filter.

Two caveats: This has only been run in production with Jamf Pro 9.x though it seems to work fine with version 10.x with some slight modifications which I’ll note below. Also these modifications can be overwritten during Jamf Pro updates so you will need to reapply them each time.

Tomcat provides many filtering options but the one we want is “Remote Address Filter” which according to the documention:

“allows you to compare the IP address of the client that submitted this request against one or more regular expressions, and either allow the request to continue or refuse to process the request from this client.”

For this to work we need a regular expression that will match any IPs in the standard private IP ranges of:

• 10.0.0.0 to 10.255.255.255
• 172.16.0.0 to 172.31.255.255
• 192.168.0.0 to 192.168.255.255

I wrote this simple regex that should capture all those IP addresses.

Next we need to pair the regex with a Tomcat filter that is set to accept connections from IPs that are matched:

Use this for Jamf Pro version 9.x:

Use this for Jamf Pro version 10.x

You’ll then need to insert that xml into the webapp’s web.xml file (including after every upgrade) at /usr/local/jss/tomcat/webapps/ROOT/WEB-INF/web.xml

Stop Tomcat and place the filter xml code in the file. In my case I inserted it under this section in the file (for both v9 and v10):

1
2
3
4

<servlet-mapping>
  <servlet-name>LegacyRestRedirectServlet</servlet-name>
  <url-pattern>*.rest</url-pattern>
</servlet-mapping>

Restart Tomcat and try to hit your Jamf Pro’s server from a public IP:

Awesome! But wait…the default Tomcat error page is not great and it’s also showing what version of Tomcat we are running which could give someone looking to exploit known weaknesses in certain versions of Tomcat an easier time of discovering if we are vulnerable. (Hat tip to Ross Derewianko who pointed out this security issue to me a while back.)

Luckily we can set a custom 404 page in Tomcat for this. It’ll just take a bit of extra work.

First, we’ll need to create an error page and place it at the root of our Tomcat webapp at /usr/local/jss/tomcat/webapps/ROOT/, and for this example I will call it 404.jsp

Next, we’ll need to tell Tomcat that we want to use the 404.jsp file as the 404 page when someone tries to reach our admin console from a denied IP address. To do this we’ll need to edit a different web.xml file, which can be found at: /usr/local/jss/tomcat/conf/web.xml

Edit this file and search for welcome-file-list and beneath this section, add:

With that done, now restart Tomcat, and when you try to visit the admin login from a denied IP address, you should no longer see the generic Tomcat error page but the one you just created.