El Capitan: Manually installing the current (9.73) JAMF Framework. Success!

[bradtchapman]

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 jamfAgent

Step 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/bin

Step 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 jamfAgent

Step 4. Create the hidden management account:

sudo jamf createAccount -username casperadmin -realname casperadmin -password YourSecretPassword -admin -hiddenUser

Step 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 JSS

Step 6. Enroll the computer:

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.

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:

[bentoms]

@mm2270 It may still be advisable to put some logic into scripts due to this from @john.miller above:

Most important, the binary is moving. We're moving away from /usr/sbin to /usr/local. This change will apply to all OS X versions OS X 10.7 and later. 10.5 and 10.6 will still stay in /usr/sbin, untouched as with most upgrades.

So if people still have 10.5 or 10.6 the migration that @john.miller mentioned may be detrimental.

[bradtchapman]

If you still have 10.5 and 10.6 machines in your environment, maybe it's time to think about replacing them.

[john_miller]

Hey everyone,

Sorry I didn't respond sooner. To your post, @bentoms ,10.5 and 10.6 machines will be unaffected. And while I'd agree with @bradtchapman about trying to upgrade machines, but I know that there is still a huge demand fro 10.6.8. This is mostly because software required for those organizations hasn't been updated, especially in education settings. So to ensure functionality for folks who can't upgrade, we're leaving the 10.5 and 10.6 stuff in place, no changes to location there. We're continuing on with that and will leave the 10.5 and 10.6 binary in place.

And yeah, as @mm2270 mentioned, the JSS will scan Extension Attributes, Policies "Files and Processes," and migrated scripts for any references to /usr/sbin/jamf. If it's found, the admin gets notified and can then change it. We won't change anything automatically.

I hope that clears it up. Thanks for keeping the discussion going.

[bentoms]

@john.miller Thanks John.

All I was trying to say was that for those with 10.6 & newer they may not want to change via the JSS as it could break their older Macs whilst fixing the newer.

[rtrouton]

For folks who need to support both 10.6.x and lower, as well as 10.7.x and higher, I've written a way to check for the current location of the jamf binary in a script using the function shown below.

# Identify location of jamf binary.

jamf_binary=`/usr/bin/which jamf`

 if [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ ! -e "/usr/local/bin/jamf" ]]; then
    jamf_binary="/usr/sbin/jamf"
 elif [[ "$jamf_binary" == "" ]] && [[ ! -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
    jamf_binary="/usr/local/bin/jamf"
 elif [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
    jamf_binary="/usr/local/bin/jamf"
 fi

In this case, when you wanted to reference the jamf binary in a script that uses this check, you would use $jamf_binary anywhere that you would otherwise reference /usr/sbin/jamf or /usr/local/bin/jamf

To see in context how I'm using this, please see the link below:

https://github.com/rtrouton/CasperCheck/blob/master/script/caspercheck.sh#L222-L241

[donmontalvo]

@bradtchapman wrote:

If you still have 10.5 and 10.6 machines in your environment, maybe it's time to think about replacing them.

There are valid reasons some workstations in some environments need to be at the OS level they are on. One high profile fashion company that shall remain nameless requires 10.5.x to run an application that hasn't been updated in many years, but is still (best effort) supported by third party consultants. When a company makes 7 figures on something that requires an old OS, it may be time to re-think the notion that being on an old OS requires thinking about replacing them. ;) Just my dos centavos.

Dammit @john.miller if you keep this up we're going to run out of beer at JNUC2015! :)

Don

[bpavlov]

@rtrouton I'm stating the obvious perhaps, but if one simply refers to just 'jamf' instead of '/usr/sbin/jamf' then this isn't a problem at all in scripts? Not best practice, but....

[donmontalvo]

Interesting, did Apple just add /Applications/Utilities to the SIP protected list?

See page 5.

[bradtchapman]

"Important: This is a preliminary document for an API or technology in development."

Security configuration is stored in NVRAM, and applies to the entire machine Persists across OS install.

Also, it actually bothers me (on principle) that they've limited the use of dtrace to user processes and applications only; system processes can no longer be monitored this way. So I would have to disable SIP in order to accomplish this. That's going to mess up a few developers who turn off SIP on their machines and forget it's not enabled when testing their code.

[myronjoffe]

I am in the process of planning the upgrade of our JSS from 9.72 to latest 9.8.x

I have manually reviewed all scripts referencing /usr/sbin/jamf
if I substitute the full file path and only have the script contain jamf <verb> will that negate the issue of the "new" Jamf binary locations?

[bradtchapman]

@myronjoffe : It should, and that's what JAMF has recommended for a long time. When upgrading to 9.8, they gave admins a warning about scripts that contained a hardcoded path of /usr/sbin/jamf , and advised them to fix it as those would no longer work.

As long as the PATH environment variable has not been modified from its default, just typing "jamf" is good enough.

[myronjoffe]

@bradtchapman Thanks!