Building a Panther Server as an OD Master and Windows PDC

In my last column, I promised to detail the building of a Panther server as an Open Directory (OD) Master and Windows Primary Domain Controller (PDC). Now that my system is up and running, I can tell you how it was done.

It's important to note that for primarily Windows shops, the Panther server can participate in an Active Directory environment as a member server, relying on the AD Master to handle authentication quite nicely. The setup of a Panther server as a PDC, however, is oriented mainly to Apple shops and those who wish to easily integrate Windows desktops without having to maintain a parallel server environment.

I have two Xservers in this configuration. The first acts as the primary authentication server housing the OD Master and the Windows PDC. The second server is the OD replica that handles authentication whenever the master is off-line, and it also acts as the file server.

Configuring the servers was relatively simple, though a few bugs required many hours to understand and develop work-arounds for. Hopefully, you'll be able to learn from my solutions and have a trouble-free installation.

Creating the OD Master and PDC is a selection that you make during the initial server setup. According to Apple Computer Inc., you should select a server to be the PDC during initial setup, because changing that option later will be problematic.

OD Master and PDC

To do so, simply choose a domain or workgroup name, enable Windows Internet Naming Service or enter the IP address of an existing WINS server, and check "enable virtual directory support." WINS maps Windows NetBIOS (machine) names to IP addresses and enables network browsing. Virtual directory support allows users to log in to a Macintosh or Windows machine in the domain and have access to their files.

OD Master and PDC

That is all you need to do during setup to enable Windows support on your Panther server! The next step is adding machines to the domain so that you can log in using an OD account. This process is the same as when the server is a Windows box. You run the network ID wizard, or right-click on "my computer" and "get properties." You will need to use a domain admin account and the naming convention DOMAIN\username or username@domain when entering your ID.

Once the machine has been added to the domain, you can log in using any account in the directory. You can also enable remote support and use Microsoft's Remote Desktop Connection for OS X to control the machines. I found that when adding the user ID to the authorized support accounts, I was unable to browse my OD catalog. However, I could successfully add a user by typing in his ID name using the DOMAIN\username convention.

The last part of this is getting the home directories and user profiles mapped properly.

If the user home directories are being shared using both Apple File Protocol and Server Message Block, then simply add the location of the user home in the Windows tab of workgroup manager. You must use Universal Naming Convention and pick a drive letter to map, or the share will not be mounted.

OD Master and PDC

As for roaming profiles, there is a bug in the system that prevents them from working on any other share except for the default Users share on the OD Master. You don't need to have the directory still working as a share, but the profiles will all be written there. Attempting to house the profiles on any other server will result in permission errors -- and frustration. So at this point, the home directory can be on any server in the domain, but the profiles must be on the OD Master.

This is a known bug, and Apple engineers are working to remove it.

I recently learned of another work-around for this issue. If you previously had the accounts on a Windows server, then copy those roaming profiles over to your share and set the permissions using these two command-line entries:

> chown root:admin /sharepoint/share

> chmod 770 /sharepoint/share

Yes, you could create the accounts on the Windows 2000 server and then move them over. It is a frighteningly kludgy solution, but if you can't put the profiles on the authentication server, then until this bug is squashed, you have a way to do this.

If you do host the user homes on a machine other than the PDC, there is another bug that quickly becomes obvious. It's in the implementation of Samba, where the server won't drop connections, meaning any user file activity will open another connection. I had 17 machines generate more than 200 connections in under an hour, effectively hanging up my machine. There are two solutions to this issue: The first is to edit the smb.conf file on the file server and add the following line near the beginning of the file (without the quotes): "dead time = 10". This lets the server drop unused connections after 10 minutes.

The other solution I found was in the Windows settings for the file server. It's completely counterintuitive to Windows structure but works in this case. I changed the machine from being a Windows domain member server to a stand-alone machine. This has the effect of forcing the server to use OD authentication instead of NT authentication, which in this implementation is the source of the problem.

Unfortunately, doing this introduces a possible security exploit, making it a stopgap solution until Apple fixes the flaw.

Well, that's it for this time. Did I miss something? Have something you'd like to say, or a question I might answer? If so, send your questions, comments and curses to

Looking for more Macintosh news? Be sure to sign up for Computerworld's biweekly Macintosh newsletter.


Copyright © 2004 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon