Disabling Jamf Pro LDAP wildcard searches to speed up user and group lookups

When setting up Jamf Pro, one of the options you have is to integrate it with your company, school or institution’s LDAP-based directory service. Connecting Jamf Pro to LDAP allows you to query your organization’s directory service for information and also allows the use of your existing user accounts and groups when requiring logins or scoping policies.

When setting up Jamf Pro to connect to a directory service, there’s a Use Wildcards When Searching setting with the following description:

Allow partial matches to be returned when searching the LDAP directory

What this setting does is that it allows Jamf Pro to use wildcards when making LDAP searches of your directory service. That allows Jamf Pro to return search results that may only partially match what you told it to search the directory service for.

For directory services with fewer than five thousand user accounts and/or groups, having this option enabled is usually fine. However, once the directory service is larger than that, disabling the Use Wildcards When Searching setting may dramatically speed up user and group lookups. For more details, please see below the jump.

Using QuickAdd-based user-initiated enrollment on macOS High Sierra with Jamf Pro 10.3

Starting with Jamf Pro 10.3, user-initiated computer enrollment now has two modes:

• macOS High Sierra: Uses an MDM profile to enroll the Mac, with the Jamf Pro agent being installed once MDM enrollment is complete.
• macOS Sierra and earlier: Uses a QuickAdd installer package to enroll the Mac, with MDM enrollment and installation of the Jamf Pro agent being handled by the QuickAdd package.

However, it is still possible to get a QuickAdd installer package to enroll a Mac running macOS High Sierra. For more details, please see below the jump.

User-initiated computer enrollment now using MDM profile enrollment in Jamf Pro 10.3

One of the changes introduced in Jamf Pro 10.3 is that user-initiated computer enrollment now has two modes:

• macOS High Sierra: Uses an MDM profile to enroll the Mac, with the Jamf Pro agent being installed once MDM enrollment is complete.
• macOS Sierra and earlier: Uses a QuickAdd installer package to enroll the Mac, with MDM enrollment and installation of the Jamf Pro agent being handled by the QuickAdd package.

Why the difference?

Using the MDM enrollment method on macOS High Sierra will automatically enable User Approved MDM, which is necessary for full management privileges on the Mac in question. The reason is that since the user is installing the MDM profile, the user is also logically approving the MDM management and satisfying Apple’s conditions for enabling User Approved MDM.

For more details, please see below the jump.

Installing and configuring the Jamf Infrastructure Manager on Red Hat Enterprise Linux

I recently needed to configure Jamf’s Jamf Infrastructure Manager (JIM) to provide a way for a Jamf Pro server hosted outside a company’s network to be able to talk to an otherwise inaccessible Active Directory domain.

The documentation on how to set up an Infrastructure Manager covers the essentials of how to do it, but doesn’t include any screenshots or have information about how to access the logs to help debug problems. After some research and working with the JIM a bit, I was able to figure out the basics. For more details, see below the jump.

Generating multiple-use Casper QuickAdd installer packages using the JSS

As part of the process of upgrading my Casper server, I generally create a new installer for the Casper agent in the form of a QuickAdd installer package. This process usually looks like this:

1. Update the Casper Suite applications on the Mac where I’m generating the new QuickAdd installer package.

2. Open Casper Recon.

3. Sign into Casper Recon.

4. Select QuickAdd Package from the Recon sidebar.

5. Set up the desired options for the QuickAdd installer package.

6. Click the Create button.

7. Choose a name for the new QuickAdd installer package.

8. Wait for Recon to create the QuickAdd installer package.

9. Take the newly-created QuickAdd package and use it to replace the existing QuickAdd packages used by CasperCheck and my deployment workflows.

The reason I use this process is that Casper’s Recon application is able to generate a QuickAdd installer package with an unlimited enrollment invitation. With an unlimited enrollment invitation, I can use the same QuickAdd installer package multiple times to enroll multiple machines. This is in contrast the user-based enrollment process via the JSS, which by default generates a QuickAdd installer package with a one-time-use enrollment invitation.

I have this Recon-based process documented, but it’s always been something I’ve wanted to automate at least somewhat. Recently, as part of a discussion with my colleague Tom Larkin, I learned that a Casper JSS server which is configured to send out emails is capable of generating enrollment invitation emails, which include a link to download a JSS-generated QuickAdd. That invitation can be set to link to a QuickAdd with an unlimited enrollment invitation and an expiration date many years in the future, which effectively gives me the ability to generate the QuickAdd installer packages I want without the need to use Casper’s Recon application. For more details, see below the jump.

Performance tuning for the Casper JSS

One of the challenges Casper admins can run into is performance tuning, which can require going into parts of the JSS that you normally go into only when JAMF Support asks you to do so. To help with this process, there are formulas which you can use to calculate if your JSS’s Tomcat and MySQL services are configured for best performance.

Before proceeding further, I want to emphasize that a) check with JAMF Support first and b) you should always, always, always make backups of your JSS before changing settings. I assume no responsibility and bear no culpability if your JSS breaks as a result of anything you implement as a result of reading this post. I am also not responsible for incorrect math, ruining anyone’s weekend, or that long talk you now need to have with your boss about why your JSS is now broken.

One other thing to be aware of is that I’m going to be focusing on Linux and Windows in this post since those are the platforms that I’m most familiar with for hosting a Casper 9 JSS.

For more details, see below the jump:

Status report script for Linux-hosted Casper servers

As part of keeping an eye on my support systems, I’ve been using a script for my Casper servers running on Linux which emails me a status report on a daily basis. I adapted this script from an earlier one I wrote to monitor Tomcat and alert me if Tomcat was having issues. The script tells me a number of things that are useful to know, including the following:

• Uptime
• Free space on all attached drives
• Who’s logged in via SSH or in the console
• Virtual memory statistics
• Current system tasks
• SMB connections information
• Recent entries in the Apache server logs
• Recent entries in the JSS server log

In my case, my Casper servers are hosted on Red Hat Enterprise Linux so I’ve focused this script’s development and testing on compatibility with RHEL-based Linux distributions. That said, nothing in it is RHEL-specific so it should also work on other Linux distributions. For more information, see below the jump.

Adding a self-signed Casper Root CA as a trusted root

Since Elliot Jordan’s presentation at JAMF Nation User Conference 2014, I’ve started using AutoPkgr in combination with Shea Craig’s JSSImporter to automatically package and upload a number of software packages to my Casper servers.

Having AutoPkgr handle this task has been great, but I’ve had to do some additional work to make sure that JSSImporter was OK with Casper using SSL certificates issued by its own internal certificate authority instead of by a third-party external certificate authority like Verisign. On top of that, the urllib3 library used by JSSImporter added a new warning that is triggered by HTTPS requests that use an certificate that can’t be validated. Since the Casper server was signing its own certificates using its own internal certificate authority, this warning was being triggered on every AutoPkg recipes’ run, which sometimes resulted in interesting emails like the one below.

I could have installed the Casper agent on the VM that I was using to host AutoPkgr, which would have installed the root certificate for the Casper server’s internal certificate authority. However, I didn’t necessarily want to have Casper manage the VM as that would have consumed one of my available Casper licenses on a machine that didn’t need management.

However, I did want to get the root certificate for the Casper server’s internal certificate authority installed on the VM. That would allow the Casper server’s SSL certificate to be recognized as a validated certificate and fix the issues I was having with not having a validated certificate.

For details on how I fixed this, see below the jump.

Updating Red Hat Enterprise Linux and MySQL for Casper JSS server running on Linux

In my own shop, I’m currently running Casper 8.x on a Red Hat Enterprise Linux server. The server had been set up initially with Red Hat Enterprise Linux 6.0 and MySQL 5.1.47 and it had stayed there for a while. However, I looked ahead to Casper 9.x and saw the following versions of MySQL were now listed as being required:

MySQL Enterprise Edition 5.5 or later, or MySQL Community Server 5.5 or later

I’m still running Casper 8.x, but I wanted to get ahead of the curve and not have to deal with a MySQL upgrade at the same time as a future Casper 9.x upgrade. Thanks to the Linux folks at my workplace, I was able to do so with a minimum of hassle. See below the jump for the details.

Uninstalling Casper on Red Hat Enterprise Linux

I recently had to roll my Casper test server back, as I had been testing Casper 9.x but needed to verify something worked in Casper 8.x. Since I hadn’t found a good knowledge base article on JAMF Nation for uninstalling Casper’s JSS from a Red Hat Enterprise Linux server, I asked JAMF Support how to do this. Here’s the procedure I used, based on their response:

Note: This procedure should only be used if you need to completely uninstall your Casper JSS. It removes all certificates, databases and anything else stored in your JSS.

1. SSH into the RHEL server as my user account.

2. su into the root account on the server by running the following command:

su root

3. Stop JAMF’s Tomcat by running the following command:

/etc/rc.d/init.d/jamf.tomcat7 stop

4. Delete the jss directory from /usr/local by running the following command:

rm -rf /usr/local/jss

Once /usr/local/jss was removed, I needed to remove the JSS’s MySQL database in order to complete the uninstall. Here’s the procedure I used:

5. Run the following command to get a MySQL prompt:

mysql

6. From the mysql> prompt, run the following command to remove the existing database:

mysql> drop database jamfsoftware;

7. Exit out of MySQL with the following command:

mysql> exit;

At this point, the JAMF-provided parts of the JSS were all removed. I hadn’t removed anything from my JSS’s file share, so all my installers and deployable scripts were intact. I then rebooted, just to make sure no stray processes remained before I tried reinstalling Casper 8.x.

Once the server was back up, I ran the following procedure to prepare the server for re-installing Casper 8.x.:

1. SSH into the RHEL server as my user account.

2. su into the root account on the server by running the following command:

su root

3. Run the following command to get a MySQL prompt:

mysql

4. From the mysql> prompt, run the following command to create a new empty jamfsoftware database for the JSS:

mysql> create database jamfsoftware;

5. Exit out of MySQL with the following command:

mysql> exit;

With the new jamfsoftware database created in MySQL on my test server, I was then ready to reinstall Casper 8.x.