One of the most remarkable features that Microsoft included with Windows NT Server is the capability to act as a fully functional file server for Macintosh clients. Services for Macintosh, which provides this functionality, turns Windows NT into not only a fully-compliant AppleShare file server that can support an unlimited number of Macintosh clients, but also a Macintosh print server and a native AppleTalk router.
This chapter examines the pieces that compose the Services for Macintosh, as well as the tools that are used to administer them. I've included some concepts of how to plan and implement your NT network to include Macintosh clients, and provided essential information for NT administrators new to the Macintosh world. I've also tried to make it useful for people coming from a Macintosh world who are new to NT Server by presenting the chapter in a capsulized format.
AppleShare File Server
Windows NT Server enables Macintosh and PC users to access the same files, which provides a true cross-platform, collaborative environment. When running Services for Macintosh, DOS and Windows users connect to the server as they normally would. They see no evidence that they might be sharing files with Macintosh users. Additionally, Macintosh clients see and connect to the NT Server in the exact same way they would connect to any other standard AppleShare server.
To create an enterprise-level solution for Macintosh clients, Microsoft leveraged many of the features integral to NT's architecture when designing Services for Macintosh. NT Server provides exceptional compatibility, performance, scalability, fault-tolerance, and security. For instance, part of the Macintosh file server portion, known as the AppleTalk Filing Protocol (AFP) server, runs inside the NT Executive, which provides significant speed benefits. Also, because the AFP server is multithreaded, it can fully leverage NT's capability to run on multiprocessor hardware. You can also take advantage of the software RAID options in Windows NT to provide increased performance and reliability. Furthermore, Services for Macintosh fully integrates with the NT security model to provide the same level of high security available to all Windows NT clients.
The AppleTalk Filing Protocol (AFP) is a protocol that resides in the presentation layer of the ISO's OSI Reference Model. It is responsible for handling the logistics of accessing files and directories on a remote computer system.
There is no hard-coded limit as to the number of simultaneous Macintosh clients that can connect. To demonstrate the extensibility of Windows NT Server as a Macintosh file server, Microsoft has conducted real-world testing where they created over 1,000 simultaneous Macintosh connections to a single NT Server.
Because of the scalability of NT Server, it provides the most powerful Macintosh file and print services on the marketeven better than any system Apple currently sells. In fact, a recent alliance between Microsoft and Apple should bear fruit in the near future, and there is a good likelihood that Apple will sell NT Server-based solutions under their own label.
AppleTalk Print Server
In addition to acting as a standard file server, Windows NT can also act as an AppleTalk print server. This leverages three important pieces of Windows NT's print architecture. First, Windows NT permits Macintosh clients to print to any printers available on the NT Server. It even allows the Macintosh clients to print to non-PostScript printers by providing a PostScript interpreter that generates a bitmapped image that can be sent to any non-PostScript printer. Second, Services for Macintosh leverages NT's capability to print to a number of remote network printers, including network printers using DLC, TCP/IP, and AppleTalk. Third, it exploits NT's capability to print to almost 2,000 different models of printers.
To complement the file and print services, NT also includes a full AppleTalk router. This provides you with the ability to natively participate in an AppleTalk inter-network. The router can be configured to route AppleTalk between any standard network card supported by Windows NT, including Ethernet, FDDI, Token Ring, and even LocalTalk.
Windows NT supports the Daystar Digital LocalTalk adapter.
You can also use the AppleTalk router to create new AppleTalk zones on local subnets, through a process known as seeding, which provides logical organization of the AppleTalk network.
Understanding the Macintosh
There are mostly two types of people who will read this chapter:
The Windows-oriented LAN administrators who often begrudgingly have to support Macintosh clients on their LAN.
Macintosh network administrators with minimal NT and Windows experience, who needed a file and print server that could support a large number of clients.
I have written this chapter to be as useful as possible to both audiences. No matter which category you fit into, or even if you don't fit into one of these two categories, you'll probably find a discussion of the differences between the two platforms useful.
A little terminology review is definitely in order. Traditionally in the MS-DOS and Windows environment, files were stored in directories and subdirectories. Macintosh nomenclature has always referred to folders and subfolders, which are functionally identical. With the introduction of the Windows 95 interface, Microsoft has begun using the terms folders and subfolders to replace the traditional directories and subdirectories. In this chapter and elsewhere in this guide, I use the terms interchangeably.
AppleTalk and Apple Networking
It would be impossible to cover all the concepts of Macintosh networking in this single chapter, but there are a few important concepts that should be understood about before continuing. This section will be especially useful for a person with minimal Macintosh background to hit the ground running with Services for Macintosh.
AppleTalk, LocalTalk, EtherTalk, TokenTalk, and FDDITalk
If you're new to the Macintosh arena, you'll quickly recognize that Apple is very big on using the word Talk in naming its communications products and technologies. Of course, since networks are used to communicate, Talk is an appropriate word. However, keeping all these terms in order and using them to describe the appropriate technologies and products can often take a little practice, so let's do a quick review:
AppleTalk: When Apple designed the Macintosh, they recognized the need to be able to interconnect the computers for sharing files and printers. They developed hardware and software, collectively called AppleTalk, for performing this communication and built it into every single Macintosh computer ever made. Originally the term AppleTalk referred to both the hardware that was used to connect the computers, as well as the protocol suite that provided a language and set of rules for the computers to communicate. However, in the late 1980's, Apple separated the hardware from the software. The software componentthe protocol suiteretained the name AppleTalk, while the hardware component was renamed to LocalTalk. This is often a great source of confusion, and people still use the terms interchangeably. However, AppleTalk only properly refers to the AppleTalk protocol suite.
LocalTalk: All Macintosh computers have the built-in capability of supporting LocalTalk. To connect two Macintosh computers in a LocalTalk network, you can simply plug a LocalTalk connector into the printer port on the back of each computer and connect the two with a LocalTalk cable. LocalTalk is a synchronous RS-422 bus that transmits data at 230,400 bps (bits per second). When the Macintosh was first introduced in 1984, this speed was acceptable for most applications, however, today LocalTalk is not considered fast enough for anything more than basic small file transfers, or for sharing printers.
Macintosh computers traditionally use the printer port as the designated LocalTalk port, although newer Macintosh computer, and newer versions of the Mac OS actually permit you to use either the printer port or the modem port.
EtherTalk: EtherTalk is the name for running the AppleTalk protocol over an Ethernet network. The AppleTalk stack defines four link access protocols (LAPs) at layer 2 of the ISO's OSI Reference Model. The EtherTalk Link Access Protocol (ELAP) was the first of these to be introduced. The other three are LLAP (LocalTalk Link Access Protocol), TLAP (TokenTalk Link Access Protocol), and FLAP (FDDI Link Access Protocol).
TokenTalk: The name for running AppleTalk on a Token Ring network.
FDDITalk: The name for running AppleTalk on a FDDI network.
AppleTalk Phase 1 and Phase 2
When Apple first designed AppleTalk, there were a number of limitations, which as networks grew, began to cause problems. This original release of AppleTalk, is now known as AppleTalk Phase 1. In 1989, Apple redesigned the AppleTalk protocols to support larger and more complicated networks. The new version of AppleTalk is known as AppleTalk Phase 2.
Windows NT Server only supports AppleTalk Phase 2.
The original version of AppleTalk only permitted 254 nodes on an entire physical network, because nodes were addressed using a single 8-bit node ID. However, with the revamped AppleTalk Phase 2, you could now address over 16 million network nodes on a network. Each node is addressed using an 8-bit node ID, and a 16-bit network address.
With extended addressing you can use multiple network addresses on a single network cable. This means if you could have 500 clients on a single network segment, using two or more network addresses. This extended addressing is supported under EtherTalk, TokenTalk, and FDDITalk. It is not supported, however, under LocalTalk. This means that you can still only have a single network number per LocalTalk cable segment, limiting the number of clients to 254 per segment.
There were many other changes to the AppleTalk protocol with the introduction of AppleTalk Phase 2. These changes include modifications to the way AppleTalk devices acquire their dynamic node IDs when they start up, changes in the AppleTalk routing scheme to reduce network traffic, and the inclusion of directed broadcasting, which uses multicast addresses to prevent non-AppleTalk clients from being impacted by AppleTalk broadcast packets.
The most significant changes for many people was the incorporation of networking standards, such as the IEEE 802.3 and 802.5 standards for Ethernet and Token Ring, respectively.
The AppleTalk protocol suite defines a number of other protocols that operate at different levels of the OSI Reference Model. The more important of these protocols are listed in Table 10.1.
Table 10.1. AppleTalk Protocols matched with the OSI Reference Model.
Routing Table Maintenance Protocol. The RTMP is responsible for maintaining a list of all the routers on the AppleTalk network, as well as providing the rules for how routers exchange routing information. Each entry in the routing table consists of a network range, a distance in hops to the remote router, a port number on the remote network, the AppleTalk node ID of the next router on the path to the destination network, the status of each port on the network. This is similar in functionality to the RIP protocol in the TCP/IP protocol suite.
AppleTalk Echo Protocol. The AEP provide a protocol similar to ICMP in the TCP/IP suite. It supports sending an echo datagram from the requestor to the echo port on a destination computer, which then responds with a echo response datagram. This can be useful for detecting if a particular host is reachable.
AppleTalk Transaction Protocol. The ATP is used to set up a transaction-based conversation between two computers. Although ATP does guarantee delivery of packets, it does not guarantee they are received in any particular order. When one machine sends an ATP request datagram, it waits for the second machine to respond with a ATP response datagram before it can proceed. When all the data has been sent between the two machines, a ATP release datagram is sent to indicate the transaction session is complete. The ATP is not intended for transporting large amounts of information, nor for establishing sessions that need to be kept open for long periods of time.
Name Binding Protocol. The NBP is important to the working of the AppleTalk protocol suite. The network itself sends packets by using a numeric address to identify network entities. However, AppleTalk itself uses names internally to locate resources. The NBP is responsible for resolving the AppleTalk names into the node ID that is required for locating the machine on the network. AppleTalk stores names internally in the format name:type@zone, where name is the AppleTalk name of the resource, type is the resource type, such as LaserWriter, and zone is the name of the AppleTalk zone where the resource resides. An example of a complete AppleTalk name is Jason's Macintosh:AFPServer@Home.
AppleTalk Data Stream Protocol. ADSP is similar to the ATP in that it provides guaranteed delivery of network packets. However, unlike the ATP, which is intended for small and quick data exchanges, the ADSP is intended for transmitting larger amounts of data, and for supporting long sessions. While the ATP does not guarantee the order in which packets are received, the ADSP ensures that packets are received in the order they were sent. Another advantage of the ADSP protocol is that it supports full duplex communications, meaning that both network entities can speak to each other at the same time. The ADSP protocol also supports flow control, which ensures that one of the network entities is not bombarded by more network traffic than it can handle.
AppleTalk Session Protocol. The ASP provides session-level communications between a client and a workstation for sending command streams. While ATP and ADSP are used to send raw data, the ASP is used initiating a session control mechanism between a client and the server. Also, in ATP and ADSP, the two network entities are connected in a peer-type relationship, whereas the ASP clearly defines a client, which must initiate a session, and the server. With ASP commands can be sent from the client to the server, but the server is not permitted to send commands to the client. The only thing the server can send to the client is data requested by the client, and an alert packet to notify the client of a problem.
Printer Access Protocol. The PAP is used for communicating with AppleTalk print devices. It is responsible for opening a session with a PAP server (printer), transferring the print job to the printer, performing flow control to prevent the client from sending too much data too fast to the printer, and reporting printer status back to the client. The PAP actually uses ATP datagrams for communicating on the network.
Zone Information Protocol. The ZIP is responsible for creating and maintaining the Zone Information Table (ZIT), which is stored in each AppleTalk router. The ZIT is a map that is used to link the friendly zone names back to the unique network numbers that are used to actually locate what subnets a zone actually resides on. The Zone Information Protocol is responsible for working with the RTMP protocol to keep the ZIT up-to-date.
AppleTalk Filing Protocol. The AFP is the high-level protocol that is used for sharing files from one computer with other machines on the network. AFPs primary focus is on providing a mechanism to control user access to folders, as well as how these permissions are displayed to the user. AFP is also designed to deal with naming inconsistencies between different operating systems and file systems, which support different allowable naming schemes. AFP relies on the ASP protocol for handling the logistical portion of setting up connections between the client and server.
Services for Macintosh supports all of these protocol and like the Mac OS itself, addresses each of them in different pieces of software. RTMP, AEP, ATP, NBP, ADSP, ASP, and ZIP are all addressed in the AppleTalk protocol loaded in Windows NT, along with related drivers that are loaded with the AppleTalk protocol. The PAP protocol is address in the Print Server for Macintosh service, and support for the AFP protocol is located in the File Server for Macintosh service, and related kernel-mode driver.
Macintosh File Structure
Macintosh files are different than PC files. Most computers use file structures in which all the file's data is stored as a single stream of information. This is the way MS-DOS, Windows and Windows NT works. Additionally, there is no set method of identifying what program created the file or what indicating what kind of data is contained in the file. The only standardized method of identifying a file's type is by using the filename extension, which is not always reliable.
Microsoft is beginning to use OLE objects within files. This provides even more flexibility than multiforked files, because the OLE objects can be defined and included only as necessary. Future OLE-based file systems could potentially support Macintosh files by storing each fork in a separate OLE container.
When discussing files, the terms fork and stream are used interchangeably to indicate discrete containers within the file. Fork is the term in common use in the Macintosh lexicon, while stream is the term used by Microsoft to describe the identical ability in the NTFS file system.
In contrast to this single fork approach, the Macintosh uses two file forksthe data fork and the resource fork. The data fork is directly analogous to a standard PC file. However, the Macintosh computers also have a resource fork. This is where special information about the file is stored. A resource fork can contain icons, bitmaps, fonts, small blocks of code, menus, window definitions and other things.
Not every Macintosh file contains both forks. Some might contain only a data fork, others might contain only a resource fork, and others might contain both.
Additionally, Macintosh files attach supplementary file properties not included on standard PC files. Of particular importance is the creator and type information. These are both four-digit codes that allow the Macintosh operating system and other applications to identify the program that created the file as well as the nature of the data contained in the file.
Apple maintains a registry of creator types for Macintosh files. If a new software vendor wants to make a Macintosh version of their program that creates files, they must register a unique creator type with Apple. This ensures that no two vendors use the same identifier codes, which could cause the wrong application to launch when a user tries to open a file. Microsoft's registered creator code is MSFT.
Because NTFS offers native support for multiple data streams in a single file, it has no problem supporting Macintosh resource and data forks. This is in comparison to NetWare 3.1x, which tries to provide Macintosh file support by splitting the data and resource forks into two separate files. The problem with this approach is that a look-up table is used to provide mappings between the resource forks and data forks of all the files on the Novell partition. If this look-up table fails, all the Macintosh files on the partition would be destroyed. An additional advantage of providing native support for multiple file forks is that if a non-Macintosh user deletes a Macintosh file, both forks will be deleted, which is not guaranteed under a system using a non-native lookup table..
Macintosh files support filenames of up to 31 characters. Additionally, Macintosh filenames permit characters, such as the backslash (\) that are forbidden in standard DOS-style 8.3 names. Furthermore, the Macintosh OS permits virtually unlimited nesting of folders within folders, whereas there is an effective limitation of 255-character path names in Windows NT (and Windows 95). This means that the full name of the file, which includes its entire path, cannot exceed 255 characters. This limitation is actually created by the Win32 API calls that are used to handle file references. In fact, NTFS will allow Macintosh users to nest folder within folders to their hearts' content. The problem is that if you try to use the Explorer or File Manager to look at or manipulate those files, you will get an error. To make matters worse, because most backup programs rely on the Win32 API to access files, you will not be able to backup any file that has a full path name of greater than 255 characters.
Because NTFS supports 255-character filenames, and Macintosh users can only use 31 characters, it is important to realize how the filename translation works.
If the Macintosh user views a file or directory whose name is 31 characters or shorter, the Macintosh user will see the full NTFS long file name. If the name is longer than 31 characters, however, the user will see the short 8.3 name that is created automatically for all NTFS files and directories.
If a Macintosh client opens a file using its 8.3 filename and then saves the file, the long filename will be preserved, even though the Macintosh user cannot see it. This is done through a technique called tunneling. However, some applications copy the file you open to a temporary file and make all your changes to the temporary file. When you save it, the original file is deleted, and the temporary file is renamed as the original file. In this case, if the file was opened with the 8.3 filename, the long filename will not be preserved.
:If you copy a Macintosh file containing a resource fork to a FAT partition, the resource fork will not be copied, and thus the copy will be effectively useless.
Working with Macintosh Permissions
Macintosh folder permissions on Services for Macintosh are based on NTFS file and directory permissions. Under AppleShare, access restrictions can only be made on a folder-by-folder basis.
You can use the MacFile menu in the File Manager to set permissions on a particular folder on a Macintosh-accessible volume.
You must use the File Manager interface or the MACFILE command-line tool to set permissions on Macintosh-accessible volumes. There is no Explorer interface for performing this action.
If you try to set permissions on a folder that is not part of a Macintosh-accessible volume, you will get an error message.
The way that Macintosh computers assign permissions to folders is dictated by the AFP protocol. It permits the security permissions for a folder to include permissions for an owner, a primary group, and everyone else. These permissions are set with the File Manager as shown in Figure 10.1.
The File Manager provides an interface for setting permissions on a Macintosh volume.
You can also log on from a Macintosh workstation to modify permissions.
Notice that for each of the three access control entries (ACEs)Owner, Primary Group, and EveryoneAFP only permits three levels of permissions: see files, see folders, and make changes. When you make apply these AFP permissions to a folder shared as a Macintosh volume, NT converts the AFP permissions into NTFS permissions and applies them to the selected folder as well as all files within the folder.
When you change the AppleShare permissions on a folder, it has a direct effect on the NTFS permissions for the folder and for any files within the folder.
Let's look at some of what happens when you choose different options and how this affects the NTFS permissions and attributes.
First of all, when you set the Macintosh permissions for a folder, NT will add the Owner, the Primary Group, and the Everyone group to the NTFS permissions for the folder, as well as all the files contained in the folder. The way that NT translates the Macintosh permissions into NT permissions is shown in Table 10.3.
Table 10.3. Translation of Macintosh permissions into NTFS permissions.
You'll notice that many of the different Macintosh permissions translate into equivalent NTFS permissions, so you'll be unable to identify the exact Macintosh permissions by looking at the NTFS permissions.
In addition to the permissions listed in Table 10.1, the owner also gets the (P) and the (O) permissions on all of the preceding combinations. If the owner has all three permissions, the owner will be assigned the NTFS Full Control permission. This is not so with the primary group, or the Everyone group.
Remember, the NTFS permissions are as follows:
Change Permissions (P)
Take Ownership (O)
You'll also notice that the see files and see folders options actually appear to have the same effect on the NTFS permissions. Although it is not reflected in the visible permissions, NT honors these two flags for Macintosh clients. When a Macintosh user does not have the see files permission, a little file icon with a slash through it appears in the upper-left corner of the window. Likewise, if the user does not have permissions to see folders, the icon will be a small folder with slash through it. The icon that indicates a user does not have the see folders permission is shown in Figure 10.2.
The little icon of the folder with a line through it indicates that the user does not have permission to see folders.
Here are some things to be aware of when working with these permissions:
Permissions are cumulative. Essentially you can mix and match rights from each category. For instance, if only the Owner has see files permission, and only the primary group has see folders permission, and if only the Everyone category has make changes permission, and if I'm the owner, and I'm a member of the primary group do I have all three rights.
The owner has built-in rights. Even if you remove all three rights (see files, see folders, and make changes) from the owner, the owner still retains the change permissions (P) and take ownership (O) rights.
Discrepencies in Permissions between PC and Macintosh clients. PC clients do not honor the see folders and see files permissions the same way as Macintosh clients. This can result in discrepancies in what a Macintosh and a PC user can see.
Changing ownership changes the ACL. When you use the MacFile permissions option to change the owner of a file, the old owner will be removed from the folder's access control list (ACL)and likewise from all files within the folder. For example, if JGARMS is the owner and I change the owner to JSMITH, not only will the NTFS owner change to JSMITH, but JGARMS will be completely removed from the NTFS ACL.
The AFP permissions keep placeholder entries for the primary group and Everyone. If you use the MacFile Permissions option to remove all three AFP permissions from the primary group or the Everyone group, they still retain placeholder access control entries (ACEs) in the NTFS access control list.
For instance, if you remove all the AFP permissions from the owner, the primary group, and Everyone, the resulting NTFS permissions on the folder will list the owner with special access (PO), and will list the primary group and Everyone with special access (), which is essentially no specified access. This is shown in Figure 10.3.
When you remove Macintosh permissions, place-saving entries are retained in the NTFS access control list (ACL).
You can set the owner of the folder to a groupit does not have to be an individual user's account. This is in sharp contrast to the normal operations of Windows NT, where the Administrators group is normally the only group that can own files.
Existing ACEs are preserved when replacing permissions on subdirectories. When you choose the option to Replace Permissions on Subdirectories, only the NTFS permissions for the owner, the primary group, and the Everyone group will be changed. All other access control entries (ACEs) in the ACL will remain unchanged. This is quite different from the usual behavior of the NT Explorer and the File Manager, where the entire ACL of each subdirectories is replaced.
NT Supports the AFP Cannot Move, Rename, or Delete option. When you choose the option Cannot Move, Rename, or Delete, NT sets the read-only attribute on the folder, but not on the files within it.
Understanding Macintosh Guest Logons
When a Macintosh user connects to an AppleShare file server, there are normally two methods of logging in:
As a Guest
As a Registered User
To illustrate this point, Figure 10.4 shows the Macintosh user validation screen.
Macintosh users can log on as a Guest, or as a registered user.
When the user logs on to an NT Server running Services for Macintosh as a registered user, they can use a standard Windows NT user account and password, much as would be expected. This is very straightforward.
The problem, however, is when the user tries to logon as a Macintosh guest. I often run into people that don't quite understand how this works, and they often encounter problems because of it.
There are two basic things to remember, and everything else will fall into place:
The Macintosh Guest logon is completely unrelated to the Windows NT Guest user account.
The file-level access for a Macintosh Guest is controlled by the NTFS privileges assigned to the pseudo-group Everyone.
The pseudo-group Everyone is unrelated to the NT Guest user account. The reason I call it a pseudo-group is that you cannot directly control membership in this group the same way as other groups. The actual membership of the Everyone group could be simply defined as every non-disabled user account in this domain and all trusted domains.
So what does this mean? Well, it means that you can disable the NT Guest user account and Macintosh guests can still connect. Many people don't believe this until they've tried it, so feel free to go ahead and try it. Now that we've gotten over that, let's move on and figure out how the Macintosh guest access really works.
First of all, if you absolutely don't want guest access from Macintosh users, you can disable it by going to the MacFile Control Panel, choosing Attributes and then deselecting the Allow Guests to Connect option. This will prevent all Macintosh guest access, no ifs, ands, or buts.
However, you might want to rethink this strategy. There is a reason Macintosh guest access is there, and there is a reason it is enabled by default. When you install Services for Macintosh, NT creates a read-only, Macintosh-accessible volume called Microsoft UAM Volume and enables guest access. By default, when Macintosh users connect to NT Servers, their passwords are sent in clear-text over the network, which creates a security problem. However, the Microsoft UAM allows Macintosh clients to connect to the NT Server using encrypted passwords.
The catch-22 is that the users must be able to logon to the server to download the UAM. So the theory goes that they should connect to the server as a guest, which doesn't require a password and download the UAM. Because the volume is marked as read-only, it cannot be tampered with. Additionally, rather than disabling Macintosh guest access globally, and preventing people from downloading the UAM, you can restrict Macintosh guest access on a volume-by-volume basisand leave it enabled Microsoft UAM Volume.
So where does that leave us? Well, we now know how to restrict Macintosh guest users from accessing an NT Server running Services for Macintosh. Once they've been allowed to connect to the server, access to particular files and folders is dictated by the permissions set for Everyone at each folder level.
If you remove permissions for Everyone from a particular folder, a Macintosh guest will not be able to access files in that folder.
The Everyone group that shows up when you set the AppleShare file permissions is exactly the same as the NT Everyone group that shows up when you set NTFS permissions.
Who is the Macintosh Guest, Really?
This section is for the techie folks who really want to understand what's going on. We've identified in this chapter that Macintosh guest users do not in fact use any standard NT user accounts. If this is true, how can we explain the fact that NT requires all system events and processes to be auditable to a single user? Well, the answer is that when a Macintosh guest logs on, he or she is logged on as a special ANONYMOUS LOGON account that is built into Windows NT.
We can see this account by enabling auditing of user logons. Figure 10.5 shows the audit event that gets registered in the Security Log when a Macintosh guest logs on.
A Macintosh guest generates logon events as the user NT AUTHORITY\ANONYMOUS LOGON.
Well, at least we know how the user logs on. Just remember, the NT AUTHORITY\ANONYMOUS LOGON is built-in to NT and cannot be disabled. However, the rights of the ANONYMOUS LOGON is based on the privileges assigned to the Everyone group for a particular resource.
Installing and Configuring Services for Macintosh
Enabling Macintosh support for Windows NT Server is exceptionally simple. In fact, it is just as straightforward as installing almost any other service. There are essentially five steps:
Install the Services for Macintosh service
Configure the File Server options
Configure the AppleTalk router options, if desired
Create any Macintosh Volumes and assign appropriate permissions
Install the Microsoft User Authentication Module (UAM) on Macintosh clients, if desired
Installing Services for Macintosh
When you install Services for Macintosh on your system, there are a number of changes that take effect. These include the following:
Installing the AppleTalk protocol and binding it to the default network adapter
After installing Services for Macintosh, the AppleTalk Protocol will not be listed in the list of installed protocols in the Network Control Panel.
Adding a MacFile icon to the Control Panel and extensions to the File Manager and Server Manager that enable you to configure and manage the Services for Macintosh
Adding an option to the Print Manager and printer creation wizard for printing to an AppleTalk printer
Installing the PostScript Raster Image Processor (RIP) that enables you to print PostScript jobs to non-PostScript printers
Adding two services, File Server for Macintosh, and Print Server for Macintosh
Adding Performance Monitor objects for AppleTalk and MacFile Server
Creating a Microsoft UAM Volume directory on the first available NTFS volume and creating a Macintosh shared volume for it
Installing the MACFILE.EXE command-line utility for managing and configuring Macintosh services
In order to install Services for Macintosh, you must have at least one NTFS volume.
To install Services for Macintosh you should be logged on as a member of the Administrators group and follow these steps:
From the Control Panel, double-click the Networks icon.
Click the Services tab. This brings up the Services page, which lists all the services currently installed on your system.
Click the Add button. This brings up a window that lists all the services that can be installed on your system. Scroll down to Services for Macintosh and select it, as shown in Figure 10.6.
Select Services for Macintosh from the Select Network Services window to install Macintosh client and printer support.
When you have highlighted Services for Macintosh, click OK.
You might be asked to provide the location of the Windows NT Server installation files. If so, enter full path, such as f:\i386, where f: is the CD-ROM drive. Click the Continue button.
NT Setup will copy files from the distribution media and make modifications to your system. This might take a few moments. When it is completed, it will return you to the Services page on the Network Control Panel. Services for Macintosh should be listed under Network Services, as shown in Figure 10.7.
Once you have installed Services for Macintosh, it will appear in the list of Network Services in the Network Control Panel.
Click OK to close the Network Control Panel window and complete the installation process.
NT Setup will review the network adapter binding and services. This might take a few minutes. Once this is completed, the Microsoft AppleTalk Protocol Properties window will appear, as shown in Figure 10.8.
The Microsoft AppleTalk Protocol Properties window is used to configure the AppleTalk protocol necessary to support Macintosh clients.
This window is used to configure the AppleTalk protocol options.
The default network adapter for your system will be listed in the field Default Adapter. This is the physical network on which the NT Server will advertise its services. If you have more than one adapter, you can choose which physical network segment you want your system to advertise on. This will make a difference if AppleTalk routing is not enabled.
The second field here, Default Zone, is the zone where the NT Server will advertise its services. Each AppleShare server can advertise itself in only one zone. If you don't already have an AppleTalk router on the network, this pull-down list will be empty. If you do have an existing AppleTalk router, the designated default zone on the router will be listed in the Default Zone entry. If you want the NT Server to appear in a different zone, choose it from the pull-down list.
AppleTalk zones are similar to NT workgroups, except that zones also contain routing information and workgroups do not.
For information on configuring NT Server as an AppleTalk router, see the section, Configuring Windows NT Server as an AppleTalk Router, later in this chapter.
Click OK to continue.
NT Setup will finish making internal configuration changes. This might take a few minutes. When it is completed, you will need to restart the system before any changes will take effect.
Click Yes when prompted to restart the system.
When the system restarts, all printers created on the NT Server will become available to Macintosh clients.
Configuring Services for Macintosh
You can configure Services for Macintosh by three different methods. The most common is to use the MacFile Control Panel, as we will do here. However, you can also use the Server Manager or the MACFILE command-line utility to perform the same functions.
To configure Services for Macintosh using the MacFile Control Panel, follow these steps:
Open the Control Panel. Notice the MacFile icon, shown in Figure 10.9. This was installed with Services for Macintosh.
From the MacFile Attributes window, you can configure global options for Macintosh services on your NT Server.
The options for the MacFile Attributes window are as follows:
Server Name for AppleTalk Workstations. This is the name the server will appear as on the AppleTalk network. By default this will be the same as the standard NT name of the computer. However, if you want to, you can choose to have your computer appear with a different name. This can be 1 to 31 characters long.
Logon Message. This message will appear on the Macintosh workstation when a user connects to the NT Server. The ability to receive these logon messages is built-in to the standard AppleShare client for the Macintosh 2.1 and above. An example of this message is shown in Figure 10.12.
NT supports the capability to send logon messages to Macintosh clients.
By default, no logon message is sent to Macintosh clients.
Allow Guests to Logon. By default, Macintosh users are allowed to connect to the NT Server as guestseven if the NT Guest user account is disabled. To disallow Macintosh Guests from logging into the NT Server, deselect this option. For more information about Guest Macintosh users see the section Understanding Macintosh Guest Logons earlier in this chapter.
Allow Workstations to Save Password. For Macintosh clients, the capability to cache server passwords is controlled by each server. This differs from standard Windows clients, where the caching of passwords is controlled by each individual client. By default, Services for Macintosh does not allow Macintosh client to cache its password. Enable this option if you want Macintosh clients to be permitted to cache passwords.
Require Microsoft Authentication. By default, when a Macintosh client connects to an NT Server, the password is sent in clear text over the network. If you need a higher level of security, check this option and clients will be required to use the Microsoft User Authentication Module (UAM) to log on. For more information on the MS UAM, see the section Installing the Microsoft Authentication Module on a Macintosh Client, later in this chapter.
:Even if you have the Require Microsoft Authentication option checked, users can still log on as guests, provided the Macintosh guest access is not disabled. This permits users to connect to the Microsoft UAM Volume and download the MS UAM. Because the guest access does not require sending a password, there is no security problem with this configuration.
Sessions. You can use this option to limit the number of Macintosh clients who can simultaneously connect to the NT Server. By default, there is no limit. If you want to limit the number of users, you can enter a value between 1 and 4,294,967,293.
In Windows NT Advanced Server 3.1, there was a physical limit of 255 simultaneous Macintosh connections that was due to the design of the Services for Macintosh. However, with NT Server 3.5, Microsoft removed that limit. In fact, Microsoft has actually done internal testing of NT Server 3.51 with 1,000 simultaneous Macintosh clients without a problem.
Two other methods of configuring the Macintosh Services options are using the Server Manager and using the MACFILE command-line utility. Additionally, both of these methods enable you to configure Services for Macintosh on remote machines.
Configuring AppleTalk Routing On Windows NT Server
You can configure AppleTalk routing either during the Services for Macintosh installation process or at a later time. To configure the options at a later time, make sure you are logged on as a member of the Administrators group and start at step 1. If you want to configure AppleTalk routing during the Services for Macintosh installation process, start at step 4.
Open the Control Panel and double-click the Network icon.
Click the Services tab. The Services page should appear. It lists all the installed network services.
Find Services for Macintosh on the list and double-click it. This will open the Microsoft AppleTalk Protocol Properties window.
Click the Routing tab on the Microsoft AppleTalk Protocol Properties window. This will display the AppleTalk Routing page, as shown in Figure 10.13.
The options on the Routing page can be used to configure NT Server as an AppleTalk router.
By default, AppleTalk routing is disabled, so all other options on the page should be grayed out. To enable AppleTalk routing, check the box next to Enable Routing.
Enabling AppleTalk routing does two things. First, it routes AppleTalk packets between any Ethernet, LocalTalk and Token Ring network interfaces on your computer. Second, it enables you to seed the AppleTalk network to create zones.
You can configure the seeding of AppleTalk networks individually for each network interface. If you have more than one network interface, choose the one you want to configure for AppleTalk seeding from the Adapter pull-down list.
Click the option Use this Router to Seed the Network. The Network Range field and the Zone list box should now be enabled (not grayed out).
Enter a valid AppleTalk zone range into the From and To fields. The AppleTalk zone range is used to identify different physical networks. If you are attached to a larger network, check with the person in charge of the AppleTalk protocol to obtain the correct ranges. For more information on AppleTalk zone ranges, see the section on Understanding AppleTalk earlier in this chapter. Acceptable values are between 1 and 65,279. It is also acceptable to use the same value in the From and To fields.
Use the Add button to add zone names for the specified network segment. The first zone you enter will become the default zone for the network segment. If you want to change the default zone, select it from the zone list box and click the Make Default button.
If there are other AppleTalk routers on this physical network, you can click the Get Zones button to import the zone list. If you do this, all zones you entered manually will be replaced. NT will ask you to confirm that you want to replace the zone list, as shown in Figure 10.14.
These configuration settings indicate that the NT Server will act as an AppleTalk router and seed the local network segment with network values 10 through 12. Additionally, zones SALES and PROCUREMENT are on the local network segment.
When you are finished entering AppleTalk routing information, click the General tab at the top of the screen.
You can now use the Default Zone list to select the zone where you want your server to appear. When you are finished, click OK.
A window will appear notifying you that the AppleTalk protocol been successfully configured. Click OK. You will be returned to the Network Control Panel.
Click OK. Restart the computer to ensure the changes take effect.
When to Use AppleTalk Routing
If you're not intimately familiar with AppleTalk routing, it might be hard to determine when you need to use it and how best to configure it. There are two basic configurations where AppleTalk routing might be useful to you:
When you are using your NT Server to connect two physically separate AppleTalk networks. In this sense, you are using AppleTalk routing in the traditional sense of routing.
When you have an AppleTalk network and you want to logically divide the network into zones. This provides for easier browsing, and is not necessarily consistent with the traditional use of the word routing.
In both cases, you can use the NT Server as a seed router, depending on the existence of other AppleTalk routers on the network.
You need to have a seed router for each zone that you want to appear on a subnet.
Let's address these scenarios separately.
Routing AppleTalk Between Two Physically Separate Networks
Let's say that you are working on a large, private network, with 1,000 Macintosh clients spread around the network. You have five major zones: Sales, Procurement, Tech Support, Administration, and General. You have a new suite of 20-30 Macintosh computers served by an NT Server running Services for Macintosh that you need to connect into the existing network backbone.
Of course one option would be to connect the computers directly to the network backbone, as shown in Figure 10.16.
Connecting a series of Macintosh clients served by an NT Server directly to the network backbone.
In this case, the Macintosh clients in the group of computers we just added can communicate with the NT Server, as can any Macintosh clients on the rest of the network. Additionally, the newly added clients can become part of any of the zones available on the backbone.
As far as the NT Server goes, you don't need to enable AppleTalk routing because there is no need for actual routing, nor do you need to seed a new zone.
While this might seem nice and simple, there are two problems. First the minor one. You might not want the clients on the newly added network to be able to join any of the zones on the network. For instance, if the people in the newly added group of computers only need to be part of the Procurement and Sales zones, you might want to be able to restrict them to these zones. In this example, there are only five zones, so this might seem unnecessary. However, it is not uncommon for larger enterprises to have dozens and even hundreds of zones, where being able to restrict groups of computers to certain zones could be a necessity.
The second reason that the network architecture in Figure 10.17 is not adequate is that the users on the newly added computers will share all network bandwidth with the rest of the users on the network. This single-segment approach can have a negative impact on network performance.
To help alleviate both of these problems, you can use the NT Server as an AppleTalk router, as shown in Figure 10.17.
In this scenario, the NT Server is used as an AppleTalk router between the local subnet and the rest of the network.
To make this scenario work you need the following:
a second network card for the NT Server
a unique range of network numbers for the new subnet
Let's say you will use the network range 36-38, since it's not being used elsewhere on the network.
To configure NT properly for this scenario, you would use the following steps:
Open the Control Panel.
Double-click the Network icon.
Click the Services tab.
Double-click the Services for Macintosh.
Click the Routing tab. This is where the real work begins.
Click the Enable Routing check box.
From the Adapter pick-list, choose the network adapter that is connected to the new subnet.
Select the option Use this Router to Seed the Network.
Enter 36 in the From field, and 38 in the To field.
Click the Add button. The Add Zone window appears. Type Sales and click OK. Repeat this step to add the Procurement zone as well.
Make sure you enter the AppleTalk zone names exactly the same as they appear elsewhere on the network. Be especially careful to include exact spacing, punctuation and case.
Because you entered the Sales zone first, it appears as the default zone. This means that all Macintosh clients will appear in this zone automatically, unless you manually configure them to use a different zone.
Figure 10.18 shows the configuration options discussed in the preceding steps.
Services for Macintosh is now configured for AppleTalk routing.
Click the General tab at the top of the Microsoft AppleTalk Protocol Properties window.
From the Default Adapter pick-list, choose the adapter that is connected to the new subnet. This is the same adapter you chose in step 7.
From the Default Zone pick-list, choose the zone you want the NT Server to appear in. The only choices will be Sales and Procurement, because these are the zones you chose to seed on the new subnet.
Now choose OK a few times to get out of the Control Panel, and then restart the computer.
When the computer comes back up, it will be configured properly to support the routing scenario depicted in Figure 10.17.
Using AppleTalk Routing to Create Zones
The second common scenario is to use the AppleTalk routing capabilities to create AppleTalk zones on the network. My experience is that this is what the vast majority of people using NT Server's Services for Macintosh use AppleTalk routing for.
Remember, in the Microsoft world, there are workgroups and domains that provide logical grouping of computers. These logical groupings make locating a resource on the network easier.
In the Macintosh world, you can use an AppleTalk router to create zones, which are used to logically group machines and resources on the network. In a smaller network, full-fledged routing is often not necessary, but it is still often useful to create zones for organization of resources. Windows NT Server enables you to do this.
Let's use an example. Let's say that you have a small network that has 45 Macintosh computers and a couple of networked AppleTalk printers. You want to logically group our network into five zones: Development, Production, Advertising, General, and Printers.
You can use the AppleTalk routing capabilities of NT Server to do this. While it won't make your network any faster, it does help you to organize a little better.
To configure NT properly for this scenario, you would use the following steps:
Open the Control Panel.
Double-click the Network icon.
Click the Services tab.
Double-click the Services for Macintosh.
Click the Routing tab.
Click the Enable Routing check box. Although this example only includes one network card on the server, so there won't be any real routing, you still need to enable this feature.
Select the option Use this Router to Seed the Network.
Because this machine is the only AppleTalk router on the network, you can use whatever values you want to seed the network. For now, enter 10 in the From field, and 11 in the To field.
Click the Add button. The Add Zone window appears. Type Development and click OK. Repeat this step to add the Production, Advertising, General, and Printers zones as well.
Because you entered the Development zone first, it appears as the default zone. This means that all Macintosh clients (and even printers) will appear in this zone by default.
Figure 10.19 shows the configuration options discussed in the preceding steps.
These options will create five zones on the AppleTalk network.
Click the General tab at the top of the Microsoft AppleTalk Protocol Properties window.
From the Default Zone pick-list, choose the zone you want the NT Server to appear in. Because it will be used by everyone, put it in the General zone.
Now exit the Control Panel and restart the computer.
When the server comes back up, it will create the five zones specified earlier in the example. Now you'll be able to see the zones on your Macintosh clients, and you'll be able to move them into the appropriate zones.
Creating Macintosh-Accessible Volumes
In the AppleShare world, network volumes are the resources that are made available on an AFP file server for network users to connect to. They are logically the same as network shares, share points, or mount points in the Windows networking world. The process for creating a Macintosh-accessible volume with NT Server is similar to that of creating a standard network share that would be accessed by Windows networking clients.
There is one major difference between Macintosh volumes and standard Windows share, which you should be careful of. With Windows shares, you can create shares within shares. Let's take a look at an example. If you had a file structure that looked like the one shown in Figure 10.20, you could create a share-point for the Divisions folder. You could also create separate share-points for each of the folders in the Divisions folder, Accounting, Advertising, General, Procurement, and Sales. If a user attached to the Divisions share-point, he or she would be able to see the folders beneath that folder, given the correct permissions, of course. Likewise, if a user attached to the Accounting share-point, he our she could see the things below that level, but could not see anything else in the Divisions folder. This provides for a useful method of organization.
Sample Windows directory structure showing shares within shares.
However, with Services for Macintosh, you cannot create Macintosh-accessible volumes within other Macintosh-accessible volumes. This would preclude you from setting up an environment like the one described above. You could either create a volume for each division, or you could create a single volume that contained all the divisions, but not both.
There are four tools you can use to create Macintosh-accessible volumes in Windows NT:
MACFILE command-line utility
The easiest of these options is to use the Administrative Wizards, which we'll discuss in this section. We'll also look at using the File Manager for creating Macintosh volumes. The Server Manager interface for creating Macintosh volumes functions in almost the exact same manner as the File Manager interface. The syntax for using the MACFILE utility is listed at the end of this chapter.
Microsoft did not include a method for creating Macintosh shares from the NT Explorer interface.
NT Server automatically creates a Macintosh-accessible volume called Microsoft UAM Volume when you install Services for Macintosh. This volume is created on the first NTFS partition on your server.
Using the Administrative Wizards to Create a Macintosh-Accessible Volume
One of the new features of Windows NT Server 4.0 is the inclusion of a set of administrative wizards that simplify common administrative functions. There are eight basic administrative wizards, on of which is called Managing File and Folder Access. This wizard permits you to specify files and folders on the local server or on a remote server that should be shared to the clientsincluding Macintosh clientson the network.
To use the Administrative Wizards to create a Macintosh-accessible network volume, follow these steps:
You must be logged on as a user with administrative privileges to create network shares.
From the Start menu, choose Programs, Administrative Tools, then Administrative Wizards. The Administrative Wizards main window is shown in Figure 10.21.
You can use the Share Management Wizard to create network shares on the local computer, or on a remote NT system.
By default, the share will be created on the local computer. Click the Next button to continue.
You will be given a list of all the local drives, as shown in Figure 10.23. Choose the drive the contains the files and folders you want to share. The drive will expand and you can see the files and folders contained on the drive. Locate the folder you want to share as a Macintosh volume, then click the Next button.
The Share Management Wizard permits you to specify the permissions on the folder you specified.
The Share Management Wizard is not a very robust tool and is probably best used by beginners who are just beginning to learn about Windows NT. However, if you are a more advanced user and commonly change permissions on files witholding subfolders, and want a fine level of granularity when specifying permissions, you should not use the Share Management Wizard.
You will be asked if you want to share the folder with network users. Click Yes.
The Share Management Wizard will ask you for a name for the share, a comment, and what kind of clients you want to share the folder to, as shown in Figure 10.25.
You need to specify a name for the network share, as well as what kind of clients should be able to connect to it.
Each shared volume on an NT Server must have a unique name. If you enter a name that is the same as an existing share name, NT will advise you that the name is already in use and ask you to choose a new name for the share.
If the Macintosh Users option is grayed outindicating that you cannot share the folder with Macintosh usersthen you either selected a folder located on a FAT partition, or you don't have Services for Macintosh installed on your NT Server.
Click the check box for Macintosh users to access the share. If you don't want to make the share available to Windows clients, you should uncheck the button for Users of Microsoft Windows. Click the Next button.
The Share Management Wizard presents a summary page indicating the name of the share you created, its network path, and what clients it will be shared to. Click Finish.
The share should now be available for users on the network. You can change Macintosh permissions for the file using the File Manager, or the MACFILE command-line utility.
Using the File Manager to Create a Macintosh-Accessible Volume
To create a Macintosh-accessible volume using the File Manager, follow these procedures:
Open the File Manager.
The easiest way to get into the File Manger in NT 4.0 is to click the Start menu, choose Run and then type winfile and hit return.
Find and select the directory you want to share as a Macintosh volume, such as D:\USERS, as shown in Figure 10.26.
The Create Macintosh-Accessible Volume window enables you to specify options for the new volume.
From here, you must specify the following:
Volume Name. This is the volume name the Macintosh clients will see. It must be 27 characters or less. You can create a maximum of 255 Macintosh volumes on a single server. By default, this is the name of the folder you are sharing.
Path. This is the path of the folder you want to share. It must be on a local volume, and it must be NTFS, or CDFS.
Services for Macintosh allows you to create Macintosh-accessible volumes on a CD-ROM.
Password/Confirm Password. You can specify a password here and any Macintosh will be required to enter this password when connecting to this share. This security is provided in addition to any additional folder- and volume-level permission you might have set.
This volume is read-only. If you check this box, the volume will be marked as read-only. Any Macintosh user who connects to the volume will be unable to make changes to the volume, regardless of what additional privileges they might have.
Guests can use this volume. If you select this option, Macintosh users will be able to connect to this volume as a guest. If guest access is disabled from the MacFile Control Panel, this option has no effect. NOTE:
Guest access from Macintosh clients has nothing to do with the NT Guest account. For more information on Macintosh guest access, see the section Understanding Macintosh Guest Logons, earlier in this chapter.
User Limit. You can use this setting to limit the number of simultaneous Macintosh clients that can access this volume. NT Server has no built-in practical limitation as to the number of Macintosh clients it can serve. NOTE:
The sum of the number of users of all the Macintosh-accessible volumes cannot exceed the Macintosh user limit in the MacFile Control Panel.
When you are finished entering the volume information into the Create Macintosh-Accessible Volume window, click the Permissions button to specify the access permissions for the volume. The Macintosh View of Directory Permissions window is shown in Figure 10.28.
You can use NT to specify the Macintosh permissions exactly as you would on a standard AppleShare server.
From here you can specify the permissions for the Owner, Primary Group, and Everyone. Additionally, you can change the Owner and Primary Group.
For more information on setting Macintosh permissions, see Working with Macintosh Permissions, earlier in this chapter.
:It is very important to realize that Services for Macintosh does not distinguish between share permissions and file folder permissions. Standard Windows NT shares have their own permissions, which are different from the permissions set on the files and directories contained within. However, the volume permissions for a Macintosh, are exactly the same as the folder where the volume begins. This means that if you change the permissions when you create a Macintosh volume, the NTFS permissions will directly and immediately reflect the change.
Click OK to close the security window.
Click OK again to create the share.
Macintosh users should now be able to access the share.
Viewing and Modifying Macintosh-Accessible Volumes
You can use the MacFile option in the File Manger to view and modify the settings for Macintosh-Accessible volumes.
Any changes you make to the volume, including setting or clearing the read-only flag, will take effect immediately. However, if you remove guest access for the volume by clearing the Guests Can Use this Volume option, it will not affect any users currently logged on as guests. This is because this option is only checked at logon.
Removing Macintosh-Accessible Volumes
You can remove Macintosh-Accessible volumes, by using the Remove Volumes option under the MacFile menu in the File Manager.
If there are any Macintosh users accessing the share, you will be warned that removing the share could result in the connected users loosing data, as shown in Figure 10.29.
You will be warned if you try to remove a Macintosh-accessible volume with active users.
You can wait until the users have logged out, or you can click Yes to proceed and remove the volume anyway.
The Microsoft User Authentication Module (MS UAM)
When a Macintosh client connects to an AppleShare file server, it uses a user authentication module (UAM) to handle the authentication of the user by exchanging user name and password with the server. Macintosh computers running System 7.x (or System 6.0.7 and above, running AppleShare 2.1 or greater) have a built-in Apple authentication module. When communicating with other Macintosh computers running System 7.x, or with Apple's AppleShare servers, this allows the user's password to be encrypted before being sent over the network.
However, because of the way Windows NT stores passwords, it cannot take advantage of the Apple encryption method, called Apple Random Number Exchange. This means that when a Macintosh client wants to connect to an NT Server running Services for Macintosh, it sends the password in plain text over the network. Passing the password in clear text over the network results in a situation where anyone on the network could see the password as it goes between the network client and the server, thus sacrificing the security of the user's account.
Additionally, Apple's built-in UAM only supports passwords of up to 8 characters, while NT Server supports passwords of up to 14 characters. If a user has a password longer than 8 characters, he or she will not be able to login to the NT Server from a Macintosh client using Apple's standard authentication module.
Thus, there are two occasions where you would want to install the Microsoft UAM:
When you don't want user passwords to be sent in clear text over the network.
When users have passwords longer than 8 characters.
Understanding the MS UAM
To help rectify the security problem, Microsoft created the Microsoft User Authentication Module (MS UAM). This module must be installed on each client that wants to use it. It interfaces with the Chooser, and provides for encrypted user verifications using Microsoft's Challenge Authentication Protocol (MS-CHAP). In addition, it supports up to 14-character passwords.
When you install Services for Macintosh on an NT Server, it automatically creates a directory called Microsoft UAM Volume on the first available NTFS partition. It then shares this directory as a read-only Macintosh volume and grants guest access. Macintosh clients can then connect to this share to obtain the MS UAM and install it on their system.
The reason the Microsoft UAM Volume is created with guest access enabled is so that Macintosh users do not need to sacrifice their passwords in order to obtain the UAM!
The MS UAM might seem like a great thing, and worthwhile to rush off and install it on all your systems. However, before you do this, let's take a look at the downside.
In the README.UAM file that is installed with Services for Macintosh, Microsoft writes, "Microsoft encourages you to install Microsoft Authentication (MS UAM) only if you need increased security on your Windows NT computer."
The reason for the caveat is that installing the Microsoft User Authentication Module adversely affects two major functions on Macintosh computers:
The UAM cannot be used to connect to volumes at startup.
The UAM cannot be used to connect to remote resources through aliases.
For those not well versed in Macintosh terminology, file aliases are very similar to Shortcuts in the Windows 95-style interface.
When Macintosh users connect to AppleShare file servers, they have the option of designating that certain shares should be reconnected automatically at startup, as shown in Figure 10.30.
Macintosh users can designate certain network volumes to be reconnected at startup.
This is similar to the persistent connections option on Windows systems.
However, because of problems internal to Apple's system software, the Macintosh cannot use alternative UAMs to reconnect at startup. This means that either one of a couple of things will happen, depending on the server's configuration:
If the server is configured to allow users to connect without the MS UAM, the user will be able to logon to the server at startup using the standard Apple UAM. The problem is that this defeats the increased security of the MS UAM.
If the server is configured to require MS UAM authentication, and the volumes the user is mounting permit Macintosh guest access, the Macintosh user will connect to the volumes as a guest.
If the server is configured to require MS UAM authentication, and the volumes the user is mounting do not permit Macintosh guest access, the volumes will not be mounted.
The second problem with the MS UAM has to do with the way it interferes with reconnecting to file aliases located on network resources. Very often Macintosh users will create aliases to files or folders on remote file servers. If a user double-clicks an alias and is not currently connected to the file server where the file is located, the Macintosh tries to connect to the server. This is considered a great feature by many Macintosh network users. However, the problem is that the alias will always try to connect using the standard Apple UAM. The results are the same as listed previously when users automatically connect at startup.
However, there is one slight saving grace. Once the user is attached to a network volume, the aliases will work. This is because the user authentication process is only dealt with when you first connect to the resource. While this doesn't provide a solution for connecting to systems at startup, it does mean that your users can use the MS UAM to attach to a Macintosh-accessible volume on the NT Server, and then use their aliases.
This leaves the system administrator, you and me, in a very unenviable position. It means that we can either forfeit the security provided by the MS UAM, or you can cripple the functionality of your users' systems. The correct solution to this problem must be handled on a site-by-site basis. If you choose to require the MS UAM, I encourage you to not turn it into a PC versus Macintosh argument.
I want to make one thing clear. This problem is mostly because of defects in the Macintosh OS. All custom UAMs, including the NetWare UAM provided by Novell, have this same problem. Hopefully Apple will resolve this problem by adding full support for custom authentication modules sometime in the near future. As for the question of why can Macintosh clients use encrypted authentication with other Macintosh computers, including Apple's AppleShare servers, it is because Apple uses a different encryption method that requires the clear text password to be available at both ends. NT Servers do not store user passwords in a form that can be decrypted.
Installing the MS UAM on Macintosh Clients
Installing the Microsoft UAM on Macintosh clients is straightforward. If you are going to require users to use the MS UAM, you need to install it on all Macintosh clients.
Don't be too concerned about the size of the MS UAM. It's only about 30KB.
To install the MS UAM on a Macintosh client, use the following procedure:
From the Macintosh client, open the Chooser from under the Apple menu.
Click the AppleShare icon in the upper-left corner of the Chooser.
Select the zone where you installed the NT Server running Services for Macintosh. Find the NT Server in the list on the right and double-click it.
If you have already configured the NT Server to require Microsoft authentication, you will only be able to logon as a guest. However, if you have also disabled Macintosh guest access, you will get an error, as shown in Figure 10.31.
You can copy the Microsoft UAM from the Microsoft UAM Volume, which is created on the NT Server when you install Services for Macintosh.
Double-click the Microsoft UAM Volume entry.
Be sure not to put a check mark in the box of the right side of the entry. If you check this box, the Microsoft UAM Volume will automatically appear on your desktop the next time you restart the Macintosh.
If you have a logon message configured, it will appear now. Click OK to continue.
The Microsoft UAM Volume should now appear on the desktop.
Close the Chooser.
Open the Microsoft UAM Volume. There should be a folder called AppleShare Folder inside, as shown in Figure 10.33.
The AppleShare Folder contains the MS UAM file needed to provide secure logons.
Drag-copy the AppleShare Folder into the System Folder on the Macintosh Client.
By default, there is no folder called AppleShare Folder inside the System Folder. However, if you have other UAMs installed, such as the NetWare UAM, the AppleShare Folder will exist and you will receive an message asking if you want to replace the AppleShare Folder. Do not do this. Simply open the AppleShare Folder on the NT Server and copy the MS UAM file inside into the existing AppleShare Folder on the Macintosh client.
Reboot the Macintosh to take advantage of the MS UAM.
Using the MS UAM on Macintosh Clients
Using the Microsoft User Authentication Module on the Macintosh is just as easy as installing it. Here's an example of connecting to an NT Server using the MS UAM:
From the Chooser, locate an NT Server to log on to and double-click it.
If the NT Server does not require Microsoft authentication, you will be asked if you want to use Microsoft authentication or standard authentication. Choose Microsoft authentication. The Microsoft authentication window will appear.
However, if the server is configured to require Microsoft authentication, you will not be given a choice, but rather the Microsoft authentication windows will appear automatically.
Enter your user name and password. If the user account comes from a trusted domain, enter the name of the trusted domain, a back-slash, and then the user name (procurement\jgarms, for example).
Select the volumes you want to mount. If you want to select more than one volume, use the shift when you select the additional volumes.
Click OK. Volumes will appear on the desktop.
Close the Chooser.
Printing to an AppleTalk Printer
After you install Services for Macintosh, you can create an NT printer that sends jobs to any printer on an AppleTalk network. This is quite a neat feature because even if you don't have Macintosh computers on your network, you might still have a printer that takes advantage of AppleTalk networking. If this is the case, you can use NT to allow Windows and DOS clients to print to this printer exactly as they would any other printer on an NT Server.
To create a printer on the NT Server that sends jobs to a printer device on an AppleTalk network, use the following procedure:
In order to print to a printer on using AppleTalk, you must have Services for Macintosh installed. See the section Installing and Configuring Services for Macintosh earlier in this chapter for more information.
Make sure you have Services for Macintosh installed and are logged on as a member of the Administrators group.
From the Start menu, choose Settings, and then Printers. This will open the Printers windows, which shows all currently created NT printers.
Double-click the Add Printer icon to start to the Add Printer Wizard. The Add Printer Wizard is shown in Figure 10.34.
The Add Printer Wizard is used to create or connect to an NT printer.
Choose the option for My Computer and click the Next button to continue.
It might not seem obvious to choose the My Computer option, because you are in fact connecting to a computer on the network, so let's take a quick look at this. You can choose the Network Print Server option only when the printer has been created on another NT or Windows for Workgroups system, or on a Novell system if you have the Client or Gateway Services for Novell installed. For stand-alone network printers that you print to using AppleTalk, DLC, or TCP/IP, you must create the printer on your system. This is why you choose the My Computer option.
You now need to specify the port you want to add to. By default, you should see a number of LPT ports and COM ports listed. Click on the Add Port button to specify the location of the AppleTalk printer. This will bring up the Printer Ports window.
Choose AppleTalk Printing Devices from the list of available print monitors, as shown in Figure 10.35. Click OK.
If the AppleTalk Printing Devices option does not appear in the list of available print monitors, then you have not installed Services for Macintosh. See the section Installing and Configuring Services for Macintosh earlier in this chapter for more information on installing Services for Macintosh.
The Available AppleTalk Printing Devices window will appear, as shown in Figure 10.36. This window is similar to the standard Windows network browser and is used to locate the AppleTalk printer on network.
When you expand the AppleTalk zone, all AppleTalk printers in the zone will be displayed.
From the list, choose the printer you want to connect to and click OK.
An AppleTalk name must be unique in its zone. However, you can have the same name used in multiple zones without problems, since AppleTalk resources are identified and located by both their name, and their zone.
You cannot use NT to change the actual name of an AppleTalk printer. If the printer is an Apple printer, you can use the LaserWriter Utility program that came with the printer to rename it.
A window will appear asking if you want to capture the AppleTalk printer, as shown in Figure 10.38. If you capture the printer, no one will be able to print directly to the printer. Rather, they will be forced to print through the NT print spooler. If you don't capture the printer, people can bypass the NT printer spooler and print directly to the printer.
You can capture an AppleTalk print device, which prevents people from printing directly to it.
For security reasons, you should capture the AppleTalk printers. The first security issue is that people if you permit people to print directly to the printer, you have no method of auditing and tracking printer usage. The second, more critical problem is that if you don't capture the printer, someone else could capture the printer and deny everyone else access to it. Even in a smaller network where this might be easy to troubleshoot, this denial of service could result in lost productivity and angry users.
Click Close to close the Printer Ports window. The port identifier for the printer you just specified should appear in the list of available ports, as shown in Figure 10.39.
You must specify the make and model of the printer.
It is important that you choose the correct make and model for the printer so that NT knows exactly what features the printer includes and how to work with it. Choosing the wrong printer can often cause unpredictable results.
Give the printer a name, as shown in Figure 10.41. You also need to tell NT whether or not you want to make this your default printer. Since this is a server, if you already have other printers created, you probably want to select No.
Give the printer a name and specify if you want it to be the default printer when printing jobs from the server console.
Click the Next button to continue. This will take you to the screen where you specify that you want the printer to be shared to the network.
Click the Shared button, as shown in Figure 10.42. Specify the name you want the printer shared as. If you have MS-DOS or Windows 3.x clients, you should make the share name 8 characters or shorter. If you will have Windows 95 or NT clients that need to print to the printer, you should specify the appropriate printer drivers to be installed.
The Printer Properties page is used to change various settings once the printer has been created.
You should take the opportunity to enter any comments about the printer, as well as the location. If you want to change scheduling, sharing, security, or device settings you can do it now, or later as necessary. For more information on these options, refer to chapter 8, Configuring and Installing Print Services.
Click OK when you are finished configuring the printer.
The printer you just created and shared on the network is capable of receiving print jobs from any Windows NT client. This means that standard Windows clients, other NT clients, Macintosh clients, Novell clients (with File and Print Services for NetWare) and UNIX clients (using LPD and TCP/IP) can all print to this printer through the NT Server. The strength in this feature is that the clients don't need to have AppleTalk installed; only the server must have AppleTalk installed.
Printing from Macintosh Clients to an NT Server
One of the truly remarkable aspects of NT Server is how seamlessly the Services for Macintosh are integrated with the rest of the system. Perhaps this is seen best in how easy it is for Macintosh Clients to print to printers through an NT Server.
When you install Services for Macintosh, NT automatically makes all printers on the NT system available to Macintosh clients. This means there is nothing that needs to be done for your Macintosh users to begin printing. All printers created on the NT Server will appear in the same zone as the NT Server.
It is extremely important when you create printers on NT Server that you choose the correct printer type. NT knows from the printer type exactly what features are supported by the printer. With Macintosh clients, it is important to know which printers have PostScript and which don't. For example with HP printers, all printers with an M in the model name have PostScript. The M is HP's standard designation that lets you know the printer is made to work with Macintosh computers. (It also means the printer has a built-in LocalTalk interface.) If you have an HP LaserJet 4M Plus, you should be certain to select this when configuring the printer. If you choose HP LaserJet 4 Plus instead, NT will think the printer does not support PostScript and will rasterize the PostScript and send the bitmapped image to the printer, resulting in reduced print quality.
From a Macintosh client, you use the Chooser to select a printer on an NT Server exactly the same way you would to any other AppleTalk network printer.
The PostScript interpreter built into Windows NT Server emulates an Apple LaserWriter Plus v38.0.
Administering Services for Macintosh
There are three major places you will need to go to for configuring Services for Macintosh:
MacFile Control Panel. This applet enables you to get current statistics on the Services for Macintosh, including a list of the current users, what files are in use, and what volumes are shared. Also, you can use it to alerts to Macintosh users. It also enables you to configure the properties for Services for Macintosh, including the server's name on the AppleTalk network, a logon message for Macintosh clients, and the global policy for Macintosh guests.
File Manager. The File Manager is used to create, view, modify and remove Macintosh-accessible volumes. It can also be used to set Macintosh folder-level permissions, and associate MS-DOS-style extensions with Macintosh creator and type information. From here, you can also access the online help for Services for Macintosh.
Network Control Panel. From the Services page in the Network Control Panel, you can configure the AppleTalk routing and zone information for Service for Macintosh.
Additionally, there are two other places that enable you to manipulate the Services for Macintosh options:
Server Manager. You can use the Server Manager to do everything that the MacFile Control Panel does. Additionally, you can use it to create, view, modify, and delete volumes. The big advantage for Server Manager is that it can be used to configure remote systems.
MACFILE Command-Line Utility. The MACFILE command-line utility can do everythingexcept configure AppleTalk routing and send alerts to Macintosh users. It even works on remote systems.
Identifying Logged-On Macintosh Users
If you need to identify what Macintosh users are logged on, what volumes they are accessing, and what files they have open, you should use the MacFile Control Panel.
When Macintosh users connect through Services for Macintosh, they will not appear under the list of active users in the Server Control Panel. The Server Control Panel only lists users who connect using the standard Microsoft networking.
The MacFile Control Panel, shown in Figure 10.44, provides four different sets of information that enables you, as the system administrator, to find out who is access in what files through Services for Macintosh.
The MacFile Control Panel enables you to get information about what Macintosh users are connected to the NT Server.
This screen gives you a summary of connections provided by Service for Macintosh. Included are the number of connected users, the number of open files, and the number of file locks. File locks typically occur when files are opened with write access.
The other connection-related information that can be obtained from the MacFile Control Panel is as follows:
Connection information by User. The Users button from the MacFile Control Panel enables you to get statistics about the users currently connected to Services for Macintosh, as shown in Figure 10.45.
You can find out to what volumes a particular user is connected.
The top box includes a list of all the current Macintosh users, their computer name, how many files they have open, and how long they've been connected. When you click a user, the bottom window will show the volumes that user is connected, the number of open files the user has on that volume, and how long the user has been connected to that file.
While you have a user selected in the top window, you can select the Disconnect button at the bottom of the screen. If the user has no open files, you will be asked if you want to disconnect the user. Click Yes if you really want to disconnect the selected user. This will disconnect the user from all Macintosh volumes.
However, if the selected user has files open, NT will warn you that the user has open files and could loose data if you disconnect the user. It then asks you to confirm that you really want to disconnect the user. Click Yes to disconnect the user. This will disconnect the user from all Macintosh volumes.
If you want to disconnect all users, you can use the Disconnect All button.
Connection information by Volume. With the Volumes button, you can get information about which volumes are being accessed by which users, as shown in Figure 10.46.
You can find out what users are connected to a particular volume.
The top window shows all the Macintosh-accessible volumes on the local server. It also includes the number of open files on each volume and the actual path where the share is located.
If the path for a particular volume does not fit in the window, as with the Microsoft UAM Volume in the Figure 10.34, you can double-click the volume name and NT will display a window containing the full path to the volume.
When you click a volume from the top window, the bottom window displays all the users attached to that volume, including how long the user has been connected and whether or not the share is in use. The definition of "in use" in this case refers to whether or not the user has file locks in that volume.
If you click a user and click the Disconnect button, NT will ask you to confirm the request. If you click Yes, the user will be disconnected from the selected volume only. If you click the Disconnect All button, all users on that volume will be disconnected. This will have no effect on user connections to other volumes.
Connection information by File. If you simply want a list of all the files that are being accessed by Macintosh clients, you can use the Files button. This gives you a list of all the in-use files, including the name of the user accessing the file, whether the file is opened for read or read/write access, the number of locks the user has on that file, and the full path to that file on the local server. This information is shown in Figure 10.47.
You can find get a list of all files that are currently in use by Macintosh clients.
More often than not, you will not be able to read the full path of the files listed in this window. If you want to know the full path to a file, you can double-click the file name and NT will display a window containing its full path.
You can use this screen to close a user's access to particular files. This can be done by clicking on a file fork you want to close and then clicking on the Close Fork button. NT will ask you to confirm this action. If you click Yes, the user will be disconnected from the particular file.
However, if you click the Close All Forks button, all files open by Macintosh users on this server will be closed.
Sending Messages to Macintosh Clients
Windows NT's Services for Macintosh supports the capability to send alert messages to Macintosh users. This requires a Macintosh client running AppleShare 2.1 or above (built-in to System 7.x), and requires that the client be logged into the server. This differs from standard Microsoft clients, which aren't required to be logged into a server to receive alerts.
The NET SEND command and the Server Control Panel applet cannot be used to send messages to Macintosh users. So, if you have Services for Macintosh installed, be sure to send any important server alerts to your Macintosh clients as well.
Alerts can be sent from the MacFile Control Panel. From the MacFile Control Panel applet, simply choose the Users button. This brings up a window that displays all the currently connected Macintosh users, as shown in Figure 10.48.
You can send messages to the selected users or to all users.
From here, you can also choose to send the message to all the users on the Macintosh local computer. You can enter up to four lines of text. Once you have entered the message, click OK and it will be immediately sent to the selected users.
While the current AppleShare client for Macintosh supports sending messages from the server to connected clients, there is no provision for sending messages to clients who are not connected, or from client to server, or from client to client.
Mapping File Extensions to Macintosh Creator and Type Fields
As described earlier in this chapter, creator and type information is very important for Macintosh files. This information allows the Macintosh Finder to know what application to launch when a user double-clicks it. It is also used to filter what a user sees when he or she tries to open a file.
Windows NT comes with a set of default mappings, as well as an extensive list of common Macintosh creator and file types.
To view the current mappings, or to set and create new ones, you'll need to use the Associate option from the MacFile menu in the File Manager. The Associate window is shown in Figure 10.50.
The Associate window is used to set DOS extension to Macintosh creator and file type mappings.
The pick list at the top of the screen contains approximately 60 of the most common MS-DOS file extensions.
The scroll list at the bottom of the screen contains almost 70 common Macintosh creator and file types. For instance, you can scroll down and see the Microsoft Word 6.0 documents have creator MSWD and type W6BN. If you want to add new creator and file types, use the Add button. Likewise, you can select an existing entry and use the Delete button to remove it.
Let's take a look at how this works. From the list of MS-DOS extensions, choose BAT. You'll see that files with the BAT extension will be mapped to LMAN/DEXE and are LMAN Executables, as shown in Figure 10.51.
MS-DOS files with the BAT extension are mapped to Macintosh file type LMAN/DEXE.
Now if we wanted to change that, we could simply choose a different creator/type combination from the list and click the Associate button. For instance, if we wanted Macintosh users to be able to double-click MS-DOS batch files and open them in a text editor, we could select the LMAN/TEXT option from the top of the creator/type list and click the Associate button, as shown in Figure 10.52.
Now Macintosh clients will automatically open MS-DOS batch files with a text editor.
Now, from a Macintosh client, all files with the BAT extension will be recognized as text files and can be opened in any program the recognized text files.
So why is it important to establish these associations? Well, normally the Macintosh stores and maintains these all by itself. However, if the file originates on a PC, it does not contain the creator/type information. The Macintosh then does not know what to do with the file. For instance, let's say that you used the Windows version of Microsoft Word 6.0 to create a file and saved it to an NT Server. Now if you went to a Macintosh and used Microsoft Word to look for the file on the NT Server, if the file associations were not created properly, the document would not even show up in the open list on the Macintosh. This is because the Macintosh can't find a valid creator/type for the file. However, with file associations, as long as you named the file with a DOC extension, the Macintosh version of Word would recognize it because NT Server would provide the creator/type information to the Macintosh.
Administering Services for Macintosh from an NT Workstation
Although you can't set up NT Workstation as an AppleTalk file and print server, you can use an NT Workstation to administer NT Servers running Services for Macintosh. In order to do this, you need to install the AppleTalk protocol on the NT Workstation. In addition to enabling you to use Server Manager to manage Services for Macintosh on NT Servers, there are two other benefits for installing AppleTalk on an NT Workstation:
You can use the NT Workstation to print directly to an AppleTalk printer
You can use third-party products that take advantage of the WinSock-compatible AppleTalk stack to communicate with other devices on the AppleTalk network. Possible products could include client software that allows NT Workstations to access files from an AppleShare server.
To install the AppleTalk protocol stack and administer remote NT Servers running Services for Macintosh, follow these steps:
On the NT Workstation, make sure you are logged on as a member of the local Administrators group.
Install the Server Tools for Windows NT. These can be found on the NT Server CD-ROM, and include utilities such as Server Manager, User Manager for Domains, and others. For more information on installing these tools, see Chapter 9, Working with Clients.
Open the Control Panel and double-click the Network icon.
Click the Protocols tab. This takes you to the Protocols page, which lists all currently installed network protocols.
Click the Add button. This will present you with a list of all available network protocols.
Select AppleTalk Protocol, and click the OK button.
You might be asked to provide the location of the Windows NT Workstation installation files. If so, enter full path, such as f:\i386, where f: is the CD-ROM drive. Click the Continue button.
NT Setup will copy files from the distribution media and make modifications to your system. This might take a few moments. When completed, it will return you to the Protocols page in the Network Control Panel window. You should see the AppleTalk Protocol in the list of installed protocols.
Click the Close button to continue. NT will review the network bindings information and start the AppleTalk protocol so you can configure it. The Microsoft AppleTalk Protocol Properties window will appear, as shown in Figure 10.53.
You must configure the AppleTalk zone where you want your NT Workstation to reside.
Choose the Default Adapter and Default Zone for you NT Workstation.
Your network adapter should be listed in the Default Adapter list. If you have more than one network adapter, the default adapter should be listed. If you have any third-party utilities that allow your NT Workstation to take advantage of the AppleTalk protocol, this is the adapter they will be bound to.
Additionally, if you have an AppleTalk router on the network, the default AppleTalk zone should appear in the Default Zone. For most uses, this is really pretty unimportant, because NT Workstations do not publish services by default. However, if you have any third-party utilities that enable your NT Workstation to publish services to the AppleTalk network, this is the zone where they will appear.
Click OK to continue. A message will appear telling you that the AppleTalk protocol has been configured.
Click OK. You will be prompted to restart you computer.
Click Yes to initiate a system restart.
When the system restarts, the AppleTalk protocol will be fully installed and you will be able to use the Server Manager utility to manage NT Servers running Services for Macintosh.
Additionally, you can use the Add Printer Wizard or the Print Manager to create a local printer that can be used to print directly to an AppleTalk printer on the network.
The MACFILE.EXE command-line utility will not be installed on the NT Workstation. If you want to use this utility to administer remote NT Servers running Services for Macintosh, you can copy the MACFILE.EXE executable from an NT Server with Services for Macintosh installed onto the NT Workstation.
Using the MACFILE Command-Line Utility
When you install Services for Macintosh, you also get a command-line utility called MACFILE.EXE. This utility performs four major functions. While three of these can be done from a graphical front-end, with the MacFile Control Panel applet, or with the Server Manager, the fourth function, FORKIZE, can only be done through the MACFILE utility. Additionally, it's nice to have a command-line tool for appropriate tasks, such as writing batch files.
Even if you're not interested in command-line utilities, look at the MACFILEFORKIZE. This command has no graphical equivalent, and deserves careful attention.
One of the additional benefits of the MACFILE command is that it enables you to configure remote NT Servers running Services for Macintosh.
The MACFILE utility is broken down into four basic commands:
The MACFILE VOLUME command enables you to add, remove, or change network-accessible Macintosh volumes.
/addSpecifies that you want to add a Macintosh-accessible volume.
/removeSpecifies that you want to remove a Macintosh-accessible volume.
/setSpecifies that you want to change options on an already existing Macintosh-accessible volume.
/server:\\computernameSpecifies the name of the NT Server running Services for Macintosh that you wish to administer. If this switch is omitted, changes will be made to the local computer.
/name:volumenameSpecifies the name of the Macintosh-accessible volume you wish to create, remove, of modify. This can be between 1 and 27 characters and should be enclosed in quotation marks if it contains any spaces or special characters.
/path:directorySpecifies the path to the directory to be shared on the AppleTalk network. Only include this when creating a new share.
/readonly:[true | false]If true, users cannot make changes to any files located on the volume, regardless of additional rights given to them on particular folders within the volume. If false, user access to particular files is determined on a folder-by-folder basis. If this switch is not included when creating a volume, changes to the volume will be permitted (readonly=false).
/guestsallowed:[true | false]If set to true, Macintosh users can connect to the volume as a guest. If false, users will not be able to connect to the volume as a guest. When creating a new volume, the default is for guests to be able to logon (guestsallowed=true). NOTE:This is independent of the Windows NT Guest user account. For more information on this, see the Understanding Macintosh Guest Logons section from earlier in this chapter.
/password:passwordSpecifies that users need to enter a password when connecting to this volume. If you don't use this switch, all access control is based on their user account and users will not be required to type an additional password when logging on. Using this option along with /guestsallowed:true, enables you to effectively create a resource with share-level permissions, instead of user-level permissions.
/maxusers:number | unlimitedBy using this switch, you can restrict the number of users that can connect to a particular share. If you don't specify this switch when creating a volume, there is no limit placed on the number of users who can connect.
The MACFILE DIRECTORY command is used to set the owner, group, and permission information on a directory in a Macintosh-accessible volume.
/server:\\computernameSpecifies the name of the NT Server running Services for Macintosh that you wish to administer. If this switch is omitted, changes will be made to the local computer.
/path:directorySpecifies the path to the directory in a Macintosh-accessible volume where you want to modify permissions, owner, or group information. Remember, Macintosh file permissions are designated on a per-folder, not a per-file, basis.
/owner:ownernameSpecifies the new owner of the folder. If you omit this switch, the ownership will not change.
/group:groupnameSpecifies the new primary group for the folder. If you omit this switch, the primary group will not change.
/permissions:permissionsThis switch indicated the permissions to be set on the specified folder. With this switch you can set standard Macintosh folder permissions, which include the ability to see file, see folders, and make changes. You can set each of these options for the owner, the primary group, and everyone (also called world). In addition, this switch can be used to designate that the folder cannot be renamed, moved, or deleted. You can specify that the changes should be applied to all subdirectories within the specified directory. This switch is used by specifying a 11-digit string of ones (1) and zeros (0). A one (1) is used to grant the permission, and a zero (0) is used to revoke the permission, following this pattern:
Allows the Owner to see files
Allows the Owner to see folders
Allows the Owner to make changes
Allows the Primary Group to see files
Allows the Primary Group to see folders
Allows the Primary Group to make changes
Allows Everyone to see files
Allows Everyone to see folders
Allows Everyone to make changes
Specifies that the directory cannot be renamed, moved, or deleted
Specifies that changes should be applied to the current directory and to all subdirectories.
The MACFILE SERVER option enables you to change default server configurations, such as the server's name as it appears on the AppleTalk network, guest access permissions, and the maximum number of users.
macfile server [/server:\\computername] [/maxsessions:number | unlimited] [/loginmessage:message] [/guestsallowed:[true | false]]
/server:\\computernameSpecifies the name of the NT Server running Services for Macintosh that you wish to administer. If this switch is omitted, changes will be made to the local computer.
/maxsessions:number | unlimitedSpecifies the maximum number of Macintosh users that can be simultaneously connected to the server.
/loginmessage:messageSpecifies a message that will be sent to Macintosh clients when they connect to the NT Server. This is supported by all AppleShare 2.1 clients and greater (includes all System 7 clients). If left blank, no message is sent to clients when they connect.
/guestsallowed:[true | false]Specifies whether or not Macintosh clients can connect as guests. If set to true, guests are able to connect to Macintosh-accessible volumes. However, you can restrict guest access to volumes on a volume-by-volume basis by using the MACFILE VOLUME command. Additionally, if this switch is set to false, all Macintosh guest access will be denied, regardless of the settings on individual volumes. By default, Macintosh computers can connect as guests.
This is independent of the Windows NT Guest user account. For more information on this, see the Understanding Macintosh Guest Logons section from earlier in this chapter.
The MACFILE FORKIZE can be used to join two separate files together into the a single Macintosh file with a data fork and a resource fork. Additionally, it can be used to set the file's creator and type information.
The true usefulness of this command is in its capability to set the file's creator and type information. While the capability to join to separate files together into a single Macintosh file is useful, most people will not need it.
/server:\\computernameSpecifies the name of the NT Server running Services for Macintosh that you wish to administer. If this switch is omitted, changes will be made to the local computer.
/creator:creatornameThis specifies the program that was used to create the file. When a Macintosh user double-clicks a file in the Finder, the creator information is used to determine what program to start. It can be up to four characters. Every company that writes software for the Macintosh is required to register their creator code with Apple to ensure its uniqueness.
/type:typenameThis specifies exactly what the file is. This helps the program called by double-clicking the file to determine how to handle the file.
/datafork:filepathSpecifies the name of the file you want to use as the data fork.
/resourcefork:filepathSpecifies the name of the file you want to use as the resource fork.
/targetfile:filepathIf you are joining two files into a single Macintosh file, this specifies the name of the file you want to create by combining the resource and data forks. If you don't specify the /datafork and /resourcefork switches, this is the file whose information you are modifying. This file must reside on an NTFS volume on the server specified by the /server switch.
Shortcomings and Problems
If you read through this chapter and the rest of the guide, you will catch glimpses of where I point out the limitations of Services for Macintosh. I thought this was important enough for people to understand, however, so I created this section to bring them together in one place.
Some of these limitations are lack of features, and others are just things to be aware of. They are as follows:
NT Server cannot read Macintosh CD-ROMs. Although you can create a Macintosh-accessible volume on a Windows CD-ROM, NT is completely unable to read Macintosh CD-ROMs. This is because most Windows CD-ROMs use the ISO 9660 format, whereas most Macintosh CD-ROMs use the High Sierra format.
NT RAS does not support dial-in AppleTalk clients. The standard remote networking for Macintosh clients is AppleTalk Remote Access (ARA). This is not, however, supported at this time by NT Server. Macintosh clients can, though, dial into an NT Server using TCP/IP over PPP. This requires usually a third-party add-on such as MacPPP. When Macintosh clients dials in using this method, however, they cannot access the Macintosh volumes on the NT Server because this requires the AppleTalk protocol. Microsoft expects to have ARA support in NT Server soon.
The Microsoft UAM is not fully integrated with the MacOS. If you use the Microsoft UAM, you cannot take full advantage of aliases in System 7.x. This can be an extreme inconvenience to Macintosh users. This is discussed at greater length earlier in this chapter.
Services for Macintosh requires an NTFS partition. In order to install Services for Macintosh, you need an NTFS partition. This is because the installation process creates a Macintosh-accessible network volume that contains the Microsoft UAM. Due to the dual-fork nature of Macintosh files, they cannot be stored on a FAT or HPFS partition.
AppleTalk printers do not support user authentication. Under Windows NT, you can restrict access to printers based on a person's user account. However, the AppleTalk Printer Access Protocol (PAP) does not provide authenticated information on the user who submitted the print job. Additionally, by default Macintosh clients can print to any printer created on the NT Server. With Macintosh clients, all print jobs are submitted using the built-in SYSTEM account. This means that you cannot control printer access for individual Macintosh users.
Using NT as a PostScript interpreter is limited. One of the most amazing features about Windows NT is that it can enable clients to send PostScript jobs to any NT printer, even printers that don't understand PostScript. While this a great feature for Macintosh clients, because the standard laser printer driver is PostScript, there are limitations. Probably the most obvious is that when NT converts the PostScript code into a bit-mapped image that can be printed to any printer, it does so at 300 dpi. Until recently, this might not have been a real problem, but today with even the cheapest laser printers supporting 600 dpi, the difference is noticeable. If print output is of high concern, be sure to use a real PostScript printer.
Macintosh guest access is unrelated to the Guest user account. Even if you have the NT Guest account disabled, Macintosh users can still access Macintosh-accessible volumes as guests. For more information on this, see the section Understanding Macintosh Guest Logons earlier in this chapter.
Services for Macintosh allows for a breach in NT file security. Although by its very nature, NT is not supposed to allow you to assign ownership of files to other users, there is a way around this. If Services for Macintosh is installed, an NT user can use the Macintosh permissions to assign ownership of files to a different user, which is normally not permitted. For more information on this, see Chapter 25, "Advanced Security Guidelines."
This chapter discussed using Windows NT Server as a complete server solution for networks with Macintosh clients. We looked at the core Macintosh services provided by NT Server, including the ability to act as an AFP-compliant file server, as well as providing Macintosh print services, and native AppleTalk routing.
We looked at the structure of a Macintosh file and how it differs from a standard PC file. In addition, we looked at how NT Server provides on-the-fly translation of long file names for Macintosh clients. We continued by looking at the Macintosh AFP permission structure for restricting access to network resources, as well as the differences between a Macintosh guest user and a PC guest user.
The chapter continued with a step-by-step installation guide for Services for Macintosh, including a guide to setting up AppleTalk printing. We also took a look at how and when to set up AppleTalk routing by looking at two common network scenarios.
We also took a close look at the Microsoft User Authentication Module (MS UAM) and how it can be used to strengthen the security of your network. We also saw that the MS UAM has some pitfalls that prevent Macintosh users from performing certain functions.
Next we looked at tools that are used to administer the Services for Macintosh, such as the File Manager, the Administrative Wizard, the MacFile Control Panel applet, the Print Manager, and the MACFILE command-line utility. Included in this discussion was information on remotely administering Services for Macintosh from remote NT Server, as well as NT Workstations.
Finally, the chapter ended with a look at some of the limits of NT Server's Services for Macintosh. While NT provides a robust and powerful server platform for supporting Macintosh clients, it can't do everything and it is important to understand the limitations.