The existing complexity of DEP, though, gives us choices. There’s no reason we couldn’t setup multiple MDMs for multiple departments within an organization, allowing central management of assets, and separate management of devices at the department levels, allowing for good competition between MDM vendors in the mid-level of the environment. Having multiple options is good, because it gives us choice, and it avoids obvious anti-trust complaints.
Read the whole thing. Complex shouldn’t be immediately pejorative. Good management can, and almost should be considered a complex task.
Hopefully by now you’re aware of Apple’s Device Enrollment Program (DEP), which allows you to specify a Mobile Device Management (MDM) server for your devices to check in with during their initial setup process. This applies not just to iOS devices, which substantially benefit from enrollment in MDMs, but also to Macs, which traditionally have had fewer benefits.
That has substantially changed in the last few months.
A month ago, the Mac Admins Podcast sat down with Erik Gomez of Pinterest to talk about using MDMs to install Mac applications – including root agents like Puppet, Chef and Munki. Erik designed a workflow — and built some tools himself — to configure those root agents and engage them in a seamless series of actions for onboarding new staff. The goal was simple: fully utilize DEP and MDM to install their management agents and software management scheme, as well as customize the device in a way that their engineers normally would ahead of deployment.
The experience of rolling out new equipment to new staff, or returning staff, can be a whole lot less hands on for IT Admins, and that’s an excited part of this.
This process is going to talk about several different important parts, and I want to lay out what you need to make this work.
DEP Account – This should go without saying, but you need a DEP Account. That involves getting a customer number from Apple, and if you’ve got a retail store near you, their business team can help with this. Please stop and read the Deployment Program Help if you have questions. Please note: It can take more than a week to get this done, so start early.
Developer Account – This process requires that you have a signing certificate that is signed by the Apple Worldwide Developer Relations Certificate Authority. There can be no substitutes, so you’ll need to join the Developer Program. It’s $99, and you should probably already have this anyway.
SimpleMDM Account – SimpleMDM is one of the few MDMs that support the InstallApplication verb in the mdmclient binary for the Mac so far(1). You can try it out for 30 days with no credit card. Devices start at $30/year.
A Web Server – You’re going to need a place to host your signed application packages and a JSON file. It’s best if it has an SSL/TLS Certificate installed and configured for use.
InstallApplications Script – You will need the InstallApplications project from Github. This is the glue that makes everything else possible. InstallApplications is the actual signed package you’ll be installing from the MDM, which will in turn reference the JSON file on your web host, and then process the packages specified therein. This is a great way to stage a bunch of useful content on the machine that can then be called in a coherent process to take the machine from fresh-from-Apple to fresh-from-your-organization.
DEPNotify – There are few things as bad as a process with no interface. Users can grow confused or impatient if expectations are not properly set. DEPNotify is a good way to message to your users what is happening with their brand new computer.
During Setup Assistant, a machine that is registered with DEP will check in with Apple’s Activation Servers, and based on the hardware model identifier and the serial number, be assigned to the MDM that corresponds with its record in the DEP portal. At that time, the MDM in charge of the situation can deploy pre-stage packages during the Setup Assistant.
That’s where this process comes in. You can create and sign the InstallApplications package with your Developer certificate, and then deploy that LaunchDaemon to the machine in a safe method without ever touching it. InstallApplications works by referencing a JSON file that is stored on the internet that provides a series of package URLs, file locations and file checksums for the packages you want to install on the machine before and after the Setup Assistant completes.
The nice thing about InstallApplications is you only need to rebuild the package if the location of the JSON file — or some of the attendant details for how it’s secured — have changed. Ideally you build it once, and then handle the rest via the JSON file. Once you have selected your pre-stage and stage 1 and 2 packages (of which there can be a number of each, you’re not limited to one package per stage), make sure to capture the appropriate checksums with the shasum -a 256 /path/to/your/cool/package.pkg and embed the values appropriately.
As part of our install, we’re dropping in the DEPNotify binary and the munkitools package into the pre-stage, since they don’t require a user session, and then a trigger for DEPNotify that performs the first login tasks during Stage 1. We’re doing our Munki configuration via SimpleMDM’s support for custom profiles, so those settings are already present when our trigger script runs after the first user logs in. Our script, a sample of which is linked here, kicks off the DEPNotify application, and begins to guide the user through what will follow.
I also wrote a second script that is installed as the last thing our Munki server doles out for install. It issues one last command to DEPNotify and then cleans up the log file. You can later create an uninstaller for DEPNotify that cleans up the application.
Sign this package with your Developer ID Certificate.
Upload this to SimpleMDM as a macOS Package and Configure it to be installed in the default group selected in DEP.
Create the referenced JSON file and place it on your Web Server making sure that the security on the directory matches what you’ve specified in step 1.(2)
Upload the packages referenced in the JSON file to your Web Server.
Check to make sure packages download okay.
Write a first-boot script that launches your software installer, and gives DEPNotify the data that it needs to get things going.(3)
Test this with a Virtual Machine(4). Test it again. And again.
And Now, A Video:
This is what it’s like to setup a machine using Simple MDM, InstallApplications, DEPNotify and Munki together in a seamless toolchain:
It took approximately one full day to set all of this up and get it working like I liked, including the creation of this entry and documentation.
(1) the others are ZuluDesk and Airwatch as of the release of this post. I’ll keep this footnote updated as I hear of more.
(2) Right now, InstallApplication.py really does not like redirections, so make sure you’ve specified the correct URL.
(3) This is going to be the part that takes the longest. Building a good post setup experience for your users is going to be an interesting experience, and I think we’re going to see a lot of different takes on it based on the different schools of thought for user-focused deployment. There’s no reason that something like DEPNotify couldn’t be used over a period of hours or days to inculcate institutional culture to new staff. Play with this, It’s going to be interesting.
(4) Testing with a Virtual Machine is easily done. Using Joe Chilcote’s vfuse, create a new VM from an AutoDMG master. Open the .vmwarevm bundle and edit the .vmx file in a text editor (I recommend BBEdit) and add your Serial Number and Model Identifier. Now start your VM and you’ve got a DEP-enabled VM!
This week’s Techno Bits newsletter has a summary of the Broadcom Wi-Fi SOC exploit, some great links from Emily Kausalik and Charles Edge on macOS Sierra’s logging system, and some backstage sneak peeks into Merriweather Post Pavilion’s new stage house and the network that supports it, as well as a thank you to Walt Mossberg for his incredible career in tech journalism.
Congress has decided, for whatever reason they have chosen to represent as to why they’re acting, and frankly, none of them are too well-explained, that your Internet Service Provider can continue building a file on every site that every device on your home and work internet connection visits.
Ostensibly this is for marketing purposes – i.e., to sell those results to third parties who want to buy them in bulk – and it means that the connection that you pay for each month isn’t entirely your own.
This is, as one might imagination, a frustrating betrayal of trust, more so when you consider that we are not blessed with robust competition in most residential marketplaces, and there are few rare ISPs that can afford to stand on moral grounds against this tactic.
It used to be that you could opt out of the “super cookie” Unique Identification Headers (UIDH) that companies like Verizon are already appending to your HTTP Requests.
Yeah, that’s sleazy. They are trying to make you, their customer, more visible to advertising partners based on your existing actions.
Thanks to aggressive lobbying of the Congress, and an abdication of any desire for an individual right to privacy on the part of Legislative and Executive branches, these communications giants are going to take a second turn at squeezing more revenue out of their networks, and they’re going to do it to their customers without so much as a discount for being their unwilling partners in marketing.
Okay, That Sucks, Now What?
So, what’s a person to do if they want to keep their surfing habits – which in many cases contain personally identifying and possibly embarrassing information – away from their ISP’s prying eyes?
There’s an easy way to help prevent their access, and that’s to use a Virtual Private Network, or a VPN. That’s a way of sending all your outbound internet traffic securely to a third party before it passes through to the internet as a whole.
What’s that look like? Think of it this way: imagine that you want to send a secret letter to a friend. You don’t want anyone in your local post office to know that you’re sending a note to John Smith in Des Moines, Iowa, so you pack up your sealed letter to John in a letter to another friend, Betty Johnson of Dubuque, Iowa, with a note to please mail this letter for you from her local post office. The post office sees that you sent a letter to Betty, but because there are rules against opening your mail, they can’t read it. Then, Betty receives your message, posts your letter to John, and no one’s the wiser.
That’s what a VPN does. It’s a secure way to send all your traffic to a third party to act on your behalf. You can securely wrap your traffic to the Internet to a third party before it gets out to the rest of the internet.
It’s not perfect, but it at least prevents some of the skeeviest trends in local ISPs. Drawbacks to using VPNs include weird results for Location searches, a performance hit to your internet speed, and perhaps the inability to view location-specific programming.
I don’t make anything from a referral to them, but I do use their product and endorse it. It’s an easy VPN to setup. Give it a try if you spend a lot of time on unencrypted Wi-Fi, or if you don’t want your ISP to have access to your surfing history.
At least two MDM vendors are going to be supporting the `InstallApplication` verb in the MDM Specification for the Mac. Why does this matter? As Apple encourages the adoption of MDM and DEP together for configuring user machines, the Munki community (and for that matter, the Puppet and Chef community) saw a path forward that didn’t include our favorite open source software installation agent. No longer.
This week’s Techno Bits Newsletter is all about reading the tea leaves, and how the work of Erik Gomez and others is looking promising for leveraging DEP and MDM with existing management systems like Puppet, Chef and Munki. Are we finally seeing the light on the horizon? Could well be.
Thanks very much to the folks at Amsys for having me out to London to present my talk this year at MacADUK, called Munki Mistakes Made Right. Over the last few years, I’ve done probably 25 munki installations, in groups as small as a few clients, or as many as a hundred. There are always challenges in implementing Munki well, especially as the product matures and grows and the ecosystem around it changes to add tools like autopkg, Jamf Pro, and other solutions that can be co-implemented with Munki.
I’ve learned a lot from my implementations, and I want to share that with everyone, that, as the saying goes, that my mistakes may be avoided for future generations of admins. I’ve prepared a few sections of this presentation on various mistakes I’ve made (security mistakes, configuration mistakes, catastrophic mistakes) and how we addressed them in practice. This talk shouldn’t be seen as totally conclusive of all the mistakes that one can make – folks are always coming up with new and creative ways to break things, as well they should – but it’s a good place for me to talk about the ways we’ve been changing our existing environments to make them better, stronger, and faster.
There are some things that I’ve released recently, code-wise, that get callouts in this presentation, and I want to make sure they’re called out clearly here for ease of use:
Munki in a Box 1.5.1
I released Munki in a Box 1.5.1 last week, and it was largely a maintenance release. The following changes should have been expected: by default, Munki in a Box will now setup HTTP Basic Auth set on a password of your choosing. In addition, it’s designed to be used with an HTTPS-native server, which you should be using anyway. The old security branch, which 1.5.0 was based on was something that walked that line, but it was time to fold that branch back in. So I did.
In addition, MIAB 1.5.1 now creates local overrides for all the autopkg recipes that are specified in the initial command variable, to better handle the trust package portion of autopkg.
Change Munki, Tell Slack
As part of the talk, I’m going to explain why a configuration manager or Mac-capable MDM is your best friend, but facing a lack of those for budgetary or administrative reasons, I’m going to give you a tool to deploy changes to your fleet in reportable ways.
Both will handle a scripted change of your Munki preferences file and pass that information along to a Slack channel of your choosing via a webhook.
Slides & Notes
I’m making my slides and presenters notes available as a PDF for Download, in case you might enjoy it. If you have comments on the scripts above, please let me know, or suggestions for converting them to python, both are welcome.
When a consultant friend (Hi M!) asked what I carried with me every day, it was the first time that I’d stopped to think of everything I’ve collected over the years to carry with me on a day-to-day basis. Based on their challenge, I’ve catalogued what’s in my daily carry bag, and I present it here for you.
First up, the bag itself. I have a 2013 Timbuk2 custom messenger bag. Timbuk2 bags have two specific problems: One, they’re gorgeously designed and Two, they last forever. I’ve had a total of four since 1996, and I’ve never needed to buy a new one, I just always wanted to change up my style before the bag gave out. Better still, they have lifetime warranties, so if a part gives out, you can ship back your bag and they’ll shine it up good as new. They’re not inexpensive, but the features of the bag are substantial, and the design is wonderful. My messenger has a flap organizer in the front fascia, as well as multiple zip pockets for business cards, baseball cards, your passport, and other flat goods. The flap organizer is my catchall for small tools and keychains that I tote with me all the time.
From a hardware perspective, I carry the following:
Late 2016 MacBook Pro 15” with TouchBar, 1TB, 16GB
iPad Pro 12.9” with Apple Pencil
iPhone 7 Plus (Matte Black)
The MacBook Pro and iPad ride back to back in the padded laptop sleeve in the center of the bag, and the iPad behind in the protected position.
Inside my bag itself I have a couple of organizers that serve as containers for primary work tasks, and they keep the contents protected and clearly identified and organized in case I need them. The bigger of the organizers is a Skooba Cable Stable DLX, with multiple mesh pockets to allow easy visibility into the contents, and elastic tension loops to hold the contents in place.
Contents, Left Side:
Mini DisplayPort to DVI Adapter
USB-C to Lightning cable – 2-meter
USB-C to USB-C charging cable – 2-meter
27W USB-C Charger
Diskwarrior USB Drive
OWC Envoy Pro Mini USB Drive
Contents, Right Side:
Lightning to 3.5mm adapter
Paracord USB-A to Lightning Cable
Thunderbolt 2 to Gigabit Ethernet Adapters (2)
USB-A to USB Micro Cable – 6-inch
Netool Smart Network Terminal
USB-C to Lightning Cable – 2-meter
Belkin USB-C to Gigabit Ethernet Adapter (2)
Thunderbolt 3 to Thunderbolt 2 Adapter
Contents, Center Spine Loops:
USB-C to USB-A Adapters (2)
I don’t have a lot of notes on this set, except to say that extras are always welcome, especially when you think about all the times your clients need something, and you just supply it out of clean blue air, and replace it later.
In addition to my primary organizer, I also keep a smaller Cable Stable Mini outfitted with my SpecAn gear. This includes a full Metageek set, including a WiSpy DBx for peeking at the 2.4 and 5 Ghz spectrum in their entirety, as well as a Linksys AE2500 USB WiFi stick for use with Channelyzer in my Windows VM (Windows VMs on the Mac can’t talk too the AirPort interfaces, we just get a raw network socket, so this is our workaround) as well as the USB-A to USB Mini interface. In the pocket I keep the antenna and hook. Sometimes I throw the Oscium Lightning-based SpecAn in this as well, but most times it’s loose in the pocket.
And then there’s everything else! This list starts at the upper left corner and works clockwise:
Thunderbolt 2 cable, 2-meter
Field Notes notebook
USB 3 SANdisk Extreme
Code 42 branded microfiber cloth
OLALA 13000mAh battery
PSUMA-branded 4000mAh backup battery
sticky-backed velcro strips
RJ-11 and RJ-45 jack ends
Sugru moldable plastic
Pentalobe and Tri-wing screwdrivers
Gotenna bluetooth radio for texting when there’s no cell service
That’s a look inside my daily carry. It’s pretty amazing how much stuff I tote around on a daily basis.
Ubiquiti Networks are designed to work with a controller of some kind. This can be a downloaded application that runs on a computer you already have, or be configured to run on an Amazon Web Services t2.micro instance (free for a year, $150/yr after that), but the easiest way to have a small dedicated appliance that’s ready to go at the first moment is the CloudKey, a small appliance, slightly longer, but slightly narrower, than a Raspberry Pi.
The CloudKey is your dedicated controller for your network, be it just an AP, or an AP and a switch, or a couple APs, a switch or two, and a security gateway.
Since Amazon is the world’s most efficient shipping operation, everything showed up in one medium-sized box. The Cloud Key and the PRO AC each come with (almost) everything you need to make this all go.
UAC Pro AP
This is almost everything you need to make a go of it. What’s missing? Well, if you lack a POE switch, you need a 5V/1A Micro USB power source for the CloudKey. And, for the UAC Pro, you’re going to need one Ethernet cable if you have a POE switch, and two if you just have a standard switch. So, plan ahead, and if you’re not using a POE switch, stock your supply kit accordingly.
Setup is a two-part process: CloudKey first, then Network.
Open the box, and you’ll see there’s three things in there, save the manual: The appliance itself, a stubby 6″ Ethernet cable, and a Micro SD card.
Slide the Micro SD card into the rear of the device, taking careful note of the pictogram on the device to line it up properly. Once you’ve got the card in place, plug in the ethernet cable to the device, then into your switch. If you’re flying without a POE switch, plug in the Micro USB cable.
This will boot the device, and you’ll see a white light on the center of the CloudKey as it starts up.
The next step requires access to your router, or the installation of their Device Discovery Tool. Once you’ve determined the IP address of your CloudKey, visit that address in a browser. They recommend Google Chrome, or Mozilla Firefox, but my experience says Safari for macOS and iOS both work just fine.
This is the initial screen for the CloudKey. We’re going to start on the bottom half, Configure Your UniFi CloudKey.
The CloudKey will walk you through initial setup. You login with the ubnt : root combination of username and password, and it will take you through the rest of the easy steps where you set your locality, an administrator password, and the rest. Once you’ve gotten to the main interface, you’ll want to check to make sure that your CloudKey is up to date. Mine shipped with 0.4.3, and 0.5.5 is current as of the authoring of this post.
I found that once I upgraded the firmware, I still got a “Hey, turn the device back on!” message, for the first two refreshes of the admin page. That did go away eventually.
Ubiquiti Network Setup
Once you’ve got a password for the CloudKey and it’s been setup and provisioned, it’s time to start working on the network itself. Plugin the UAC Pro if you haven’t already, and make sure the LED in the main ring activates.
Go back to the CloudKey address, and this time, instead of setting up the CloudKey, you’re going to want to setup the Network itself, the top option.
First up, Location & Timezone. This one’s easy.
You’ll now see the UAC Pro and you’ll want to continue. Check the box next to your AP, and click Next.
Here’s where you setup your initial network name (the Secure SSID) and password (the Security Key) for your Wi-Fi network.
Then setup your Controller username (different from the CloudKey admin!) and password.
Last up, you have to setup your Ubiquiti account. If you haven’t yet, you can setup a Ubiquiti account before starting, otherwise, it’ll guide you through that process as well. This is what you can tie your whole chain together with – Security Appliance, Switches, APs and CloudKey.
That’s the basics of the wireless network configuration. There’s more control available, though. By default, the UAC Pro uses 20MHz channels in 2.4GHz and 40MHz channels in 5GHz. The sidebar of the main controller view will let you alter the radio controls of the APs. Select the Device, and click the Configuration heading.
Here, you can select the channelization of each radio, as well as the channel width and broadcasting power. You can enforce Airtime Fairness, if you’re worried about device dominance, or use Band Steering to force your devices to use 5GHz as much as possible. You can also configure your device’s IP information here, give the AP a specific name.
You can also setup basic maps of your APs using the Maps section and blueprints of your space. This will, if you have multiple APs, let you triangulate the location of devices, as well as map coverage areas and guesstimate signal strengths based on readings from each location. While no substitute for a proper survey, it’s a pretty good guess for getting started.
Next time: Setting up the Security Appliance and integrating the two.
Today, Bloomberg Technology News released a story that heralded the death of one of my favorite products over the years, the AirPort. It is one of the few products currently available at Apple that predates my career as an Apple Admin(1). Over the years, we’ve seen a lot of features crammed into these little boxes, and I have a tremendous fondness for them overall.
My thanks to Apple for building a good, solid little box that did so much. I’ve got some recommendations that I’ve been thinking about for some time, along a couple different lines of thought:
I have yet to find a device that I like more than the current AirPort Express, just in terms of what it does: Home Router, Home Wi-Fi, AirPlay speaker, remotely managed. There isn’t anything I’ve found that is as easily-managed as the AirPort line is. But there are some good options:
Archer C7 (<$99) – 802.11ac, 3×3:3, USB Port for basic NAS
* The UI doesn’t totally blow
* Good performance for throughput
* Good coverage for 5GHz for single-floor, drywall construction dwellings
* Not great at density
* Not very useful just as an access point
* NAS performance very limited.
* Synology UI that you like from your NAS
* Beamforming Support to alter coverage areas
* Good performance for throughput
* No USB for direct storage, meant to be used with an existing Synology NAS
In the early days of Wi-Fi, Wireless Distribution System (WDS) was an extension of 802.11g that would allow you to use Wi-Fi access points as wireless relays to expand coverage. I wrote a piece for an early edition of Make Magazine on how it works, and it’s been something we’ve used various places over the years, but mostly only when we’ve had to. Each wireless link in the chain can halve your bandwidth, and clog the airwaves. It’s a last ditch effort.
Or, it was, until some new players like eero and Luma started to dip their toe in the proprietary Wi-Fi world, and brought legacy companies like Netgear to the fight. Neither eero nor Luma carry Wi-Fi Alliance certification, but I don’t think that should be the end-all, be-all of the world. I’ve recommended both eero and Luma to clients, and some have adopted it. There are some interesting choices that they’ve made, and there are some consequences to that. Overall, these technologies share the same Pros & Cons:
* No wires required!
* iOS App Setup
* Interesting features not found in other platforms
* Works as a Router solution
* less configurable radios
* proprietary is harder to troubleshoot
* wireless backhaul is still problematic for throughput
There are a couple of good options from the big providers of Wi-Fi for home use, too. They’re a step up in cost, but they come with a good step up in performance, too. These are all pure access points, though, they’re not routers, and they don’t have router-like options. This is all about the best Wi-Fi you can build, not AirPlay, not Routing, not remote management.
UniFi and Xclaim are the two that I see most often, and both represent good values. Xclaim is the budget line from Ruckus, and is meant to be cloud-controlled. It is equivalent to the R300 and R500, but without the 6dB of interference mitigation or any of the beamforming that make their APs my go-to on the Pro side. The UniFi APs from Ubiquiti are solid performers, but don’t carry the interference mitigation a large urban environment may require.
* Good value APs
* Works with a local Cloud Key controller or AWS t1 micro instance
* Supports multiple SSIDs and controls
* Interference mitigation is a problem in dense environments
* 802.11n AP susceptible to hardware failure after 2 years
* UAP-PRO is only 2×2:2
* UAP-AC is almost $300.
* Needs either a Cloud Key or an AWS instance for best management.
The end of the AirPort is a sad day for me, I’ve probably managed close to 100 of them for clients in the last ten years, and I know we are currently supporting 25 of them in daily use. I don’t think there’s a good AirPlay option out there to replace them, sadly, so if that’s your current favorite streaming audio technology, now would be a good time to stock up on extras.
AirPort was a groundbreaking technology when it was released, and the first AirPort-capable Macs were magical in a way that we take for granted now. When people ask me what my favorite miracle of modern technology is, I reply without hesitation: Wi-Fi. Apple lead the way for a long time, focusing on building consumer-friendly products that did a lot. None of the solutions above carry with it the user-friendly function-focus of the AirPort, and that makes me sad. But, new companies like eero and Luma are making wireless do things that Apple has decided not to do, and so the future lives with them, or with the professional access point manufacturers who work down market like UniFi and Xclaim (Ruckus). I think we’re in good hands, even if they’re not Apple’s.
(1) The portables have all changed names, the mini, iPod, iPhone and iPad didn’t exist, the PowerMacs became the Mac Pro, only the AirPort and the iMac carry their original monikers. Crazy, right?