Peachpit Press

Working for Apples: A Windows Administrator's Guide to Serving Macs

Date: Dec 9, 2005

Return to the article

Are you Mac-savvy? Many Windows administrators and technicians have never had to support Macs on their networks, so the idea of suddenly having a handful of Mac workstations might seem really challenging. Luckily for you, it's an easier task than you probably think. Ryan Faas gives you a simple guide to supporting Mac workstations and Mac users within your Windows network.

For more information on the Macintosh, visit our Macintosh Reference Guide or sign up for our Macintosh Newsletter.

In any number of industries, there are companies or schools that have a handful of Macs. For the most part, these schools are dominated by Windows servers, workstations, and users, with an IT staff that’s competent at managing those Windows servers and workstations. But they often don’t have a great deal of experience in supporting Macs and Mac users. If that last sentence describes you, you’re one of the people that I’m writing this article for (and if you’re a Mac user in such an environment, you’re another). It isn’t a guide to all things Mac (and reading some good introductory Mac OS X user and troubleshooting books will probably be equally helpful for you), but it is a guide to how to support Mac workstations and Mac users within your Windows network.

There are two major sections to this piece: how to support Mac users accessing shared files and printers within a Windows network and how to integrate Mac workstations with an Active Directory domain. We’ll start with the easiest of the two first.

Windows Shares and Print Queues: Let the Server or the Mac Do the Work

Mac users almost always need to share files and be able to print to shared printers within a network. Whether they need to have their computers be part of a Windows domain is debatable. Often, administrators will find that capability more helpful than the users themselves. Luckily, access to the basic shared resources is pretty easy, and there are two approaches: have the Macs connect using the Windows SMB/CIFS protocol or install Services for Mac on Windows server hosting the resources and let the Macs access the servers using their native file- and print-sharing protocols (AppleTalk and AFP).

Letting Mac OS X’s SMB Client Do the Work

With the introduction of Mac OS X 10.1, Apple built support for the SMB protocol into Mac OS X itself (although it wasn’t until Mac OS X 10.2 that Apple included full and reliable SMB support). So, if you are supporting only Mac OS X workstations (particularly a small number of workstations) and your users are technically savvy enough (and most Mac users in Windows environments tend to be), you can simply rely on Mac OS X’s built-in SMB client.

SMB share points can be accessed using the Connect to Server command from the Finder’s Go menu or by browsing the network globe in a Finder window’s sidebar. When using the Connect to Server command, you would specify SMB as the connection protocol when connecting to a server’s IP address or DNS name (that is, smb://myserver.com). When browsing the network globe, Windows servers will be grouped by domain or workgroup name as they are discovered by either NetBIOS broadcast or through a WINS server.

After a user has chosen a server to connect to, an SMB client dialog box will display—allowing a user to specify his/her username and password for the server and the name of the Windows domain or workgroup to which the server belongs. Needless to say, the correct domain must be entered if the user will be using an Active Directory account. Once authenticated, a pop-up menu allows users to specify which of the share point on the server they want to mount. Users will need to mount each share point individually. Once mounted, they will display and behave as a Mac share point would. To speed things up a little, when using the Connect to Server command, users can specify the path to a share point (or a specific folder of file within it to mount a specific share point; that is, smb://myserver.com/mydepartment).

Accessing SMB Print Queues from Mac OS X

Access to SMB print queues is configured in much the same way as an LPR or AppleTalk printer in Mac OS X. Open the Print Setup Utility and click the Add button. Select Windows Printing from the first pop-up menu. Use the second menu to select from Windows domains or workgroups, or choose Network Neighborhood to browse the entire Windows network (which might be needed the first time you configure Windows printing because this menu defaults to listing the generic Workgroup item). After you have selected a domain or workgroup, you can select from the listed servers and then choose a print queue hosted by it. Use the Printer Model pop-up menu to configure an appropriate PPD for the selected print queue.

Microsoft Services for Mac

Windows servers (from NT 4 though 2003) include Services for Mac, a pair of optional services that are not included in the default Windows server installation. Services for Mac include File Services for Mac and Print Services for Mac, each of which can be installed independently of each other, and both of which can be added when the Window server operating system is first installed or at a later point. Services for Mac are included in the Other Network File and Print Services option in the custom Windows components dialog box during server installation and setup. They can be installed after the fact by using the Add/Remove Windows Components button in the Add/Remove Programs Control Panel. With Services for Mac installed, Mac users can connect to share points or print queues in the same ways that they would connect to such items hosted by a Mac Server.

Services for Mac adds the AFP and AppleTalk protocols to Windows 2000 or 2003 Server (under Windows NT, only AppleTalk installed), enabling it to provide AFP and AppleTalk access to share points and to share printers using AppleTalk. The AFP/AppleTalk file service needs to be configured globally for each server, and individual share points must be explicitly shared with AFP/AppleTalk. Share points can be configured as Windows (SMB) only or Mac (AFP/AppleTalk) only, or they can be shared using both file services. When an item is shared using both file services, it is effectively shared twice (once with each service). When Mac clients connect to the server, the server will accept both AppleTalk and AFP connections, but will prefer AFP connections whenever possible because of AFP’s greater performance.

Configuring Services for Mac and Choosing How to Authenticate Mac Users

You configure the Macintosh (AFP/AppleTalk) file service by right-clicking on the Shared Folders icon in either the MMC or the Computer Management application and selecting Configure File Server for Macintosh to access the File Server for Macintosh Properties dialog box, which includes three tabs: Configuration, File Association, and Sessions.

The Configuration tab includes four sections, most of which are self-explanatory. The first, Server Name for AppleTalk Workstations, is a text field in which you can enter the AppleTalk/AFP hostname for the server, which is automatically populated with the server’s NetBIOS name. The second section is where you can enter a Logon Message that will be displayed to users when they connect to the server using AppleTalk or AFP. The Sessions section at the bottom allows you to specify the number of concurrent AppleTalk and/or AFP connections that the server will accept.

The third section, Security, is where you specify how the server will authenticate Mac users. First, there is a checkbox, Allow Workstations to Save Password, which allows users to store their server password for automatic login (a feature that can be a security risk). The Enable Authentication pop-up menu enables users to specify how user passwords are sent to the server from workstations. The options include the following:

The File Associations tab allows you to automatically add creator and type codes that Macs have historically used instead of file extensions to determine file types. Services for Mac will create these for any files stored on a Mac share point based on the information on this tab. However, because Apple has included the capabilities for Macs to do this association on the fly for nearly a decade, the functionality is somewhat superfluous.

The Sessions tab displays the number of AFP/AppleTalk connections, the number of open files and the number open files. It also includes a text box for sending a message to all computers connected to the server using AppleTalk or AFP.

Beyond the Service: Configuring Mac File Shares

To create a share point for Macs (which Microsoft also refers to as a Mac Volume or SFM Volume), you need to use the Shared Folders tool in either the MMC or Computer Management[ms]unlike typical share points that can be created in Windows Explorer. Right-click an existing shared folder and select the option to share it as an SFM Volume. This creates a second share point for the folder.

A Mac share point’s Properties dialog box doesn’t contain a Sharing tab because permissions must be applied to Mac share points using NTFS permissions (which means that they can be created only on NTFS drives). The Security tab is still present and functions the same as it would for any other item.

There are a series of special security functions collectively known as SFM Volume Security on the General tab of a Mac share point’s Properties dialog box. The first function is Password, which allows you to assign a password to the share point. When users connect to it, they will see a dialog box that requires them to enter the appropriate password, regardless of whether they connect as Guest or use a Windows domain or server account. The second is a checkbox that allows you to make the share point read-only to all users who connect to it (regardless of any other permission assignments). The last is a checkbox to allow or deny Guest access to the share point.

What About Print Services for Mac?

When Print Services for Mac is installed on a Windows server, all print queues that you create are automatically shared over AppleTalk. There is no additional configuration that needs to be performed in order to make a print queue available for Mac users. Mac users cannot view the queue and manage print jobs as Windows users can. Also, it’s worth noting that Mac OS X 10.3 and higher supports configuring printers for use with Internet Printing Protocol (IPP). IPP is supported by Windows 2000 Server and above, although it does require additional configuration.

When to Use Services For Mac

Services for Mac provides a uniform framework for Windows administrators. However, the SMB capabilities built into Mac OS X make Services for Mac largely unnecessary. Services for Mac is extremely helpful if you are supporting workstations with older Mac OS versions such as those before Mac OS X and Mac OS X version below 10.2. In fact, much of the authentication options in Services for Mac are designed for pre-OS X Macs, meaning that Mac OS X only supports the unsecure Apple Clear Text password option for Services for Mac. Also, for further information, there are a couple of commercial products that do a better job of providing the same functionality as Services for Mac: Extremez-IP by Group Logic and MacServerIP by Cyan Software Ltd.

Another Alternative: Thursby System’s DAVE

For several years, Thursby Systems has developed a third-party SMB client for Mac users called DAVE. DAVE was developed before Mac OS X, and Thursby continues to provide both Mac OS X and classic Mac OS versions of the product. For situations where you need to provide support for Mac OS 8/9 workstations, DAVE presents an alternative to Services for Mac (or its third-party options). DAVE might be particularly attractive if you need to support only a handful of pre-Mac OS X workstations and don’t want to deal with a server-based solution. Thursby does provide a Mac OS X version of DAVE as well, which is best aimed at Mac OS X 10.0–10.1 workstations, though there is a small amount of functionality over Apple’s SMB client for more recent Mac OS X versions. Thursby provides a free and fully functional trial version of Dave from its website.

Integrating Macs with Active Directory

Now on to the more robust support of Macs in a Windows network. Macs can be integrated into Active Directory domains with or without modifying the Active Directory schema. The simplest solution is basic workstation authentication, which can be done without schema changes and allows users to log in to Mac OS X workstations using their Active Directory username and password. It also allows you to restrict users to specific workstations and login times (as you would do with a Windows workstation), to provide access to Windows home directories, and to provide Active Directory groups with local administrator access to Mac OS X workstations. If you are comfortable with modifying the Active Directory schema for Mac OS X support (a subject that goes well beyond what I could cover in this article), you can enable any level of integration you like, right up to supporting Mac OS X Server’s client management capabilities.

For pre-Mac OS X workstations, however, this is the end of the road for support options because they were not built with directory services in mind. The best you can do for network authentication (without relying on Mac OS X Server’s Mac Manager service) is to set them to mount a share point at startup, which can provide some authentication to them (as well as automatically mounting specific share points). However, users can elect not to mount the specified share point and still proceed to use the workstation.

Plugging Into Active Directory

With Mac OS X 10.3, Apple introduced the Active Directory plug-in for Directory Access (the Mac OS X utility that manages directory services configuration on each workstation). The Active Directory plug-in queries Active Directory using LDAP (as opposed to Microsoft’s proprietary Active Directory Services Interface, which is used by Windows clients). Apple designed the plug-in specifically for Active Directory’s default schema and took into account the common issues and concerns that exist when configuring LDAP access to Active Directory.

Unless the Active Directory schema is altered, Mac OS X Open Directory and Active Directory share three major user account attributes: username, password, and home directory. Apple’s Active Directory plug-in is designed to map several additional attributes to their counterparts (Mac OS X shortname to Windows logon name, for example). However, there are some attributes in the Open Directory schema that have no corresponding attributes in Active Directory. Attributes that specify user environment type, managed preferences settings, and the user ID number, for example. The Active Directory plug-in can make standardized assumptions about some of these items such as Environment type, which can generally be assumed to be the Mac OS X Finder (as opposed to the simplified Finder or command-line interface). Those that can’t be mapped or assumed, such as those that specify managed preferences settings, are ignored when the Active Directory plug-in is used, resulting the use of the standard Mac OS X default settings.

The user ID number (UID) is the most important attribute for the user account object for which Active Directory has no directly corresponding attribute. This csn create a problem because the Mac OS file system uses the UID to identify owners of files and to identify whether users are members of groups that have access to files. This isn’t a problem for files residing on a Windows server, because access to those files are assigned using Active Directory user accounts and therefore don’t require a UID. However, files created on Mac workstations still rely upon UIDs.

The Active Directory plug-in provides two options for working around this problem. The first (default) option is for the plug-in to dynamically generate UIDs for users that login using Active Directory accounts. It does this by combining information from the Global User ID (GUID) Active Directory attribute for a user’s account with information from the workstation’s MAC address. The dynamic UID is then used for access to any local files on the workstation that the user creates. This works well if users always log in at the same workstation because their dynamic UID will always be the same. If a user moves between workstations, his/her dynamic UID will be different at each workstation, but at each workstation, it will always be the same. If the user attempts to connect to a Mac where he/she has created files remotely or if there is a Mac OS X Server on the network, however, the UID from one workstation will not match that of the second workstation, and the user will not be able to access the files if he/she changes workstations. If you have only a handful of Macs and no Mac OS X Server (or users turning on file sharing on their workstations), you can generally be fine using dynamic UIDs.

The second way that the Active Directory plug-in can provide UIDs is that you can choose an attribute within the Active Directory schema to be mapped to the UID attribute of Open Directory. You can use one of the default Active Directory attributes that you are not using for its original purpose (such as telephone number or address, for example) or by extending the Active Directory schema with a custom attribute for the UID. This method allows you to assign actual UIDs to users (whether or not you extend the schema to include a UID attribute). Users will always have the same UID, regardless of workstation. However, you will need to populate the UID field manually for every user.

Configuring the Active Directory Plug-In

You use the Directory Access utility (located in the /Applications/Utilities directory on Mac OS X workstations) to configure Active Directory authentication. Ensure that the Active Directory plug-in is enabled on the Services tab. Then double-click the Active Directory plug (or select it and click the Configure button).

Enter the fully qualified DNS names for the forest and domain in the respective fields (see Figure 1). For forests containing a single domain, they will be the same. The Computer ID field indicates the NetBIOS name that will be used for the workstation’s account in the domain. Like any Windows workstation, a Mac OS X workstation joined to an Active Directory domain will be assigned a computer account. Because Mac OS X does not recognize Active Directory domain policies for computer accounts, it is possible (though not advisable) for multiple Mac workstations to use a single computer account. After entering the information in these three fields, you can join the workstation to the domain by clicking the Bind button. You will be asked to enter the username and password for an account with authority to join the computer to the domain (if a computer account doesn’t already exist, you’ll need to enter an account with the authority to create computer accounts). If the search base for your domain differs from a default Active Directory search base, you will be asked to specify the search base so that the Active Directory plug-in can locate the appropriate account.

Figure 1

Figure 1 Active Directory plug-in configuration dialog box for Directory Access.

There are also a number of advanced options available when joining Macs to an Active Directory domain. They are divided into three tabs (seen when Show Advanced Options is selected for the Active Directory plug-in configuration dialog box): User Experience, Mappings, and Administrative.

The User Experience tab includes options for creating a Mac OS X mobile account for users when they log in (which caches their credentials and allows them to log in when not connected to the network), to force a local home directory on the workstation rather than on a server (if one is designated in their Active Directory user account) and how that home directory is to be accessed, and to specify the default Unix shell for the user. The Mappings tab allows you to turn off dynamic UID generation and specify the Active Directory user object attributes to be used for UID, primary group ID, and group ID.

The Administrative tab allows you to designate a preferred domain controller for authentication. (This will override any settings made in Active Directory Sites and Subnets, although if the designated domain control cannot be contacted, the Mac will failover as appropriate to your Active Directory configuration.) It also allows you to specify domain groups whose members will be automatically granted local administrator access when they log in to the Mac workstation. Lastly it includes an option to allow authentication for login of users in any domain in the forest rather than just users in the domain to which the workstation was joined.

Once the Active Directory plug-in has been configured, you will need to add the Active Directory domain to the workstation’s search path using the Authentication tab in Directory Access. Choose Custom Path from the Search pop-up menu on the Authentication tab. Then use the Add button to locate and add the Active Directory domain to the search path. Also, make certain that the Login Options tab of the System Preferences Accounts pane specifies that users will type their username and password rather than using a list before logging out because the user list will not contain Active Directory accounts. Once this is done, you can log out of the workstation and log in using an Active Directory user account to test the configuration.

For more information on the Macintosh, visit our Macintosh Reference Guide or sign up for our Macintosh Newsletter.

© 2024 Pearson Education, Peachpit. All rights reserved.

1301 Sansome Street, San Francisco, CA 94111