Secure Instant Messaging

In many business environments, instant messaging has replaced email (and even the telephone) as the tool of choice for brief and casual contact. While easy, real-time chat has been embraced by most users, it still poses a number of challenges for network administrators. Most message services use no encryption by default, run your private conversations through their own servers, and offer no means to retain a permanent record of what could be important business communications. Running your own iChat Server can solve those problems.

In Server Admin, select your server from the left column, then click "Settings" from the toolbar. In the "Services" pane, check "iChat", and save your changes at the bottom of the window. Now choose the iChat service on the left, then hit "Settings" once again and begin with the "General" configuration pane. The current hostname of your server will already be listed under "Host Domains". If you'd prefer to use a service-specific name, such as ichat.makemacwork.com, you'll need that set up in your DNS listings.

Next, select the SSL certificate you'd like to encrypt message traffic with. You can use the unsigned "Default" certificate that's created by OS X Server, but many Jabber clients (including Apple's own iChat) will complain that they can't verify the server's identity. If your company doesn't already act as it's own certificate authority, it's easiest to use a third-party vendor such as Digicert, Thawte, or Go Daddy.

For "Authentication", Kerberos is the most secure option, but becomes unwieldy for users outside of your domain. The "Any Method" option will use Kerberos when possible, and otherwise default to a username and password. If you're required by law or policy to archive chat transcripts, move to the "Logging" pane, and check "Automatically save chat messages". When you're finished, click "Save".

Now everyone with a user account on your server can log in using any "Jabber-compatible" client. This includes iChat and Adium for Macintosh, as well as Trillian and Pidgin for Windows, among others. If you're planning to offer instant messaging from outside your office (for traveling employees, clients, or vendors) you'll also need to forward ports 5060, 5190, 5222, and 5223 through your firewall for this configuration.

Finally, there's one feature in Leopard's "Standard" server setup that somehow missed inclusion in the more flexible and configurable "Advanced" option. To automatically add every iChat user to every other user's Buddy List, you'll currently need to run the following on the command line after each user logs in initially:

sudo /usr/bin/jabber_autobuddy -m

Keep in mind that "Auto-Buddy" is a neat idea for small workgroups, but can quickly become unwieldy as your user base grows. If the feature appeals to you, it makes the most sense to automate the process by adding a launchd script that runs the command on a scheduled basis.

With these steps in place, anyone involved with your organization can send and receive secure instant messages through your OS X Server.

Recommended Reading: To learn more about the Jabber protocol (on which iChat Server is based), check out the information at Jabber.org.

Display Hidden Files In Finder

Hidden files in Mac OS X keep essential operating system data safe from casual tampering. The technique leaves the Finder uncluttered and easy to navigate, and diminishes the chance of accidental damage. But hidden files also the contain preferences for command line tools, serial numbers for commercial products, access controls for HTML directories, and the entire Unix subsystem that keeps your Macintoshes running. They're often useful for troubleshooting, and the ability to temporarily access them can be an invaluable tool for administrators.

Fortunately, there's a painless way to display these files when you're tracking down a problem on someone else's machine, and just as importantly a way to hide them again when you're done. Open the Terminal and type the following:

defaults write com.apple.finder AppleShowAllFiles -bool TRUE

Now hold down the option and command keys, and select the Finder icon in the dock. Choose "Relaunch" from the pop-up menu, and when your windows redraw they'll be full of your invisible files and folders, distinguished with lighter colored icons.

Keep in mind that working with hidden files can disable or even destroy your operating system. So when you're done, you'll want to put the system back the way you found it. To safely conceal your previously-hidden files, just run the above command again, replacing TRUE with FALSE and relaunching the Finder afterwards.

With this technique, you can harness the power of the command line while retaining the convenience of the graphical interface.

Recommended Reading: Ted Landau has a great article on the various kinds of "Invisible Files in Mac OS X" at MacFixit. Even more exhaustive is Gordon Davisson's wonderful chart of "Mac OS X Hidden Files & Directories", from Seattle's Westwind Computing.

Control File Access With ACLs

Traditional Unix file permissions (and their resultant issues and repairs) have been perplexing the majority of Macintosh users since OS X first appeared. Windows administrators, on the other hand, have bemoaned the lack of granular control in Apple's operating systems, with less-detailed permissions available than with Microsoft's XP and Vista. While Tiger introduced Windows-style ACLs (Access Control Lists) to the Macintosh, Leopard now utilizes them by default, making more complex file-sharing schemes a reality. Whether that's a gift or a curse depends on your ability to make ACLs work for you.

Understand Access Control Lists:

As easy as ACLs are to implement, deciding how to use them can be quite complicated. Access Control Lists are ordinal, meaning that the system reads them in order until it finds one that applies. Because of this, they can contain contradictory entries, with the actual permissions determined by where each entry appears in the overall list. ACLs also overrule standard file permissions, meaning that once they're utilized you can't depend on POSIX access schemes to be enforced. Without a clear plan for how your files will be shared, these features can lead to a great deal of confusion among users (if not the administrative team itself).

Mac OS X breaks ACL permissions into four groups: Administration, Read, Write, and Inheritance. "Administration" allows a user or group to change ownership and permissions. "Read" and "Write" act much like their POSIX counterparts, but allow for a much finer degree of control (such as whether or not users can read file attributes and permissions or delete files and folders as well as write to them). Finally, "Inheritance" determines if and how these permissions will be propagated to other files within a folder. Add to that the ability to allow or deny any of these rights, and you can see how a complex ACL scheme can become overwhelming.

Until you're comfortable with Access Control Lists, the best plan is to keep your plan simple. Assign "Administration" rights to a single administrative group, preferably the same group which has POSIX ownership of your share point. Then determine which user groups should have read or write access, and assign them to the list. Set these permissions at the root of your share point, and apply all inheritance options. Most importantly, avoid any "Deny" entries, which can make initial troubleshooting difficult.

Enabling Access Control Lists:

Now that you have a stragtegy to implement ACLs, you'll need to make sure that your files can apply them. If the volume was attached to your server when Leopard was installed, this should have taken place by default. If, on the other hand, you have an external volume coming from an earlier OS X installation, or you're still working on Tiger, you'll have to enable ACLs manually before you can continue. Open the Terminal and type the following, replacing DISKNAME with the name of your volume:

fsaclctl -p /Volumes/DISKNAME -e

It's important to note that in Tiger, enabling ACLs for a volume disables the ability to inherit permissions via standard POSIX (Unix-style) controls. Leopard's controls appear to allow both, but as of version 10.5.1 inheriting permissions works only when using ACLs, regardless of your settings.

Configuring Access Control Lists:

Once you've enabled ACLs, the final step is to set them for your files. In Leopard, this can be done in the "Sharing" section of Server Admin. In Tiger, similar controls can be found in Workgroup Manager.

In the top half of the window, select the share point you'd like to enforce access controls on. Then click the "plus" button on the bottom left, and the "Users and Groups" palette will appear. From the palette, you can drag the users or groups you're granting permissions into the bottom half of the main window, then arrange them in whatever order you planned. The "Permission" column will allow you to set "Full Control", "Read & Write", "Read Only", or "Write Only" from the main window. For additional options (such as removing the ability to delete files), select the "Custom" option.

Finally, if you want your existing files to have the same access controls, click the "gear" button at the bottom of the window and select "Propogate Permissions..." from the menu. When the propagation sheet appears, check the "Access Control List" box and click "OK". Those permissions will be applied to all the files beneath that share point.

With Access Control Lists in place, Windows teams can finally have the same control over their Macintosh shares, while long-time Macintosh admins can escape the pitfalls of Leopard's new file sharing issues.

Recommended Reading: John Siracusa gives a great overview of access control lists at Ars Technica, in his original review of Tiger (where they first appeared for Macintosh). Shareware author Marcel Bresink also has a great ACL overview in the manual for his application Tinker Tool. Lastly, if you're struggling with Unix permissions under Leopard, you'll want to see Apple's discussion forum for the article on 10.5 Server not inheriting permissions correctly.

Mail Won’t Search Messages

You're looking for an email you sent months ago. You're not sure which member of your team it went to, and you can't remember the subject line you used. You know what it was about, though, so you type that in Mail's "Search" field. When the results appear, however, the option to search through each "Entire Message" is suddenly grayed out and unavailable.

Leopard brought a number of improvements to Apple's Mail, such as integrated to-do lists, RSS feed subscriptions, and Address Book data detection. It also added the ability to perform system-wide email searches with Spotlight, the OS X file indexing engine. While this feature has proven to be the most powerful, it's also been the most troublesome, as issues that would previously effect only Spotlight can now disable the ability to search the content of email messages.

When Spotlight attempts to scan a corrupt file, it can stall or crash, failing to properly index your disks and (as a result) your Mail archives. To figure out what Spotlight's choking on, you'll first need it to stop indexing entirely. Make sure you've quit out of Mail, the open the Terminal and type:

sudo mdutil -i off /Volumes/*

Next, open the Console application in the Utilities folder. View "All Messages" in the left hand column, and use the "Filter" field in the top right to search for "mdworker" (the behind-the-scenes process that indexes data for Spotlight). If the remaining errors end in file names, you've found a likely source for your Mail woes. Make sure these files are safe to move (and not within Application bundles or required by the OS), then relocate them to a removable drive or erase them entirely.

With your suspect files out of the way, you can remove your existing Spotlight indexes and restart the process. On the command line, substitute the name of each of your mounted volumes for DISKNAME, and type:

sudo rm -r /Volumes/DISKNAME/.Spotlight-V100
sudo mdutil -E -i on /Volumes/*

Once the indexing is complete, check the Console logs again to make sure the errors haven't repeated. You can now reopen Mail, and the ability to search entire messages should be restored.

Identify Active DHCP Servers

Sometimes, it seems like your network must be haunted. Everything works perfectly for days then a lone workstation goes crazy, losing internet access, failing to bind to the server, or even using an IP outside your normal range. A reboot remedies the problem, until it crops up days later on a completely different machine.

The likely culprit is an unintended DHCP server. Devices like misconfigured Airports, retired routers used as desktop hubs, or even a "modded" XBox in the break room can offer erroneous network information to unsuspecting machines. It's an unexpected problem, but a common one. Fortunately, it's relatively easy to find out from which DHCP server your Macintosh is actively receiving configuration information.

First, you'll need the Unix name for your active network interface. The simplest way to get this is to open System Profiler in the Utilities folder, and select "Network" from the left column. This will list each network interface in plain english as well as the "BSD Device Name" you're looking for. You can get the same information from the command line, though the format may take a bit more to decipher, by typing:

ifconfig -u

With the Unix name of the active interface, you can use this information to determine the IP address of that interface's DHCP server by opening the Terminal and typing:

ipconfig getoption INTERFACE server_identifier

Substitute the interface name for INTERFACE in the example above and you'll immediately know which IP is providing a given computer its DHCP information. If it's not coming from the address you expect (most likely your router or your OS X Server), then you've identified a rogue DHCP server on your network. Locate the machine physically and reconfigure it (or unplug it altogether) and the problem will disappear.