Mac OS X SIG

I realize now that writing technical articles in a word processor isn't the best way to go, since it's a pain to revisit and edit things later (once you find a mistake, which is invitable). So, I'm taking the original article I wrote and reprocessing it here. (Figuring out how to make a nifty inline box for easier reading of code entries helped out, too.)

This article's a broad-stroke outline on how to integrate Samba 3, OpenLDAP, Kerberos and AFP in Leopard Server, specifically as it would apply here at Stanford. What this gets you:

• Filesharing services to both Macs and Windows clients
• Using the campus' OpenLDAP directory for account provisioning
• Using the main campus Kerberos realm for authentication
• Using Open Directory for delegating share access using ACLs

Many of us have Stanford Desktop Tools on our machine, or at least have a proper edu.mit.Kerberos file (aka krb5.conf) so that we can use Kerberos authentication for email programs like Mail.app or Eudora, web browsers like Safari with HTTP Negotiate, and other single sign-on services like filesharing. But out-of-the-box, we're faced with double-authentication scenarios, where we first log into our Mac, then we face a Kerberos dialogue box (where we enter our SUNet ID and password). Wouldn't it be nice to get our Kerberos credentials at the same time we log in?

The instructions provided by ITS for integrating stanford.edu Kerberos keytabs are here. However well written, it's clear they're geared for Unix or Linux administrators.

It's actually easier for Mac admins, in my opinion, since you have the campus Unix/Linux cluster machines to use, your Mac server already has the Kerberos bits built in, and you don't have to compile or install AFS components, either.

I want to say that we have WebAuth working on 10.5.2, but it's not. At least not yet.

At issue is the changes undertaken in web services between 10.4 and 10.5. They're quite substantial.

Tiger's web server was Apache 1.3, was 32-bit and either built for PowerPC or, later, to be "universal" to additionally run on Intel processors. Leopard's web server is a whole other beast. The default web server is now Apache 2.2, it's all 64-bit and it's built for four different processor families.

This will pose some challenges.

On the Library cluster macs we decided that we should set a specific SSH option for a number of the shared computers on campus (for example: Cardinal). The specific option is GSSAPIDelegateCredentials, and when used with GSSAPIAuthentication and GSSAPIKeyExchange allows users to ssh from our cluster computers to the selected hosts without typing a password (while getting full Kerberos-based services on the new host). We had considered allowing this for all hosts with a stanford.edu address, but concerns about untrusted computers that might have stanford.edu addresses (like all the computers in the Residences), along with some of the details about how names are evaluated for ssh_config meant we had to be a little more savvy. At the same time we were not interested in managing an ever-changing list of hosts.

The solution that we came up with was to decide to trust the hosts listed in the canocial list of stanford hosts found at '/afs/ir.stanford.edu/dev/pubsw/config/ssh/' (that is in afs space). I wrote a script that pulls in this information from the canonical file, and then makes modifications to both /etc/ssh_config and /etc/known_hosts. I am offering this script out to anyone who might like to use it.

On the Libraries’ cluster computers we need to allow Stanford people to log in with their SUNet IDs and passwords. This means that we need to authenticate against Stanford’s LDAP server. Previous documents have described how to do this for 10.4, and this document will cover the much easier process for 10.5.

In addition, we will be covering how to auto-mount the users AFS home directory as their home directory.

Note: Auto-mounting the home directory can cause problems if your users move back-and-forth between OS versions. You should be aware of this potential problem.

I needed to get WebAuth working on my Leopard server, but out of the box, there are some issues with building the modules. I want it to work with the included Apache 2.2, so that I and other admins can use Apple's Server Admin tool to configure sites and directories. (Admittedly, I get that tingly, satisfying feeling when third-party tools fit like a puzzle piece in your operating system of choice. Can't discount that motivating incentive.)

But time pressures prevailed, so I had to prioritize a workaround to meet a looming deadline. Personally, "workarounds" almost always gives leave me dissatisfied, but in this case, it's a necessity. Here's how I implemented WebAuth, opting to give up the web server administration utility of Server Admin (which, at the end of the day, isn't too great a loss).

In short, you'll 1) build Apache 2.2 from source, 2) build WebAuth, 3) add the WebAuth Kerberos keytab, 4) add an SSL certificate, 5) hand-configure your conf files to protect your sites and 6) add a launchd file to start it all automatically.

I've been doing some mucking around with my Leopard 10.5.2 dev server and came across what I think is a bug (or at least a problem). It seems that if you have a folder on a Mac OS X Server 10.5.2 sharepoint, shared via Samba, and the folder has (certain, common) extended attributes, Vista (and possibly XP) users will get an error when they try to download the folder. The error the Vista user will get is: "Error 0x800700FE: The specified extended attribute name was invalid."

It seems that if you 1) have extended attributes on 2) a directory that 3) has a colon in the attribute's key or value, Vista will produce an error and prohibit downloading. Naturally, this is problematic, because users can't always control how EAs are applied. And just about every EA has a colon with MOSX.