The the past four and a half years I’ve worked on a rapidly expanding fleet, in a very fast moving environment. In that time, I’ve developed a pragmatic approach to security. Standard users do not increase security I used to think standard users were good for security - even at one point calling them essential. Users couldn’t make changes to their devices, which meant that everything was supposed to be in my desired state. In reality what happens is an annoyed user wants to do something and they call the help desk. Eager to unblock the user, the help desk person shoves the admin password in without many (or often, any) questions. ...

Our bootstrap tool is written in Go, and as of the time I’m writing this, Go doesn’t support building for Apple Silicon Macs. As such, we need to ensure Rosetta 2 is installed for our enrollment process to work. The only problem I had was that we only wanted to run this on Apple Silicon devices - obviously Intel Macs don’t need this. I learned about /usr/bin/arch this morning, which led to the script below: ...

This weekend I was browsing LinkedIn and I saw an article linked to in Computerworld about how Apple’s new A14 chip would be amazing for enterprise. My initial reaction was surprise, since most enterprises couldn’t care less about the CPU in the device. Of course, battery gains will be welcomed by end users. Improved performance would be nice, but the majority of user’s entire computing experience is their web browser, so local performance for a huge number of people is becoming less relevant. But Apple Silicon will bring in other changes that will (at least initially) introduce new challenges for the use of macOS in the enterprise. ...

First off, let’s talk about the elephant in the room: most endpoint engineers do not get on with their security team. You will often hear complaints like Our security team wants us to deploy terrible product X. Product X is destroying our CPUs / causing kernel panics. Security has no idea what they’re doing. Let’s see how we can overcome these issues and work more closely with our security team. ...

macOS 11 has brought two, small on their own, but significant changes to how we are able to manage macOS. Today we’ll talk about the first: Profiles. Background Back in macOS 10.11 El Capitan, Apple introduced System Integrity Protection. This was the first time the root user wasn’t able to do whatever it wanted on macOS - certain files and directories could only be modified by Apple blessed methods (or by disabling or bypassing the protection, but I digress). ...

For Mac admins using Python to perform scripting duties, the impending departure of Python 2 from the default install of macOS should be encouraging them to look at alternatives. One option that is probably the easiest, is shipping your own installation of Python 3. This however isn’t without it’s drawbacks. You need to deploy and maintain an entire Python 3 runtime. Tools such as Greg Neagle’s Relocatable Python have made this easier, but it still remains a dependency for any tool you write. Shell and zsh are options for very basic scripts. What about for scripts that need a more advanced language? ...

The role of the traditional Systems Administrator is slowly but surely dying. Clicking on buttons in GUI’s is making way for configuration as code. As such, you text editor is more important than ever. I’ve had several discussions about various setups, so here is mine. For conxtext on my choices, my day to day activities in a text editor are mainly: Terraform Python Puppet Go Configuration file editing (yaml, json etc) Preamble There are a few things that need to be installed before VS Code is functional for me. Firstly, you obviously need VS Code. I also need the following: ...

Crypt is a client secret escrow tool (primarily FileVault, but other secret types too). Because it holds secrets, it is common to want to restrict access to retrieving secrets to certain locations. If you are running one node, you can simply add something like the following to your Nginx configuration: upstream crypt { server 127.0.0.1:8000 fail_timeout=0; } server { listen 443 ssl ; server_name crypt.company.com; expires 1h; ssl on; ssl_certificate /etc/nginx/ssl/crypt.company.com.pem; ssl_certificate_key /etc/nginx/ssl/crypt.company.com.key; add_header X-Frame-Options "SAMEORIGIN"; access_log /var/log/nginx/crypt.access.log; location ~ ^/(checkin) { proxy_pass http://crypt; # your proxy settings here } location / { proxy_redirect http:// https://; proxy_pass http://crypt; # your proxy settings here allow 10.0.0.0/8; # Office network allow 172.16.0.0/12; #VPC deny all; } } The above will allow everyone access to the /checkin endpoint (so keys continue to be escrowed), but restrict any other page to the subnets listed. ...

At work, we’re great fans of MicroMDM. It’s lightweight, it’s all driven via an API so we can configure it with code - it has nearly everything we want. But unfortunately, it doesn’t have everything - as Groob himself says, “it’s not a product” - this means it purposely doesn’t include some of the things you may need from an MDM. This is where MDMDirector comes in. MDMDirector is able to receive the data from MicroMDM from it’s webhook feature and then take action based on the data it receives. Perhaps you need to ensure a profile is of a certain version on all of your devices? MDMDirector has you covered. What about via a REST API? We definitely do that too. Would you like to retrieve SecurityInfo or CertificateList from the machines regularly? Yep, can do that as well. ...

Up until now Movember has been pretty light hearted - I’m guessing this is why a lot of you haven’t donated yet. Time for some numbers. Testicular cancer is the most common cancer in young men, with nearly 700,000 people getting it each year. There is a 50% chance that I will get testicular cancer again. If my cancer does come back, there is 5-10% chance it will kill me. ...