AFP548

InstaDMG 1.4b2 Release and Project Changes

Tue, 22 Jul 2008 14:01:00 -0500

Updates a plenty from the InstaDMG front today.

Read on for details...

The reference script gets a bump to 1.4b2 with lots of added featuresfrom reader Fred Licht, many of which are directed at a future whereyou may have multiple builds running at one time. I've added someupdates as well and it's a nice release. Some of the changes are:

Randomized intermediary image names.
Individual InstallerChoices.xml files for every package.
Individual logs per run.
The AppleUpdates folder changes names to the BaseUpdates folder.
Lots of other cleanup.

The most important thing in here when updating to 1.4b2 is that theAppleUpdates folder has changed names to BaseUpdates. This is to help combat some confusion as to what goes in there. Make sure thatyou update your build train roots as needed.

From a development standpoint we are plugging away at the 1.4 featureset. In order to help the many people that want to help me, the activedevelopment of the reference script is moving to the SVNat http://code.google.com/p/instadmg/.

This doesn't mean that InstaDMG is leaving AFP548.com though. Goingforward the active development version and bug tracking will live atGoogle Code. The reference releases, news, and discussion forums will continue tolive here. If you don't have a hankering to write code, or live on anightly, then nothing will change for you. Please note that the issue tracker on Google Code is where you should file bugs or feature requests.

You can grab the new reference release in our downloads section here.

As always, many thanks to the readers who provide the support for InstaDMG!

Competition Time! - seeking a name for "kicker-replacement" (We have a Winner!)

Wed, 16 Jul 2008 13:41:52 -0500

You might have read some of our previous articles talking about using kicker to perform actions on network status changes.

This was always an unsupported solution, and with Leopard it turns out that Apple no longer needed kicker, and so they got rid of it.

Chris Adams and I started kicking around some ideas in Python, and the result is an incredibly flexible framework for triggering events on any change to the SystemConfiguration API, NSWorkspace notifications, and filesystem changes via FSEvents.

You can find this along with some other useful Python Mac sysadmin utilities at the Google Code site pymacadmin.

Anyway, there's a problem.

We need a name.

[Edit: 2008/07/23 - We have a winner! Kok-Yong Tan came up with "cranker" and the primary daemon will be called "crankd" ]

Read on for details....

The only material benefit we can promise you is some Google schwag that is yet to be determined... as well as a permanant line inside the README file, but think of the fame!

We really think this is going to be huge. It's incredibly useful, you can use it to trigger events on network changes, and NSWorkspace notifications like:

NSWorkspaceDidLaunchApplicationNotification
NSWorkspaceDidMountNotification
NSWorkspaceDidPerformFileOperationNotification
NSWorkspaceDidTerminateApplicationNotification
NSWorkspaceDidWakeNotification
NSWorkspaceDidUnmountNotification
NSWorkspaceSessionDidBecomeActiveNotification
NSWorkspaceSessionDidResignActiveNotification
NSWorkspaceWillLaunchApplicationNotification
NSWorkspaceWillPowerOffNotification
NSWorkspaceWillSleepNotification
NSWorkspaceWillUnmountNotification

but we need a name! We'll update this article when we've chosen one. You can submit a name in the comments below this article, or by joining the Google Group pymacadmin and posting it there.

If you're interested in all the amazing ramifications of Apple opening up the entire Cocoa API to Python in 10.5 as far as sysadmins go, please join the group and code project, and join in. We've already started working on a unit testing framework for Mac OS X image candidates that plays really nicely with InstaDMG.

iPhone-o-rama!

Fri, 11 Jul 2008 19:52:00 -0500

How about some light reading while you play around with the App store?

First and foremost the deployment guide from Apple can be found here. A lot of good information about how to configure up the device for use within an Enterprise.

Some Enterprise-specific support information can be found here. This page will link you to the Enterprise Configuration Utility.

Finally, some perspective on using an iPhone with Exchange from Microsoft's Exchange blog.

John de Troye in French!

Wed, 09 Jul 2008 10:59:06 -0500

NausicaMedia, the first french company certified on Mac OS X and Mac OS X Server, has translated the "Tips and Tricks for Macintosh Management" of John de Troye in french.

Although this is the Tiger Version, the Leopard's one is not released yet, everyone know how much this documentation can be important as a practice for a sysadmin. The Tips and Tricks have been many times lauded like the documentation you can't get from a training center !

"Tips and tricks for the Macintosh Management", sorry : "Trucs et astuces pour la Gestion du Macintosh" is available at NausicaMedia's website.

Kerberos in Leopard: The Local KDC part 1

Wed, 09 Jul 2008 09:15:00 -0500

The Local KDC and why it shouldn't make you run in fear.

Leopard brings a brand new and much misunderstood invention to Mac OS X. Every client, and server, will create, maintain and use it's own instance of a Kerberos Key Distribution Center. All users on the system will be given Local KDC principals in addition to whatever other form of password store they would have otherwise received.

Crazy?

Maybe.

Brilliant?

Most certainly.

Read on for why this really shouldn't scare the living crap out of you...

What is this crazy thing?

In order to better secure peer-to-peer communication, and this isn't the "dirty" kind of P2P but just any connection not using a centralized directory service, Apple has added a local KDC to every install of Leopard.

This was a rather bold move on the behalf of Apple, as Kerberos has often times been seen as the work of the owner of the 3-headed dog which Kerberos uses as it's logo. Regardless of the perception of amazing complexity though, Kerberos is widely considered a very secure method of authentication. Both Open Directory and Active Directory heavily leverage Kerberos to not only ensure a secure channel for authentication but to also provide a mechanism for single-sign-on to the user.

And that is exactly what the LKDC provides. A method of secure authentication with the additional gravy of a single sign-on environment.

Local Only

The first piece to understand is that the concept of the LKDC isn't just an Apple construct. While Apple seems to have driven the creation of the beast, the functionality, or at least the basics of it, has been rolled back into the MIT Kerberos distribution. Will other vendors use the functionality... that's yet to be determined.

You can recognize a LKDC because the Kerberos realm will start with LKDC: followed by a SHA1 hash or the KDC's public certificate that essentially acts as a unique identifier. No "real" realm is going to start with LKDC: so there should be no confusion between local and managed Kerberos environments.

By definition the LKDC only can encompass one machine. There are no member servers. The KDC and the kadmin servers are one in the same. There is no redundancy and there are no trusts or any relationships between an LKDC and any other, local or not, Kerberos realm.

Because of this you'll find no edu.mit.kerberos file, or krb5.conf file for you non-OS X folk, that references the LKDC. The beauty of the entire instance of the LKDC living on the same server means that you don't need one. If you talk to a system that proclaims to be from an LKDC, by definition you know that the KDC, the kadmin interface and all member services are on that one specific machine. By the mere fact that you've initiated a connection to that server, you now know everything you could ever need to know about the Kerberos realm that the LKDC hosts.

Realms Apart

The other piece of magic that had to occur is for the client system to not completely freak out over the seriously massive amount of Kerberos realms that it now might encounter. Take the example of a larger Enterprise organization. It might have 5000 Mac OS X systems in it. This means that there will be 5000 LKDCs present on the network. If you've worked with Kerberos prior to the LKDC this is a staggering thought. Enough to make the blood of even the most hardened Kerberos admins run cold.

In 10.5 it is perfectly normal, and quite expected, for a client system to acquire and use a multitude of TGTs. Under "old skool" Kerberos you got one TGT when you logged in and you used this for all of your single sign on activities. If you were crazy enough to have multiple Kerberos realms that didn't have trusts between them you could get yourself another TGT to access resources in that secondary realm. However, you would have to manually switch between the two TGTs depending on what resource you wanted to access next.

Now with Leopard the system should be able to use any TGT you currently have to access a service. Well behaved systems on the client will attempt to acquire a service ticket with every TGT you have until it gets one that works. Yes, there's more traffic going across the wire here, but no, the user is not really inconvenienced by this.

For Leopard Apple introduced the NetAuthAgent which you'll find squirreled away in /System/Library/CoreServices. This works as an authentication agent for services. For example, in Leopard when you connect to an AFP share, the AFP client now hands over the task of figuring out the whole Kerberos "problem" to the NetAuthAgent. The agent will figure out the realm as best it can. Some services, specifically AFP can negotiate the realm to use when negotiating the authentication mechanisms that are available. AFP is very much the anomaly here. For the rest of the services the NetAuthAgent will just iterate through the list of TGTs that a user already has and attempt to get a service ticket for the remote server.

If we go back to our large example, this means that it should not only be possible, but even expected, that a Leopard client system could have 5000 TGTs for a user at any one time. While it may take a bit longer to get a service ticket for a particular service in this case, it would still be quicker than the user typing in a password, and much less of a bother.

LKDC Creation

The LKDC is created when a machine is configured with the inital admin user.

The KDC bits and pieces are stored in the usual place, /var/db/krb5kdc. In this location you'll notice all the trappings of a KDC with all of it referring to an LKDC: realm. In particular the kdc.conf file lists out all the particulars of the LKDC. You'll note that there is a keypair presumably for the LKDC stashed away in the System keychain, however from reading the config file it seems that there's no correlation between the keypair and the LKDC. Perhaps this is being reserved for future functionality.

If you are an OD Master, it's perfectly reasonable to expect the ODM to have both a LKDC and a "real" or managed realm associated with it. You'll notice 2 KDC processes running on your system and 2 KDC databases in /var/db/krb5kdc.

The presence of an LKDC can be problematic when imaging systems from a Holy Mac that's already been booted. In this case, it's best to remove the LKDC database and config files and then recreate them after the machine has been deployed using the configureLocalKDC command.

Still to Discuss...

This covers the basic concepts of the LKDC, but not the actual use and abuse thereof. We'll discuss that when we get around to writing a follow up to this.

AFP548 Abducted by Aliens!

Tue, 08 Jul 2008 17:23:27 -0500

We're back now... but we've been fully probed in all orifices by beings of unknown origin.

We had just been remarking on how the server had just had it's 4th birthday... and boom! Double degraded RAID set.

Anyhoo, we're back up and running, and should have new content shortly.

Request for Testers - MS Certificate Authority

Wed, 02 Jul 2008 11:30:00 -0500

In our continuing attempt to just tease, but not actually write anything... We're interested in hearing from people using a Microsoft Certificate Authority to provision machine or user certs.

Using the MS CA's web enrollment, it's actually quite trivial to script all of this and keep it tidy with Kerberos provided by the AD plugin. Uses for this would be to auto-enroll your laptops for certificates to be used with 802.1X, or perhaps to auto-enroll your users with e-mail signing certificates.

If you're in an environment like this, and you'd like to try this out a bit, let us know. I've got a shell script that does the enrollment work, and shouldn't require any changes on the AD side.

Summer Slowdown

Fri, 27 Jun 2008 00:23:18 -0500

A quick heads up that things may turn around here a bit slower than they have been lately.

We're reshuffling the core admin team a bit due to some serious and ongoing time constraints.

Anyone looking to help pick up the slack in the production please drop us a line.

New InstaDMG Release and Versioning

Tue, 24 Jun 2008 21:53:57 -0500

I know, I know... InstaDMG releases are few and far between these days, but there is a reason why!

As it stands I've been trying to only release major versions like 1.1, 1.2, and 1.3. Internally I've got a roadmap and minor versions like 1.3.1, 1.3.2, and 1.3.3 with each point typically corresponding to a feature. The problem with this is that I only have so much time to work on the reference script and as a result there aren't many releases.

I'm going to try and fix this though in two ways.

The first is that InstaDMG major releases are no longer beta. Plenty of people are using the script everyday to get work done, including me, so I don't think that the beta moniker really applies any more.

Secondly, I'm going to release each of my previously internal dev versions as betas for the next major. This starts today with 1.4b1 (Which for those that care used to be 1.3.3b.) and will continue until we hit all the 1.4 milestones. Keep in mind that these betas will be representative of that status and things may change in them from release to release. For example I know that there will be logging changes in 1.4b2.

By releasing the beta versions we will get more testing, more feedback, and the major releases will be more stable.

You can grab the 1.4b1 here.

AD Password Expiration Notifications

Wed, 18 Jun 2008 21:47:00 -0500

We lost the semi-useful password expiration notifications in 10.5 that we briefly had towards the tail end of 10.4.

I'd hacked a script together to notify users when their password was about to expire, but hadn't gotten around to posting it yet. Luckily, Mr. Bukowinski did a better job of it and already posted it.

Grab the script and Dashboard widget here.