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.
krypted November 16th, 2015
Posted In: Business
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:
Download the Enrollment Profile
To download an enrollment profile from Casper MDM:
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:
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:
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.
krypted August 8th, 2012
Tags: Apple Configurator, automate enrollment, CA, Casper, casper suite, enroll, export certificate, iPad, iPhone, ipod touch, JAMF, JSS, keychain utility, mass enrollment, mdm, mobile device management, trust
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:
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.
krypted July 20th, 2011