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.

Master Open Directory — Part 2

If you've got a Macintosh server in your environment, chances are it was originally purchased as a file server. With a few local accounts and enough disk space, a centralized environment to share common documents can completely change the way a small department functions. As the needs of your workgroup and your network grow, however, you're likely looking towards collaboration, scheduling, and security features. That's when Open Directory becomes an important part of network management.

In part one of this article, we explored the basics of getting Open Directory up and running. This week, we'll set security policy to restrict access to your network services, then create or migrate user accounts to the LDAP directory for distribution and set up your workstations to use them.

Secure Open Directory Access:

By default, Open Directory will allow access to any machine on the network. This may work fine in an isolated academic environment, but most businesses have greater security requirements imposed upon them. Those requirements are fulfilled by Kerberos, an encrypted ticket-based authentication system developed at an isolated academic environment called MIT.

Open the Server Admin tool and select the "Open Directory" option from your server listing on the left. Click the "Settings" button in the Toolbar, followed by the "Policy" button on the strip below it, and the "Binding" button on the strip below that. Check the top two boxes to require authenticated binding for directory services, then the next four to enforce the strict Kerberos protocols for authentication.

Now click the "Passwords" button to define your organization's minimum password requirements. An ideal policy varies widely depending on each individual environment, but keep in mind that overly strict policies often lead to weaker passwords overall (or complex passwords taped to monitors and under keyboards). Whatever you choose, be sure to check "be reset on first user login" password. This allows you to assign the same default password to all new and imported accounts, rather than assign each account a new password individually, then forces users to create a new one immediately.

Migrate Users To Open Directory:

Now that you can insure account information will be communicated securely, the next step Launch Workgroup Manager and log in under the directory administration account created in part one (diradmin by default) with the fully qualified domain name of your server (such as www.example.com).

This will open into the server's /Local/Default directory, where non-network account information is stored. If you already have local user accounts, you'll see them listed down the left column. Select those you're transferring to the Open Directory service, then select "Export..." from the "Server" menu. The dialog will prompt you for a name and location to save your exported account listing. This export file will contain all the users' existing account information except passwords, hence the importance of requiring new ones at login.

To move the accounts to Open Directory, click the tiny globe on the far left of the Workgroup Manager window, in the thin stripe just below the toolbar. Choose /LDAPv3/127.0.0.1, indicating that you're now editing the LDAP (lightweight directory access protocol) settings. You should see your directory administrator account to the left, but no other users listed. Select "Import..." from the "Server" menu, and you'll be presented with the dialog to re-import your accounts. If you're moving accounts to an empty directory, you can safely leave these options at their defaults and click the "Import" button. Your exported local accounts should now be listed down the left hand side as Open Directory accounts. Only once you're sure the new network accounts work properly should you then delete their local counterparts.

If you're setting up a brand new server, there are no accounts to move around. Instead, just select the /LDAPv3/127.0.0.1 directory, and create your new users and groups.

Bind Clients To Open Directory:

Now that you've made accounts visible to the network, you'll want to configure your other machines to utilize them. On your client machines, open Directory Utility, and click the plus sign at the bottom of the window. Leave "Open Directory" selected in the pulldown menu, then enter the fully qualified domain name of your Open Directory server and hit "OK".

The window will then expand to accept credentials for the authenticated binding you've required. Enter the username and password of your directory administration account, as well as a unique machine identifier (most often the hostname or serial number), then hit OK again. If the binding process is successful, you'll be greeted with a reassuring green light and a message that the Open Directory server "is responding normally".

If you're unsure if a computer bound properly, or has become unbound, the simplest test is to open the Terminal and type:

id diradmin

If you named your directory administrator account differently, just substitute that for diradmin, but be sure to use an account that exists only in the directory service and not on the local machine. The response should contain the UID, GID, and groups that user is a member of. Should the response instead be "no such user", and the user exists on the server, then the machine has become unbound.

Now that you can login to all your machines with Open Directory network accounts, you can leverage those accounts for OS X security, collaboration, and management features.

Master Open Directory — Part 1

It can control your company’s user accounts, their password policies and preferences. It allows access to home directories from anywhere on the network, and mirror that data safely to your server. It forms the basis for features like shared calendaring and contacts, single sign-on to computing resources, and enterprise-level security for all your network services. In the past, Open Directory may have been Apple’s best-kept secret, but it’s now the essential element of business-class Macintosh deployment.

System administrators rely on services like Open Directory to keep down per-person support costs and prevent the need for repetitive tasks and individual maintenance. For users, however, Open Directory finally delivers on the promise of a Macintosh corporate network that “just works”. In this two-part series, we'll make that happen.

Configure DNS For Open Directory:

Like anything designed to look effortless, Open Directory implementation depends on a series of precise and carefully preformed steps. In the event of an error, most of those steps can be retraced, but having flawless Domain Name Service is essential to a successful Open Directory deployment. Improperly configured DNS isn’t just the reason Open Directory can fail at the very start, it’s most often the reason it fails during or even after the job is completed.

The most important determination to make is how DNS is controlled in your individual environment. If this is someone else’s responsibility and has been pre-configured, you’ll need to coordinate with them to be sure their name servers provide both forward and reverse listings for your planned Open Directory server. You can test this by opening the Terminal and typing:

nslookup HOSTNAME

Here HOSTNAME is replaced by the fully-qualified domain name of your server, such as server.makemacwork.com. This should return the IP address of the machine in question, without any error messages. Now repeat the test, replacing IP below with the IP address you just received:

nslookup IP

If reverse lookups are operating properly, the command will return the hostname you began with. If not, you’ll have to find a way to get it reconfigured, or take on the responsibility of configuring it yourself. If it’s your job to set up Open Directory, the authoritative server for your domain should likely be under your control.

To configure DNS for Open Directory, launch Server Admin, and select your server from the column to the left. Choose the “Settings” button on the top right (represented by the gear icon), then the “Services” pane from the far right of the top strip of buttons. Check the box marking “DNS”, then click “Save” at the bottom of the window.

Now select “DNS” below your server on the far left, and choose the “Zones” button (represented by the network globe) across the top. This is where you’ll build a very short listing of the domains for which the your server offers domain name service. Find the row marked “Primary Zone” and double-click the domain name. By default this will be example.com, but you’ll change it to your own domain. Likewise, below it is a single “Machine” listing named ns. Change this to the name of the machine you’re editing, making sure that the “Nameservers” list in the primary zone matches.

If the server you’re configuring will be the primary name server for your internal domain, it’s best to have the service configured on a secondary machine as well, providing uninterrupted and redundant service. With the configuration completed, you can push the “Start DNS” button at the bottom of the window.

Before you move on, open the “Network” pane in the System Preferences. Confirm the network settings are manually configured and add the server’s own IP to the “DNS Server” listing (in front of any external IPs) and your Open Directory domain name to the “Search Domains” field. Now open the Terminal one last time and type:

hostname

If you get a fully-qualified response which includes your domain name, the server is properly identifying itself. If you receive a name ending in “.local”, then the DNS is improperly configured and needs to be repaired before proceeding to the next stage.

Deploy The Open Directory Service:

Now that you’ve laid the groundwork with DNS, return to the service “Settings” in Server Admin, check the box for Open Directory, and save. This will bring you to the first configuration pane, reading "Role: Standalone Server". Click the "Change..." button and you'll be prompted to choose an Open Directory configuration. For basic set up, select "Open Directory Master" and hit "Continue".

The Open Directory assistant will ask you to create a new user specifically to administer the network directory domain. By default, the username is diradmin and the UID is 1000, but you can change these to whatever best fits your existing management scheme. Once the directory service is in place, the right to administer it can be assigned to an existing user or divided amongst your management team.

The next window assigns both the Kerberos Realm (which controls the Open Directory security components) and the Search Base for your master domain. These should both fill in automatically. The realm is identical to your fully qualified host name, and should appear in capital letters. The search base is identical, except that each period is replaced by "dc=", defining each portion of the name as a domain component. Double-check the information is correct and hit "Continue". The assistant should confirm that your server has been promoted to an Open Directory Master.

With this foundation is in place, you can begin building on Open Directory to take control of your Macintosh network.

Next week in part two, we'll secure Open Directory to restrict access, migrate user accounts to the directory service, and configure your machines to utilize them.

Command Time Machine

With it's spacey presentation and it's promise of effortless data safety, Time Machine is the marquee feature of OS X Leopard, mentioned in every review as worth the price of the upgrade alone. While the ability to minimize data loss on any machine is fantastic, Time Machine presents some unique challenges for the people tasked with maintaining those machines. The minimal configuration options that make Time Machine so easy to use can also make it hard to control. Fortunately, there are more tools available than are exposed in the graphical interface.

Exclude Files From Time Machine Backup:

While the Time Machine pane in System Preferences has an intuitive interface for excluding paths from backup, doing so for multiple files and folders (or worse still, multiple machines) can be time-consuming. Instead, you can specify files to avoid through the command line, either locally or sent over Apple Remote Desktop. In this example, just replace PATH-ONE and PATH-TWO with as many absolute paths as you have directories or files to exempt.

sudo defaults write /Library/Preferences/com.apple.TimeMachine \
SkipPaths -array-add "PATH-ONE" "PATH-TWO"

Change Regular Time Machine Backup Intervals:

Another Time Machine annoyance is the mandatory hourly scheduling, forcing the machine into heavy disk access even when it's being used for other read/write intensive operations (like video editing and playback). You can adjust the time between backups, however, in the Terminal or by changing the preferences file with Property List Editor (available in Apple's free Developer Tools).

If you're altering Time Machine's schedule programmatically, type the following:

sudo defaults write /System/Library/LaunchDaemons/\
com.apple.backupd-auto StartInterval -int SECONDS

Replace SECONDS with your desired wait between backups, specified in seconds (that's 3600 per hour). This has the unwanted side-effect of restricting read permissions on the file, so if you want to edit these preferences again or have them run properly, you'll have to set it's permissions back to their original configuration like so:

chmod 644 /System/Library/LaunchDaemons/\
com.apple.backupd-auto

Editing the file with Property List Editor lets you skip the second step entirely, but confines you to manually adjusting the settings on each individual machine.

Schedule Time Machine Backups:

If you'd like to run Time Machine only at times you've chosen, the command can be incorporated into a legacy crontab, by preparing a scheduled job through launchd, or even by embedding the instructions in an Applescript and choosing "Run Script" from the "Alarm" options in an iCal event. The line you need is:

/System/Library/CoreServices/backupd.bundle/Contents/Resources/\
backupd-helper &

Prevent Unwanted Time Machine Dialogs:

By default, if you haven't yet set a Time Machine volume, you'll get asked if each and every disk you attach is a suitable backup destination. If you're utilizing a different backup scheme, these dialogs can become an annoyance quickly. To put a stop to the them, the command you're looking for is:

defaults write com.apple.TimeMachine DoNotOfferNewDisksForBackup \
-bool YES

Protect Database Files From Time Machine:

Finally, even Apple acknowledges that Time Machine has issues backing up live databases. The cause (and it's effects) are still unclear, but it doesn't hurt to be careful with applications which run a database in the background when closed (such as Microsoft's Entourage). The problem can be avoided by logging out before scheduled backups occur. The database will safely close, and Time Machine will run as expected.

Recommended Reading: While we were proud to have originally figured out this first Leopard tip on our own, the article was later updated to include Josh Wisenbaker's clever tip to Stop Time Machine Nagging, via the equally clever AFP548.com.