Removing DigiNotar Trust in OS X

DigiNotar got hacked awhile back. And more and more issues seem to continue to surface as a result (most notably spoofing Google). Read this article for more info on it, but I’m not gonna’ rehash it all right now. Instead, let’s correct it. To do so, we’ll use the security command. Then we’ll use the delete-certificate option along with the -Z operator, which allows inputing (or outputting when installing certificates) a SHA1 has of a certificate. Root Certificates (those that appear under the System Roots section of the Keychain Access application) are all located in the /System/Library/Keychains/SystemRootCertificates.keychain keychain and so we’ll specify that as well: sudo security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C "/System/Library/Keychains/SystemRootCertificates.keychain" And that’s it, push out the security command through ARD or a policy and you’re untrusting DigiNotar. To verify removal, use the find-certificate option and either attempt to find via the SHA1 hash (-Z again) or use the email address as follows: security find-certificate -e info@diginotar.nl "/System/Library/Keychains/SystemRootCertificates.keychain" Keep in mind that the certificate can always be re-added to the SystemRootCertificates.keychain when they get all their little issues sorted out.

The Mac OS X App Store & Managed Environments

The Mac OS X App Store was released earlier this month as a part of the Mac OS X 10.6.6 update. The App Store, with over 1,000 applications (including a couple of server tools), allowing people to download and install applications on Mac OS X computers without needing to understand how to click through the screens of a standard package installer, drag applications from disk images into the /Applications folder or basically how to do practically anything except for click and provide a valid credit card number. As with the App Store that debuted with the iPhone, the App Store for Mac OS X is clearly aimed at residential customers, but being that these computers are used in enterprises around the world, the impact to managed environments cannot be discounted. I decided to do plenty of testing and reading before I wrote this up, so hopefully you’ll find it helpful, if not very timely. The first and probably most important aspect of the App Store to most who are charged with managing large numbers of Mac OS X computers is that only administrative users can install software from the App Store. This little fact makes the App Store itself a non-issue for most enterprises, who do not make typical users administrative users. Because only administrative accounts can download and install applications, there is little risk created from leaving the App Store on client computers. Applications installed from the App Store can only be deployed into the /Applications directory. These applications are owned by System, with read-only access given to the wheel group and everyone else. No ACLs are used, so while a single user purchases the software any user on the system can open it. If you copy the software to another computer then you will be prompted to authorize it using the same Apple ID that was used to purchase it. When an administrative user purchases an application, they are not prompted for a system password, only an App Store password, which uses the same Apple ID used for the iTunes Store and the iOS App Store. Application updates are handled using the familiar Updates screen borrowed from the iOS App Store, which includes the nifty Update All option. As far as controlling the user’s experience with the App Store, there are a few options. Administrators can remove the App Store application bundle (which can be replaced any time) from /Applications. Administrators can also black list the application using managed preferences/parental controls. A Dock item is added by default and can be removed as well. Removing both the Dock item and the Application bundle will then remove the App Store menu item from the Apple menu. You can also block the hosts at apple.com, which includes itunes.apple.com, ax.itunes.apple.com, ax.init.itunes.apple.com, albert.apple.com, metrics.sky.com and possibly gs.apple.com. These will communicate over ports 80 and 443, according to the operation being used. There is also a launch daemon at /System/Library/LaunchAgents/com.apple.storeagent.plist that should be unloaded and likely removed if you’re going to outright disable the App Store. However, the only real way I would personally disable is using a managed preference. There is also a property list file for the App Store that can be used to manage the application in Workgroup Manager in ~/Library/Preferences/com.apple.storeagent.plist. However, there isn’t much that can be done here at this time. Because applications are tied to users, when a user moves computers you will want to backup and restore the applications for the user. To do so, here’s the captain obvious article for ya’: http://support.apple.com/kb/HT4482. The App Store is not a replacement for a good patch management system. Software distribution cannot be managed centrally using the App Store and Software Update Server in Mac OS X Server does not currently cache applications from the App Store. Trying to think of a way to shoehorn the App Store into a software distribution system such as JAMF’s Casper Suite, Absolute Manage or FileWave is just asking for a world of pain, so let’s pretend that we never brought it up. If your organization isn’t able to license one of the aforementioned products, check out Star Deploy from http://www.stardeploy.com/StarDeploy/Home.html or munki from http://code.google.com/p/munki. Finally, I think that Apple’s done a great job with the App Store for a version 1 release. I think that my wife loves it and that over time if Apple chooses to do more with it then great; otherwise, all of the options we’ve been using, from the installer command on, are still at our disposal.

iPhone and iPad Admin Guide Now Shipping

The Enterprise iPhone and iPad Administrator’s Guide is now shipping (and rapidly moving up in Amazon’s rankings)! There have also been a couple of sightings in Border’s. Apress also sent out a press release and an email blast regarding the book in the past week. So, feel free to buy it using the link below! 🙂

Importing Computers Into DeployStudio

DeployStudio has the ability to import a csv file that is populated with the MAC address and a few specific settings. This allows you to prepopulate the database with the names that you want each machine to have. If you purchase a lot of machines from Apple then you can get a list of MAC addresses, or, you can use a bar code scanner to scan them as you’re unboxing. If you have a list of MAC addresses (en0), then you will need to format them in a very specific manner. Here, I have included a sample csv file with the data that goes into each field, which I have name DSImporter.csv. Once you paste the data that you’d like into the csv, provide the computer names (these can be pasted or compiled using formulas). Once done, save and then open Deploy Studio Admin. From here, click on Computers and then (as you would with iTunes) click on the plus sign (+) and create a new computer list (this step is optional, but I prefer to always import into computer lists, just in case something goes wrong, especially with my first import). Once you have created the computer list, you should see a screen similar to the following. Next, click on the Server menu and select Import. Now browse to your csv file and then click on the Import button. When the import is complete you will see a screen informing you as such. Click on the Done button to complete the process. You will then see your computers listed in the database and should see the names that you assigned them listed as well. You can now set a workflow item in DeployStudio for Reconfigure system with computers database content (shown below). This will set the name (and any other fields you decided to use) from the spreadsheet that you imported into the computer list. Once you have your computers in a group, you can also set a default workflow for them for their first time imaging, by clicking on the name of the group and then clicking on the Automation tab at the bottom as you can see below. Here, you will set the workflow to run and optionally set the computer to not have a default workflow moving forward or just be disabled so users can’t accidentally reimage their computers later. If you don’t have the MAC addresses for your computers ahead of time, you can use the Hostname option instead. This will enable you to enter the computer name that you would like to use moving forward into the DeployStudio Runtime at imaging and then have it stored in the DeployStudio database, where it can be used to build future workflows or even be exported and imported into the Open Directory computers. Overall, the computers and groups in DeployStudio Admin can be used to design more and more complex imaging sequences and to provide much of the scripting logic that a number of organizations need. Beyond that, JAMF, FileWave and a few other solutions offer even more logic and even more features or a little shell scripting can take you a really long way.

Fun Times with the JAMF Binary

I originally posted this at http://www.318.com/TechJournal Casper is an incredibly useful tool for package deployment, maintaining records of the systems in your environment and policy management. But for those of you already using Casper (or considering it) you’ll be glad to know that you can use the jamf binary to do all kinds of fun stuff that can help with troubleshooting computers in your environment. For example: The following command will setup a hidden SSH user and restrict SSH access to be allowed by only that user: jamf createAccount -username casperadmin -realname "Casper Admin" -password capseradmin -home /Users/casperadmin -hiddenUser -admin -secureSSH This command can be used to display a popup on the system it’s run on that says “Hello Minnesota”: jamf displayMessage -message "Hello Minnesota" The following command will unmount a mounted server called mainserver: jamf unmountServer -mountPoint /Volumes/mainserver The following command can be used to change a users home page in all of their web browsers: jamf setHomePage -homepage www.318.com The following command can be used to fire up the SSH daemon: jamf startSSH The following command can be used to fix the By Host files on the local machine: jamf fixByHostFiles -target 127.0.0.1 The following command can be used to run a Fix Permissions on the local machine: jamf fixPermissions / The following can be used to flush all of the caches on your local system: jamf flushCaches -flushSystem The following can be used to bless the drive externaldrive: jamf bless -target /Volumes/externaldrive The following can be used to run a software update on the local system: jamf runSoftwareUpdate The following can be used to bind to an AD environment (rather than dsconfigad if for some reason you just didn’t like using dsconfigad), but would need all the parameters for your environment put in as flags: jamf bindAD The following can be used to enable OpenFirmware passwords on your computer to secretpass: jamf setOFP -mode full -password secretpass Most of these options are available inside the Casper suite, but the ability to do some simple tasks very quickly from the terminal is yet another reason to fall in love with Casper.