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.
- Click Save.
- 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.
- 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).
- 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.
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”
/usr/libexec/ApplicationFirewall/socketfilterfw --setblockall onA couple of global options that can be set. Stealth Mode:
/usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode onFirewall logging:
/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingmode onTo start the firewall:
/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate onWhile 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 onThis will allow all TRUSTEDAPPS. The –listapps option shows the status of each filtered application:
/usr/libexec/ApplicationFirewall/socketfilterfw --listappsThis 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/myappOnce signed, verify the signature:
/usr/libexec/ApplicationFirewall/socketfilterfw -v /Applications/MyApp.app/Contents/MacOS/myappOnce signed, trust the application using the –add option:
/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/MyApp.app/Contents/MacOS/myappTo see a list of trusted applications. You can do so by using the -l option as follows:
/usr/libexec/ApplicationFirewall/socketfilterfw -lIf, in the course of your testing, you determine the firewall just isn’t for you, disable it:
/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate offOr 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.plistIf you disable the firewalll using launchctl, you may need to restart services for them to work again.