Greetings, and welcome to the Caspert Report. Nation:
The hive mind of the JAMF Nation collective has uncovered a dirty secret: the current public release of the Casper Suite cannot enroll a Mac running OS X 10.11 ("The Captain"). And even though the software-pirating teenager next door (who likes to dress up as a Pokémon for Halloween) says he runs beta software because it's so edgy, most adults know better than that. But enough about what "the authority" says! I listen with my GUT, and being the freedom-loving, won't-take-no-for-an-answer kind of Mac guy that I am, I salute Mr. Pimplestiltsteen and kids like him everywhere for sticking it to the man.
OK enough of that silliness. I miss Stephen Colbert and can't wait to see him on the Late Show.
So... before I go signing up for the Casper Public Beta program, I wanted to see if there was a way to get a 10.11 Mac to run the binaries, get enrolled, and enforce some policies. I managed to do just that, and my notes are published below. As I discovered late in the process, the jamf binaries have hard coded values for the executable path, so the .plist files will always get the wrong information and have to be modified post-enrollment.
(The test machine is a MacBookPro9,1 (Non-retina 15", 2.3GHz Core i7), which I am using to type this post. It's running OS X 10.11 Developer Beta 4 (15A226f) and is enrolled on a dev JSS, checking in every 5 minutes. Several test policies have worked as expected).
One of the folders that is restricted by the new operating system is /usr/sbin, which is the install path of the current public release (9.73) of the JAMF Framework. Asking customers to turn off the new System Integrity Protection feature is not up for discussion.
So, where will the binaries go?
As has been pointed out by others on JAMFNation, /usr/local/bin is a good candidate because it's already in the default "path" export variable for every Mac, and it's not in the "restricted" folder list for the new security system.
As a newly-minted CCT and a long-time Mac analyst, I wanted a little challenge for myself. So I figured out how to install it manually, and it seems to be working just fine. This whole process can be semi-automated with ARD and a little scripting, if desired. SSH (Remote Login) must already be enabled for this to work.
Step 1. Pack up the jamf binaries on the source computer:
Copy the two binaries from a working computer. I recommend using tar in this manner to preserve the ownership and permissions, but not the absolute path:
sudo tar -czf jamf.tar -C /usr/sbin/ jamf jamfAgentStep 2. Create the /usr/local/bin folder and unpack the binaries on the destination computer:
sudo mkdir /usr/local/bin
sudo tar -xf jamf.tar -C /usr/local/binStep 3. Verify Ownership / Permissions of the jamf binaries:
List the contents of the /usr/local/bin folder and verify ownership and permissions of the jamf binaries. It should be owned by root:wheel, with 555 for jamf, and 6755 for jamfAgent (6755 is setuid & setguid to owner when executing, rwx user, rx group, rx others). If these are not correct, change them immediately using chown and chmod.
ls -l /usr/local/bin/
-r-xr-x--x 1 root wheel 4194560 Jul 28 20:25 jamf
-rwsr-sr-x@ 1 root wheel 415392 Jul 28 20:25 jamfAgentStep 4. Create the hidden management account:
sudo jamf createAccount -username casperadmin -realname casperadmin -password YourSecretPassword -admin -hiddenUserStep 5. Create the jamf configuration file (.plist):
sudo jamf -createConf -url https://server.jamfcloud.com // cloud JSS instance
- OR -
sudo jamf -createConf -server jss.company.lan // primary internal JSSStep 6. Enroll the computer:
sudo jamf enroll -promptFor #6, you will be asked for the following accounts:
JSS Username & Password = any account with enroll privileges
SSH Username & Password = hidden management account from Step #4.
(Actually, I don't know if this step can really be automated because of the user interaction required.)
There will be an error at the end of the process:
Checking for policies triggered by enrollmentComplete
There was an error.
*** --NSConcreteTask terminationStatus]: task not launchedUnfortunately the policy task will fail to launch because the LaunchAgent and LaunchDaemons are configured to point to non-existant JAMF binaries at /usr/sbin/. It must be corrected or else the services will fail to launch, and your JSS will be a sad panda because the computer will never check in.
Step 7. Edit .plist files
Use Terminal to sudo edit three files used by the JAMF Framework, replacing the string /usr/sbin/ with /usr/local/bin/ wherever it is found:
- /Library/LaunchAgents/com.jamfsoftware.jamf.agent.plist
- /Library/LaunchDaemons/com.jamfsoftware.jamf.daemon.plist
- /Library/LaunchDaemons/com.jamfsoftware.task.1.plist
Step 8: Reboot computer.
Once the computer has rebooted, it will check itself in at the pre-determined interval. Or you can do it manually, but I preferred to wait to ensure it actually worked on its own.
If this works for you, please comment.
Here's a screenshot of the computer record from within the JSS:
Just my dos centavos.