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... 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.
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 jamfAgent
sudo mkdir /usr/local/bin sudo tar -xf jamf.tar -C /usr/local/bin
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 jamfAgent
sudo jamf createAccount -username casperadmin -realname casperadmin -password YourSecretPassword -admin -hiddenUser
sudo jamf -createConf -url https://server.jamfcloud.com // cloud JSS instance - OR - sudo jamf -createConf -server jss.company.lan // primary internal JSS
sudo jamf enroll -prompt
For #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 launched
Unfortunately 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.
Use Terminal to edit three files used by the JAMF Framework, replacing the string /usr/sbin/ with /usr/local/bin/ wherever it is found:
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:
Things seem to work, however, a manual recon gives this error:
-[NSError init] called; this results in an invalid NSError instance. It will raise an exception in a future release. Please call errorWithDomain:code:userInfo: or initWithDomain:code:userInfo:. This message shown only once.
the binaries do their job however for as far as I can see...
@bradtchapman , I added an app on the Mac and after a manual recon it showed up, then I deleted the app and re-ran recon and it was gone. Seems that works fine now. Now I'll keep on testing some other functionality.
EDIT: I checked a script to run a firefox installer and then removed firefox. ran jamf policy and that works too...
This is great. I wanted to let everyone know what they can expect from the Casper Suite, as well.
As mentioned, El Capitan introduces some great security features impacting what can write to specific areas of the file system. The Casper Suite is certainly affected, and the binary has had to move. Here's a gist of what you can expect from the Casper Suite. I hope this will help everyone plan their work and preparation for El Capitan.
We're excited to get this out to give folks time to address their needs and prepare for El Capitan. We're looking to get this out in the next public beta. Until then, the workflows described here are helpful to get some testing in place and see what impacts you may experience. The beta will be a great indicator, as well, and will help folks prepare.
Specifically, the JSS will scan migrated scripts, extension attributes, and any policies called to Execute Commands in the Files and Processes payload. On upgrade, the JSS will search for "/usr/sbin/jamf" and notify Full Admins of changes they may need to make.
This is amazing. Thank you.
As a follow-up to @john.miller's news, an updated version of CasperCheck is now available which can handle both the current and future locations of the jamf binary. I have a post on this available here:
Well, yeah, we will all have some work to do if we've been specifically referencing the jamf binary in scripts by the full path (hooray for the scripts that just call 'jamf' without any path)
But I personally think its awesome that the JSS upgrade will help you identify any scripts using the full older path so we can correct them. That should save a significant amount of headaches. That's the kind of stuff I like to hear! Thanks to @john.miller for chiming in on this thread and letting us know where things are headed!
I hope @john.miller just made a typo and the jamf binary will be not really in /usr/local/jamf. This would be very uncommon. The correct path should be /usr/local/sbin/jamf. @spotmac already started a discussion about this issue here:
Hey @roiegat , did you ever figure out a way to package / automate setting up the binaries on an El Capitan machine?
I discovered a new flag in the 'sed' command today: -i . It stands for "inside" or "in-place" and will tell sed to do a search-and-replace within the target file(s). It supports wildcards like *jamf* but for safety I am writing them out one at a time:
sudo sed -i .bak 's//usr/sbin//usr/local/bin/g' /Library/LaunchAgents/com.jamfsoftware.jamf.agent.plist sudo sed -i .bak 's//usr/sbin//usr/local/bin/g' /Library/LaunchDaemons/com.jamfsoftware.jamf.daemon.plist sudo sed -i .bak 's//usr/sbin//usr/local/bin/g' /Library/LaunchDaemons/com.jamfsoftware.task.1.plist
For those of you who are wondering what's going on in the greentext:
's/ // sed commands always open with a single quote; this signifies the start of the search and replace function /usr/sbin // the search pattern; the backslashes are required to explicitly use forward slashes because... / // is a special separator between the search pattern and the replacement section, or "hold space." /usr/local/bin // the "hold space" or replacement pattern. /g' // tells sed to replace the pattern with the replacement, and closes the statement with a single tick.
If you ever find yourself having to write or modify a script, for the love of all that is holy, do not use TextEdit, even in Plain Text mode. OS X added a new feature in Lion or Mountain Lion that will replace single ticks and double quotes with prettier, typographical versions of the same thing. These typographical alternates are NOT recognized in Unix as equivalent characters; in fact, they are seen as Unicode (non-ASCII) characters. These mistakes have fouled up plenty of scripts, and there are lots of posts on JAMFNation about it. You should invest in something like BBEdit or TextWrangler, or use vi or nano on the command line.
@bradtchapman Not yet. I basically wanted to test all our current components on El Capitan and see what I would need to start working with vendors on. Nicely enough things all work in the current state (except Casper). Were in a middle of the update here so not much free time to play on this.
I did find that when a machine is bound to AD and locked, it sometimes won't let me unlock the screen. Sometimes it acts like it doesn't have a local account when I try to log in offline as well. But I'm sure it's early El Capitan issues.
I re-enrolled one of my test machines on a different dev server this week.
First I ran sudo jamf createConf -url https://mynewserver.jamfcloud.com
Then I ran sudo jamf enroll -prompt and supplied the JSS & SSH credentials. No problem there.
That's when I noticed a message during the policy check:
mbp15test:Preferences macuser$ sudo jamf policy Checking for policies triggered by "recurring check-in" ... Upgrading jamf binary... The management framework will be enforced as soon as all policies are done executing. Upgrading jamf agent... Upgrading jamfHelper.app... Upgrading JAMF notification service... Upgrading Self Service.app... Executing Policy Update Inventory... Running Recon... Retrieving inventory preferences from https://mynewserver.jamfcloud.com/...
Hmm, that's weird. "Upgrading jamf binary?" The current version is just going to try to put it in /usr/sbin , but that's going to fail because System Integrity Protection is enabled.
Or so I thought...
mbp15beta:sbin macuser$ ls -la /usr/sbin/jamf* -r-xr-x--x 1 root wheel 4194560 Aug 11 13:11 /usr/sbin/jamf -rwsr-sr-x 1 root wheel 415392 Aug 11 13:11 /usr/sbin/jamfAgent mbp15beta:sbin macuser$ ls -la /usr/local/bin/jamf* -r-xr-x--x 1 root wheel 4194560 Jul 28 20:25 /usr/local/bin/jamf -rwsr-sr-x@ 1 root wheel 415392 Jul 28 20:25 /usr/local/bin/jamfAgent mbp15beta:sbin macuser$
So...how did JAMF manage to install the latest binaries in /usr/sbin if this folder is restricted??
Running El Capitan Public Beta 5 now (15A262e), and the jamf binary still had permission to update itself at /usr/sbin. I speculate that Apple might let this get into the Golden Master.
Checking for policies triggered by "recurring check-in"... Upgrading jamf binary... The management framework will be enforced as soon as all policies are done executing. Executing Policy Update Inventory... Running Recon... . . . Locating hardware information (Mac OS X 10.11.0)... Gathering application usage information... Submitting data to https://myjss.jamfcloud.com/... <computer_id>17</computer_id> 2015-08-31 22:27:14.455 jamf[11519:174986] -[NSError init] called; this results in an invalid NSError instance. It will raise an exception in a future release. Please call errorWithDomain:code:userInfo: or initWithDomain:code:userInfo:. This message shown only once. Submitting log to https://myjss.jamfcloud.com/ mbp15beta:sbin macuser$ ls -la /usr/sbin/jamf* -r-xr-x--x 1 root wheel 4194560 Aug 31 22:26 /usr/sbin/jamf -rwxr-xr-x 1 root wheel 415392 Aug 11 13:11 /usr/sbin/jamfAgent mbp15beta:sbin macuser$ /usr/sbin/jamf version version=9.73.1438183906.c
I've discovered that the exception isn't exactly undocumented. If you look at this file:
It is a rather extensive list of binaries and libraries that appear to be exempted for compatibility's sake.
The file was last modified on August 10th, 2015.
The following is an excerpt:
/usr/lib/libwkextmac.dylib /usr/lib/pkgconfig/gutenprint.pc /usr/libexec/aksusbd /usr/libexec/com.matrox.vpg.Agent /usr/libexec/com.matrox.vpg.MaxAgent /usr/libexec/cups/backend/cifs /usr/libexec/hasplmd /usr/netvault /usr/sbin/AELWriter /usr/sbin/cups-genppd.5.2 /usr/sbin/cups-genppdupdate /usr/sbin/fsctl_ufsd /usr/sbin/jamf /usr/sbin/jamfAgent /usr/sbin/nipalsm /usr/sbin/nmnetmgrd /usr/sbin/nmnetmgrd_launchd /usr/sbin/nmnetmgrd_launchd_MT /usr/sbin/palModuleMgr.sh /usr/sbin/proxyhelper /usr/sbin/qmasterca /usr/sbin/qmasterd /usr/sbin/qmasterprefs /usr/sbin/qmasterqd /usr/sbin/rpc.net
Some interesting items in
/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths. The full list as of 10.11 Developer Beta 8 is available from here:
Those are my scripts. While it should work to download them all, I would hold on doing anything on this just yet. From the above, it sounds like JAMF may not even need to update the jamf binary location, if the exceptions Apple has in the latest beta builds holds true for the final version.
Even if they do need to move them, @john.miller specifically mentioned that JAMF is looking at a way to have the JSS scan your scripts after being upgraded, and build a list for you on ones that are using the explicit binary path (/usr/sbin/jamf) so you can update them.
I don't mind if you want to use my scripts, but I just hope no-one is doing any unnecessary work this early in the game.