In a Tango class recently, I had to follow. I’m much more used to leading, and I kept bumping into people. Not my best moment. But then my instructor said something that turned out to be very wise advice: “close your eyes.” All of a sudden, everything just kicked into place and I was on the other side of a Tango dance, easily imagining how legs can get kicked out and intertwined and how the whole thing just works. It also helped me lead better. I finally understood that you have to be forcefully charging ahead, or you mess up the rhythm of the follower.
The same can be true in business. I used to find that new employees at my old company always had 20 things to tell us that we should be doing better. Most of these things had been tried, or deprecated over time. Many employees came from smaller companies who didn’t need checks, balances, and documentation like we did. Many came from larger companies, who needed a lot of those same checks, balances, and documentation that we did not. Building business processes can be a fine line between not having enough process, and having so much that people can’t get anything done any more, because there aren’t dedicated people (or time for) managing those processes.
The recommendations were sometimes good. But most of the time, after a month or three on staff, the reasons we did things started to make sense and the number of recommendations went down. But those first couple of months could be a challenge, and so when I saw this trend with a new employee I’d always just say “write everything down, and we’ll review it in a couple months – just try it our way for now.”
Once I got into the rhythm of following, I was able to open my eyes. Then, I could show off. Similarly, once my employees got into the rhythm of things, then we could look at their recommendations and see what would make sense for their new job. Some of these recommendations helped to shape the way we did business moving forward, and we were so very glad to have them. But what was gone was all the time spent trying to explain why we chose to do things a certain way. Much simpler for all parties when you can close your eyes and follow, if only for a little while.
Enrolling iPads into the JAMF Casper MDM solution is done through Apple Configurator, messages or using links deployed to iOS devices as web clips. When doing larger deployments the enrollment process can be automated so that devices are automatically enrolled into Casper MDM when they are set up using an Enrollment Profile that is manually downloaded from Casper and deployed to device. Additionally, a certificate can be needed if the certificate is not included in the profile, an option available as a checkbox in the setup. While you hopefully won’t need to download the certificate, we’ll start there:
Obtain the Certificate for the JSS Server
To obtain the trust certificate from the JSS Server:
Open the web interface for the JSS.
When prompted to trust the certificate, click on the disclosure triangle and then the checkbox to trust the cert, providing the administrative credentials when prompted.
Open Keychain Utility.
Click in the search field.
Search for JSS.
Control-click on the name of your server’s “Built-in Certificate Authority” entry.
Choose the option to Export.
When prompted, provide a name for the certificate in the Save As fiel.
Choose a location to save the certificate to using the Where field.
The .cer format is sufficient for our purposes.
Download the Enrollment Profile
To download an enrollment profile from Casper MDM:
Log into the web interface of the JSS.
Click on the link for Mobile Device Enrollment
At the Mobile Device Enrollment Invitations screen, click on the Enrollment Profiles tab.
At the Enrollment Profiles screen, click on Download for the appropriate profile (for most environments there should only be one)
Once the profile is downloaded, it will automatically attempt to enroll the computer you are downloading it from in the Profiles System Preferences pane.
Click on Cancel.
Click on the downloads link in Safari.
Click on the magnifying glass icon to see the .mobileconfig file.
You have now downloaded the .mobileconfig file that will enroll devices into Casper MDM.
Add the Profile To Apple Configurator:
To deploy the profile through Apple Configurator:
Open Apple Configurator on the client computer.
Click on Prepare in the row of icons along the top of the screen.
Drag the profile (by default currently called MDM-iOS5.mobileconfig) from the Finder into the list of Profiles.
The profile then appears in Apple Configurator (in this example, called MDM-iOS5).
Deploy The Casper MDM Enrollment Profile Through Apple Configurator
Once the profile is installed in Apple Configurator, let’s deploy it. In this example, don’t configure any other options. To deploy:
Set the name to be blank, numbering should be disabled, Supervision should be off, iOS should be set to No Change, “Erase before installing” should be unchecked, Don’t Restore Backup should be set in the Restore field.
Check the box for the newly added profile (MDM-iOS5 in this example).
Click on the Prepare button.
At the “Are you sure you want to apply these settings to all USB-connected devices?” screen, click on the Apply button.
The subsequent screen shows when devices are being configured. Here, dock the device to receive the profile (note, all docked iOS devices are going to be configured with this profile).
Once the device is connected, the profile will begin to install. You are then prompted to “Tap device to install profile”.
On the device, tap on the Install button.
At the Warning screen, tap Install.
Once the Profile is installed, tap Done.
You have now been enrolled.
If you then wish to unenroll, simply remove the profiles by tapping on profiles and then tapping on the Remove button. Per the MDM API, a user can elect to remove their device from management at any point, so expect this will happen occasionally, even if only by accident.
In a couple of previous articles I looked at automating the Application Layer Firewall in OS X. These are pretty common articles that get back-linked to the site, so I decided to update them earlier, rather than later, in the Lion release. The tools to automate firewall events from the command line are still stored in /usr/libexec/ApplicationFirewall. And you will still use socketfilterfw there for much of the heavy lifting. However, now there are much more helpful and functional options in socketfilterfw that will allow you to more easily script the firewall.
Some tricks I’ve picked up with alf scripting:
Configure the firewall fully before turning it on (especially if you’re doing so through something like Casper or Absolute Manage where you might kick yourself out of your session otherwise).
Whatever you do, you can always reset things back to defaults by removing com.apple.alf.plist file from /Library/Preferences replacing it /usr/libexec/ApplicationFirewall/com.apple.alf.plist.
Configure global settings, then per-application settings
To debug: “/usr/libexec/ApplicationFirewall/socketfilterfw -d”
In /usr/libexec/ApplicationFirewall is the Firewall command, the binary of the actual application layer firewall and socketfilterfw, which configures the firewall. To configure the firewall to block all incoming traffic:
/usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on
A couple of global options that can be set. Stealth Mode:
/usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on
/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingmode on
To start the firewall:
/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on
While it would be nice to think that that was going to be everything for everyone, it just so happens that some environments actually need to allow traffic. Therefore, traffic can be allowed per signed binary. To allow signed applications:
/usr/libexec/ApplicationFirewall/socketfilterfw --setallowsigned on
This will allow all TRUSTEDAPPS. The –listapps option shows the status of each filtered application:
This shows the number of exceptions, explicitly allowed apps and signed exceptions as well as process names and allowed app statuses. There is also a list of TRUSTEDAPPS, which will initially be populated by Apple tools with sharing capabilities (e.g. httpd & smbd). If you are enabling the firewall using a script, first sign your applications that need to allow sharing but are not in the TRUSTEDAPPS section by using the -s option along with the application binary (not the .app bundle):
/usr/libexec/ApplicationFirewall/socketfilterfw -s /Applications/MyApp.app/Contents/MacOS/myapp
Once signed, verify the signature:
/usr/libexec/ApplicationFirewall/socketfilterfw -v /Applications/MyApp.app/Contents/MacOS/myapp
Once signed, trust the application using the –add option:
/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/MyApp.app/Contents/MacOS/myapp
To see a list of trusted applications. You can do so by using the -l option as follows:
If, in the course of your testing, you determine the firewall just isn’t for you, disable it:
/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off
Or to manually stop it using launchctl (should start again with a reboot):
launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist
If you disable the firewalll using launchctl, you may need to restart services for them to work again.