SolutionBase: Configuring a MacIntosh to work in a Windows domain

So you've got your Mac workstation and want to connect it to your Windows domain. What do you do? This article shows how to make Macs and Windows play nice together.

Chances are, you probably have a few Macintoshes somewhere in your organization. Equally probably is the fact that you'd have to use deadly force to remove those computers from users who rely on them. Instead it's up to you to figure out how to make them work on your network. Here's how to enable Macintosh users to log into your Windows network and share files with PC users.

The File Server For Macintosh service

If you are a Windows Server administrator, you are probably familiar with the way that Windows allows you to share folders and then set permissions to those folders to grant or deny access to various users. In Windows shares are based on SMBs. In the Macintosh world, there is a similar file sharing technology. However, the Macintosh version uses something called Apple File Protocol (AFP). Although it has a similar function, AFP and SMB are not compatible.

This means that we need a way of making a Macintosh be able to access a Windows file share. As you may recall, our original goal from part one of this article series is to incorporate a Macintosh based graphics department into the corporate network. Since the network is based on Windows Servers, we probably want to structure things so that the Macintosh users are saving their files onto Windows Servers. In order for that to be possible though, several things have to happen.

First, the Macintosh users have to be able to log into the Windows network. Although the Macintosh network and the Windows network both use TCP/IP, the Macintosh machines have no concept of Windows domain controllers. Therefore, you have to either configure the Macintosh machines to recognize the Active Directory, or you will have to configure your Windows network to accept a login from a Macintosh.

I personally recommend configuring Windows to accept a Macintosh based login. Doing so is a lot easier than configuring a Macintosh to work with Active Directory. Of course logging in is just the beginning. After the authentication process completes, the Macintosh machines need to be able to locate Windows based resources (remember, Macintosh uses the AppleTalk protocol for locating resources), and they need to be able to access the Windows file system.

The key to pulling this off is to use the File Server for Macintosh (FSM) service. There are a few issues with the authentication mechanism that we will have to address later on, but the first step is to install the FSM service. The FSM service provides Windows Server 2003 with the ability to communicate via the AppleTalk protocol, understand AFP, and to accept the Apple authentication process.

To install the FSM service, select the Add/Remove Programs command from the File menu. When the Add or Remove Programs dialog box appears, click the Add/Remove Windows Components button. After a brief delay, you will see a list of the available Windows components. Scroll through the list until you find the Other Network File and Print Services option. Select this option and click the Details button. On the following screen, select the File Services for Macintosh check box. There is also a Print Services for Macintosh check box, but don't select this option right now. For now, let's just focus on the file services. Click OK, followed by Next. Windows will now install the FSM service. Click Finish to complete the installation process.

Now that the FSM service has been installed, it's time to configure it. To do so, select the Computer Management command from the server's Administrative Tools menu. When you do, the Computer Management console will open. Navigate through the console tree to Computer Management (Local) | System Tools | Shared Folders. Now, right click on the Shared Folders container and select the Configure File Server for Macintosh command from the resulting shortcut menu. When you do, you will see the File Server For Macintosh properties sheet, as shown in Figure A.

Figure A

You can configure FSM through the File Server For Macintosh properties sheet.

The first thing that you will need to fill in is the Server Name for AppleTalk Workstations option. Normally, this will be the server's computer name. The name that you enter here is the name that Macintosh users will see through the Chooser.

The next option on the properties sheet's Configuration tab is the Logon Message. Macintosh users will see this message after they log into the Windows Server. My recommendation is to keep this message short or don't use it at all because it can get a little annoying after a few days.

Just below the Logon Message field is the Security check box. If you select this check box, then Macintosh workstations will locally store a copy of the Windows network's password. If you care at all about your network's security, then do not select this check box.

Now we are getting to the important stuff. As you may recall, earlier I mentioned that there were a few issues with the authentication mechanism that you would have to overcome. The problem is that Windows Server 2003 absolutely will not store Apple passwords in anything other than clear text. Obviously, this is a huge security concern. There is a way around the problem, but it's a bit of a Catch 22. Microsoft has created something called a Microsoft User Authentication Module (UAM).

The UAM's purpose is to allow Macintosh clients to log into the network in a similar manner to Windows clients. The problem is that the UAM module is stored on the Windows Server in a special folder. Incidentally, UAM based authentication is the default option. If you look at Figure A, you will notice that the Enable Authentication option is set to Microsoft Only. However, clients can't use UAM based authentication until they have logged in to download the UAM module.

The solution lies in choosing the correct option from the Enable Authentication drop down list. I already explained why the Microsoft Only option won't work (for now). The next option on the list is Apple Clear Text. Apple Clear Text would technically work, but you really don't want passwords sent and stored in clear text. Besides, if you enable the Apple Clear Text option, then clients won't be able to log in once they download and install the UAM module.

The next option on the list is Apple Encrypted. Don't let this one fool you. The Apple Encrypted option causes workstations to encrypt the password prior to sending it to the server, but the password is still stored on the server in clear text. Besides, once again UAM based logins will fail if this option is selected.

The last two choices on the list are Apple Clear Text or Microsoft, and Apple Encrypted or Microsoft. Both of these choices will get the job done because they support both Apple and UAM based authentication. I recommend initially going with the Apple Encrypted or Microsoft option because it would be nice to have passwords encrypted as they are sent to the server. You could then make it mandatory for clients to install the UAM module. You can continue to use the Apple Encrypted of Microsoft option during the transition period and then switch to the Microsoft Only option once everybody has the UAM module installed.

Of course if you hire a new employee or if someone gets a new computer then you will have to go back to using the Apple Encrypted or Microsoft option until the new employee or computer has the UAM module installed. If you work in a place with a high turn over of employees or computers then it might be better to just leave the Apple Encrypted or Microsoft option set.

Installing the UAM module

OK, so your Macintosh users can log in, but how do they install the UAM module? To install the UAM Module, have your users click on the Apple menu and select the Chooser command. When the Chooser opens, have the user select the AppleShare option. When AppleShare is selected, the right side of the screen will display all of the resources that can be accessed through the AppleShare protocol.

Have the users to locate the Windows Server on the list and then select it. With the server selected, the users should click the Server IP Address button and enter the server's IP address in the space provided. This will allow the machine to talk to your server using TCP/IP in the future, rather than having to rely on AppleTalk.

At this point, the user will see a logon prompt. The users should enter their Windows logon credentials. The users will now see a dialog box that displays any Macintosh accessible volumes on the server. The users should select the Microsoft UAM Volume and click OK. The user will now see a dialog box confirming connection to the UAM volume. Click OK and the UAM volume will now show up as a network drive on the machine. The users can now open the volume and double click the MS UAM Installer. When the installation completes, the users will see a confirmation that the UAM module was installed.

The File Association tab

Now that I have discussed authentication and UAM modules, let's get back to the File Server For Macintosh properties sheet. The next tab on the properties sheet is the File Association tab, as shown in Figure B. Although you don't have to do anything with this tab right now, it's important that you understand what it is and what it does.

Figure B

The File Association tab helps to translate between PC and Macintosh file names.

As you are no doubt aware, files in a Windows environment have two parts, there is the filename and the file extension. The file extension helps the operating system to know what type of file a particular file is. For example, an .EXE file is an executable file, while a .DOC file is a Microsoft Word document. Windows uses a table to associate file extensions with the programs used to open them. For example, if you were to double click on a .DOC file, Windows would open Microsoft Word and load the file that you selected. This happens because the file association table has associated Microsoft Word with the .DOC extension.

Macintosh computers also use file associations, but they work a lot differently. In a Macintosh environment, there are two parts to every file. A file has a data portion and a resource portion. The resource portion of the file defines the file type and defines the file's creator. The creator is Macintosh speak for the application that's associated with the file. This two pronged file structure is known as a resource fork.

Although Windows file extensions do basically the same things as Macintosh resource forks, they are not compatible with each other (Except for OS X, but that's another story). If you move a Macintosh file to a PC and then back to a Macintosh, the Mac will have no idea of what to do with the file because the PC will strip away the resource portion of the file. On the other hand, if you have files stored on a PC and you allow a Macintosh to access those files. The Macintosh will make a real mess of the volume holding the files. It won't actually hurt anything, but the Mac will leave resource fork files behind.

This is where the File Association tab comes into play. The File Association tab is designed to map resource fork information to common file extensions

The Sessions tab

The Sessions tab, shown in Figure C, displays the number of connected Macintosh sessions, and the number of open file forks and file locks. The Sessions tab also allows you to enter and transmit a message to all connected Macintosh machines. For instance, if you needed to bring the server down for maintenance, this tab would allow you to see how many users were connected and to send them a message stating that you are taking the server down in five minutes.

Figure C

The Sessions tab, shown in Figure C, displays the number of connected Macintosh sessions, and the number of open file forks and file locks.

While I am on the subject of sessions, go back to Figure A for a second. If you look at the bottom of Figure A, you will notice that Windows initially allows an unlimited number of simultaneous Macintosh sessions. However, if you were concerned about running out of Windows client access licenses or if your server was suffering from performance problems, you could limit the number of concurrent Macintosh sessions.

Creating a Macintosh-accessible share

The final step in the process is to create a Macintosh accessible share on your server. There are two things that you need to be aware of up front though. First, you will need to decide off the bat if the share will be accessible to Macintosh only or to both Macintosh and Windows. Second, regardless of any permissions you assign, the share will be read only to Macintosh clients and you will have to manually remove the Read only flag.

To create the share, go to the Computer Management console. Right click on the Shares container and select the New Share command from the resulting shortcut menu. When you do, Windows will launch the Share a Folder Wizard.

Click Next to bypass the wizard's Welcome screen. You will now be prompted to enter the path to the folder that you want to share. After doing so, click Next. You will now see a screen similar to the one shown in Figure D. On this screen you must select whether the share will be accessible to Windows, Macintosh, or both. You must also enter share names and an optional description of the share.

Figure D

You must decide whether the shared folder will be accessible to Windows, Macintosh, or both.

Click Next and you will see the screen shown in Figure E. This screen allows you to set the permissions that will apply to the shared folder. As you can see in the Figure, the wizard tries to keep things simple for you, but you can enter custom permissions if you choose. Keep in mind that these are share level permissions, not NTFS level permissions.

Figure E

This screen allows you to set the share's permissions.

Click Finish, followed by Close to create the share. Don't forget what I said about Windows making the share read-only by default though. If you need to remove the read only attribute then select the newly created share in the Computer Management console. Right click on the share (there are separate shares for Macintosh and Windows, make sure that you choose the Macintosh share) and select the Properties command from the resulting shortcut menu. When you do, you will see the share's properties sheet.

Now remove the check mark from the This Volume is Read Only check box at the bottom of the General tab, shown in Figure F.

Figure F

Macintosh shares are read only by default.