• Article

Cross-Platform Security

Yes, You Can! Secure Your Mac On A Windows Network

Jay Shaw

 

At a Glance:

  • Connecting a Mac to your Windows-based network
  • Configuration of different Mac OS versions
  • Security considerations and network services

Mac OS

Windows

Services for Macintosh

Active Directory

If you work in network support for Windows, sooner or later it's bound to happen. You'll be sitting quietly at your desk, and someone will walk up with a long list of questions about their Apple Macintosh computer. How do we connect it to the existing

network? How will users access file shares, print, browse the Internet, and use e-mail? What do you do? You don't know anything about a Mac beyond plugging it into the wall. In a perfect world, you could plug in any device and go to work. Unfortunately, it's a little more involved than that. It isn't as hard as it sounds, though, nor is it as difficult as it used to be. Just remember that there is more than one way to peel an Apple!

First, you need to determine which Mac OS you're working with. If you need to support only the Classic Mac OS (OS 9.x or older), your choices are simple, but limited. Obtaining support for the platform will become increasingly more difficult as time progresses. Supporting Mac OS X is more complicated, but you also have many more options at your disposal. You might need to support both versions of the OS. You can provide file and printer sharing on either platform. More advanced functionality like integration with Active Directory® is only available in an OS X environment, and requires a little more planning.

Services for Macintosh

If you only need to support the Classic Mac OS or need both Classic and OS X, the best approach is to install Services for Macintosh (SFM) on your server running Windows®. Once it is loaded, the server can designate directories as Mac-accessible volumes. These volumes can be seen from machines running either the Classic Mac OS or OS X, and can even be shared with Windows-based clients at the same time. The server running Windows stores the Mac files on NTFS volumes and ensures that NTFS file names are properly supported.

SFM also allows for support of the Classic Mac file format. Classic Macs store files in two pieces called forks: a data fork and a resource fork. As the name implies, the data fork contains data. For executables, this is where the program's instructions are stored. The resource fork contains the file's resources, which can include items like icons, sounds, font, and images. SFM permits the server running Windows to store both forks in a single file.

Once you have loaded SFM and configured file permissions, you can connect to your server from a Mac, but note that file permissions for the Mac and the PC are configured separately. You will be required to authenticate using your domain user name and password for resources. While this is important functionality, it only provides basic file sharing. It also only allows you to serve files in one direction: Windows-based server to Mac.

In the past, it was necessary to load the AppleTalk protocol to support Macintosh clients, but Windows now supports Apple File Protocol (AFP) over TCP/IP. This means that your Mac volumes are available to your clients through TCP/IP. The AppleTalk protocol is no longer needed in many cases. Even Apple has moved on and no longer promotes its use. However, keep in mind that if you want to eliminate AppleTalk, you will need the DNS name or the IP address of the server you want to connect to. You cannot browse for Apple resources without AppleTalk.

If you want to continue to use the AppleTalk protocol, the Windows-based server can act as an AppleTalk router. It also has the ability to seed or define your AppleTalk network exactly as if it was a native Macintosh server.

Apple provides a client or User Authentication Module (UAM) right out of the box in both the Classic and OS X environments for connection to SFM, but it's not a very secure solution. It only supports eight-character passwords. This invariably causes problems when users with longer passwords attempt to access a resource. UAM also does little to hide these passwords as they travel over your network, for little or no encryption is applied. Because of these shortcomings, it's important to use the Microsoft UAM instead. The UAM supports 14-character passwords and uses stronger encryption. SFM and UAM are available as free downloads from the Microsoft Web site at Windows 2000 SFM.

While this solution does provide a good deal of functionality, there are still a number of limitations. For example, Classic Macs are often configured without a centralized login—you log in to each resource separately. You only have access to folders configured as Mac volumes on Classic Macs. Browsing for resources is very limited. Shares must be configured twice if you need access to the same files from the PC and the Mac, and security is not very robust. There is also no support for Distributed File Shares (DFS), file shares that are spread across several servers to provide better redundancy.

Printing is a little more flexible, however. By loading print sharing for Macintosh on your server, you will have access to any printers that have been shared from your Windows server on the Mac clients. Any AppleTalk printers connected to the network can be configured for use by any of the Windows-based clients as well.

When Macintosh printers are shared using SFM, the Windows-based server captures them. This means that print jobs sent from Mac clients are spooled to the server first. They are then converted to a bitmap format recognizable by the Windows-based printer driver and then sent to the printer. This allows you to manage Macintosh print jobs in the Windows-based print queues along with any other print jobs that were sent from computers running Windows. While this does work, it's not always the best solution. There are often problems when the print jobs are converted. Printouts are not always accurate, and sometimes don't print at all. Driver problems also plague this configuration.

In a larger environment, it is often necessary to manage print jobs in this manner. When in a smaller environment, however, it's usually best to allow the Mac clients to bypass the Windows-based server and print directly to the printers. Although you lose central control, the jobs will print properly most of the time. This can be accomplished in a few different ways. Many printers have native support for AppleTalk, in which case the printers will show up on the Macs as AppleTalk devices, allowing you to print directly to them. Another possibility is to print through TCP/IP directly to the printer.

Native OS X Support

If you don't need to support the Classic Mac environment at all, you may be able to get all the functionality you need right out of the box with OS X. OS X has the ability to access Windows-based shares without any additional server-side configuration. To access a file share, tell the Mac which server and share you would like to connect to, and then authenticate. Press Command-K, or select Go | Command to Server... from the Finder menu, and the related dialog box should appear (see Figure 1).

Figure 1 Mac Server and Share Authentication Dialog Box

Figure 1** Mac Server and Share Authentication Dialog Box **

Enter your file share following one of the formats shown here:

smb://servername/sharename 
smb://fullyqualifieddomainname/sharename

You will then be prompted with a login screen similar to Figure 2.

If you enter your domain, username, and password, you will have access to the share. The only configuration requirement for this is that you must use TCP/IP. Permissions are set on the server and are tied to your domain login. OS X doesn't require any special file space or configuration, and files do not require a resource and a data fork. In fact, the files look as if they came from a machine running Windows. You still must log in to each resource and you're not integrated with Active Directory, but you can get to file shares a lot more quickly. As an added bonus, OS X can be configured to show up in a workgroup and share files with your Windows-based machines as well.

Figure 2 Macintosh Share Login Screen

Figure 2** Macintosh Share Login Screen **

There is one caveat: you must know where you're going. Because you are not integrated with Active Directory, you cannot browse for resources past your local subnet. If a resource is remote, you need the server name or IP address and the name of the share to which you would like to connect.

Printing on a Windows-based network from OS X is a little more involved. First, you must open System Preferences | Hardware | Print & Fax, click Set Up Printers, and then click Add. Next, select Windows Printing, then choose your correct domain from Network Neighborhood. Select your server and you will be prompted to log in. Once you have authenticated, a list of available printers will be displayed. Select the printer you want to use and then select the correct driver from the Printer Model dropdown list. You should now be able to print. Printers attached to your OS X machine can be made available to Windows-based clients as well.

So how did Apple make such a jump in functionality? For years, users have been struggling with added services and third-party applications like Dave from Thursby Software. When Apple scrapped the Mac Classic operating system in favor of OS X, much of the work was done for them. Because OS X is based on Unix, Apple was able to integrate Samba, a group of open-source Unix applications that use the Server Message Block (SMB) protocol. This is the protocol used by Windows for client-server networking. As such, Apple inherited most of this functionality from its Unix background. This has not been a trouble-free transition, however.

On a large network, problems quickly arise. You still need to log in to each and every resource you access. This quickly becomes cumbersome on all but the simplest of networks. In addition, the Mac client is not a domain member, which means that there is no domain login account for it. You cannot map your home directory during login. Browsing for resources is very limited—you can only browse on your local subnet. Security becomes an issue because the Mac can cache the user names and passwords for the resources it uses. Without an Active Directory login, someone could easily gain access to a Mac client and related domain resources with the locally cached login information.

The Apple OS X Active Directory Client

Apple has finally given us a way to connect to Active Directory. In fact, Apple has been working on its Active Directory client for some time, but it has been plagued by bugs and has been very difficult to configure. Some administrators have had success, but even these modest results have typically been difficult to reproduce.

Macintosh Direct Access Client Configuration

  1. Open the Direct Access Utility.
  2. Click Enable next to Active Directory, and then click Active Directory.
  3. Click Configure, then enter your Active Directory Forest and Domain.
  4. Enter a computer ID for your Mac client.
  5. Click Unhide Advanced Options, and select the Cache Last User Login for Offline Operation and Allow Administration by: check boxes.
  6. Add the usernames and groups that you want to give administrative access to your Mac in the format domain name\user or group, and then click Bind. You will be prompted for a user account with rights to join your domain.
  7. Click OK and then click Authentication at the top. Make sure Active Directory is still highlighted.
  8. Click Custom Path in the Search dropdown list, and then click Add at the bottom.
  9. Select your Active Directory Domain from the list and click Add.
  10. Click Contacts, and then Add.
  11. Click Apply and close the Directory Access window.

Early implementations of the Apple client required you to make complicated schema changes to Active Directory in order for it to work. This is quite difficult and time consuming. Once these changes are made, the functionality is not as robust as one would hope. When it is working, domain users can authenticate on a Mac and gain access to resources on the domain. However, browsing remains a problem as do home folders, which I'll discuss later.

Apple recently released OS X 10.3.4. It's important to have this update when using Apple clients because it apparently has resolved many issues, but it's still not perfect. A single Active Directory login is now supported without making any schema changes in Active Directory. This means that you can configure a Mac to allow domain user accounts to log in, and you can do away with local user accounts. Password changes and updates are supported from the Mac, as are cached passwords for access to your account when you're not connected to the network. You also have the ability to grant administrative access through user names and groups from Active Directory. Hourly login restrictions are supported as well.

There is also some support for home folders. You can map a user's home folder during login based upon their profile in Active Directory. This is especially useful when users have both PC and Mac computers. You can use a single login and mount your home folder on the Mac, then use it again as your home folder on the PC. This makes for easy backup and convenient access to all of your work. Unfortunately, you cannot use this mapped directory as your home folder—there is still a separate home folder for each user account locally on the Mac, which often causes confusion when users are saving files and looking for them later. Sometimes users think they have saved a file on the server-based home folder, when in fact these files are located on the local Mac drive. DFS volumes also remain unsupported. This can be a big problem in an enterprise-level environment, as there will be resources that the Mac cannot access.

The client is configured in OS X with a utility called Directory Access, located in the Applications | Utilities folder. When you open the utility, click Enable next to Active Directory, and then click Active Directory. From this screen you can click Configure, and then enter your Active Directory Forest and Domain. Enter a computer ID for your Mac. Click Unhide Advanced Options, and select the Cache Last User Login for Offline Operation and Allow Administration by: check boxes. Add the usernames and groups to have administrative access to your Mac in the format domain name\user or group, and then click Bind. You will be prompted for a user account with rights to join your domain. Click OK and then click Authentication at the top. Make sure Active Directory is still highlighted. In the Search dropdown list, click Custom Path, and then click Add at the bottom. Select your Active Directory Domain from the list and click Add. Now click Contacts, and then Add. Last, click Apply and close the Directory Access window. After you restart, you should be able to log in with a domain user account and password.

Perhaps this still isn't enough for your users. Do you need even more from Active Directory? Apple has an update to OS X, version 10.4 (code-named Tiger), due out next year, that promises to solve some of the security and configuration issues and provide cleaner integration with Active Directory login and home directories. Unfortunately, Apple has a history of dangling the promise of such features in front of its customers without delivering, so we'll have to wait and see.

ADmitMac to the (Costly) Rescue

Alternatively, you might want to take a look at ADmitMac from Thursby Software. ADmitMac is an enhanced Active Directory client for OS X. NT LAN Manager version 2 (NTLMv2) and SMB signing are both supported. This provides enhanced security when connecting to Windows Server 2003. If you need access to DFS, ADmitMac is the only product I know that supports it through OS X. ADmitMac also allows you to map server-based home folders for use as home folders on both the Mac and the PC. This means that users who have both a PC and a Mac can have the same home files available to them on either platform, with a single account and no chance of confusion between the two. ADmitMac can also search published resources available in Active Directory. All this is done on the client side with no schema changes to Active Directory. Nevertheless, don't get too excited—this sounds very promising, but there is a catch, as ADmitMac currently costs $119 per client. However, you can download a trial version at: Thursby Software. I love to use ADmitMac because it provides so much support for the added services of Active Directory, but it can become quite expensive if you have a lot of Mac clients.

So, which approach is best? In most of the mixed environments I support, I use SFM simply because there always seems to be a Classic Mac left hanging around somewhere. Unfortunately, this is only a halfway solution and can often be clumsy, confusing, and insecure, particularly when other products offer so much more functionality.

Active Directory integration on OS X has been referred to as "The Holy Grail" for Apple and its implementation of an Active Directory client is improving with each release. The first white paper released by Apple on Active Directory integration was over 40 pages long. Hopefully, their client will get better with time, but there are still many problems. Fixing them would certainly make integration decisions a lot easier.

Jay Shaw is an independent network consultant. His company, Network Consulting Services, is located on Long Island in New York. He can be reached at info@ncservices.net.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.