technology.siprep.orgSt. Ignatius College Prep Tech Blog – SI's blog about technology

Skip to content St. Ignatius College Prep Tech Blog SI's blog about technology Using the personal recovery key to unlock/reset a user password on a FileVault-encrypted Mac In a previous blog post, I wrote about Why you should use FileVault personal recovery keys instead of institutional recovery keys . If you have a personal recovery key, this is how you can use it to unlock a FileVault-encrypted machine that's been reboot (useful for organizations that doesn't have their local admin accounts as FileVault-enabled ones) or how you can use it to reset a user's forgotten password. The steps for both procedures are very similar and differ only at the very end. When you boot up the Mac and get to the FileVault prompt for the user, click the question mark button next to the password field. Then, click the arrow next to If you forgot your password, you can reset it using your Recovery Key . You'll then be prompted to enter your recovery key. Go ahead and enter the recovery key when prompted. It won't be the one you see in the screenshot. It'll be one that you have escrowed somewhere (Crypt Server, your MDM, MunkiReport, etc.). And, don't worry—that recovery key is for a VM'ed Mac, and I rotated the key to be a new one anyway. Wait for macOS to boot up. At this point, the procedures for "unlock a machine that you want to reboot but don't know the user password to" and for "user has forgotten her password and needs a new one" diverge. If the user has forgotten her password, have her simply enter a new password, verify it, and then click Reset Password . If you just wanted to unlock the encrypted computer so you can log into another account (e.g., local admin that isn't a FileVault-enabled user), click Cancel , and you can log into another account on the computer. Posted by Alan Siu June 20, 2019 Posted in Uncategorized Tags: filevault , mac , passwords , personal reovery key , troubleshooting 1 Comment on Using the personal recovery key to unlock/reset a user password on a FileVault-encrypted Mac Finding 32-bit applications on Macs In macOS 10.13 (High Sierra), Apple started warning users about 32-bit applications by saying those applications were "not optimized" for their Macs. The warnings continued in macOS 10.14 (Mojave). Starting with macOS 10.15 (Catalina), 32-bit applications will cease working altogether . Hopefully, vendors still producing 32-bit applications for Macs will get their acts together and create 64-bit versions soon. In the meantime, you might want to check your Macs for what 32-bit applications they have installed so you can pressure vendors to update their apps, start looking for 64-bit alternatives to those apps, or consider whether you even still need to use those apps. Checking for 32-bit apps on an individual machine I'm not sure how useful this would be to Mac admins, but you can check for 32-bit applications on a single machine by going to System Information.app Then scroll down on the left side to find, under Software , Applications . It might take a while for the list to load. Once the list is loaded, you can sort by 64-bit (Intel) , and then sort again, so all the No entries are at the top. Checking for 32-bit apps for multiple machines via MunkiReport If you're using Munki and MunkiReport , you can go to Listings > Applications to see which apps in your fleet are 64-bit or not. If you want to query the MunkiReport database directly, you can also run SELECT DISTINCT path FROM applications WHERE has64bit=0 ORDER BY name, path and that will give you only distinct results. You could go distinct with name instead of path if you don't want the actual name of the app bundle but just the name of the app. Acknowledgements Thanks to eholtam and gmarnin on the MacAdmins Slack for pointing me to the right place in MunkiReport. Posted by Alan Siu June 7, 2019 June 7, 2019 Posted in Uncategorized Tags: 32-bit , catalina , high sierra , macos , mojave , munkireport 1 Comment on Finding 32-bit applications on Macs TCC in Mojave doesn’t prevent deleting local folders for AD-bound Macs Note : We're currently using a setup of Force local home directory on startup disk for AD-bound Macs instead of Create mobile account at login or Use UNC path from Active Directory to derive network home location —so if you're using either of those other options, your mileage may vary—definitely do some testing! This is also as of 10.14.5 (Mojave); Apple very well may change things for 10.15 (Catalina) and beyond. I was worried that TCC would mean we wouldn't be able to delete local home folders for AD users without jumping through some code signing hoops, but apparently a regular old /bin/rm -rf /Users/USERNAME command in a root-run script seems to do just fine there, whereas it would choke on a regular (non-AD) user with an Operation not permitted TCC error If you do need to code-sign a script, though, eventually, you may want to have a look at Code Signing Scripts for PPPC Whitelisting . It has a detailed walkthrough using Outset as an example. Posted by Alan Siu June 5, 2019 Posted in Uncategorized Tags: active directory , code signing , mojave , pppc , scripts , tcc Leave a comment on TCC in Mojave doesn’t prevent deleting local folders for AD-bound Macs Reinstall macOS using installr Now that Mac imaging is essentially dead and the new T2 chips make it more complicated to boot from external drives, reinstalling macOS to re-deploy a Mac can be a bit trickier. installr is a tool to do a clean reinstall of macOS via recovery mode (and install additional packages, too, if you'd like). The actual usage of installr is fairly straightforward and explained well in its README on GitHub . Here are a couple additional notes from my own testing on a late 2014 Mac Mini, though... Listen to the README on http vs. https https is definitely not something you can rely on if you're using installr over the network. If you try to serve up the installr.dmg over https, and then attach it via recovery mode, you may get this as a response: Usage: hdiutil attach [options] <image> hdiutil attach -help One more step for FileVault-encrypted drives Installr will prompt to erase the drive before installing macOS, but you installr won't see drives that are unmounted, so if the drive you're trying to reinstall macOS on is an encrypted drive, you'll either have to unlock/mount the drive first... or erase it first. Once the drive is mounted, installr will recognize it (and prompt you to erase it again). installr from USB not that much faster than over network Using installr over USB (even from a portable SSD) doesn't make the re-installation process go much faster. When I ran installr of http (over wireless), it took 4 minutes and 27 seconds from confirming erasure of the drive to the installer finishing and then needing to reboot to complete the installation. When I ran installr off a USB portable SSD, it took 1 minute and 48 seconds from confirming erasure of the drive to the installer finishing and then needing to reboot to complete the installation. So, it's a difference of less than 3 minutes. When you still have another 17 to complete the installation after that, 3 minutes is not a huge gain for choosing USB installr over http installr, but that small gain is something to consider when choosing how you decide to use installr in your own environment. One huge advantage to using http is having the installr files or disk images in one place instead of a variety of USB drives. How you choose to use installr will greatly depend on the needs and means of your organization. What the installr process looks like in Recovery Mode To run installr, you might have to boot into Recovery Mode (especially on a T2 Mac), as opposed to running it from an external drive. As I mentioned before, erasing the drive ahead of time isn't strictly necessary (it may be a FileVault-encrypted one), so if the drive is already mounted and isn't encrypted, you can skip launching Disk Utility. If you did hav...