Volume Number: 21 (2005)
Issue Number: 1
Column Tag: Programming

Mac OS X Server's Print and File Services for Mixed Networks

by Mark Underwood

Providing Essential Services in the "Mixed" IT World

INTRODUCTION

X Server was designed from its first iteration to supplant the need for multiple servers, each providing vertical access protocols. Buy a windows server to support Windows boxes, a Mac server for Mac boxes, ad nauseum. Hey, this is a Mac-based Server, right? So as the X clients can talk the multiplatform talk, X server should be able to walk the walk with ease, right? That it does. Not only does X Server speak AFP-ease (Classic Mac), SMB-ese (Windows) and NFS-ease (UNIX), but it can over all of the networking protocols X server handles without hyper configuration! In this article, we'll give the detailed instructions for those support staffers who want to set up and customize print and file services for Mac OS X Server.

No way is this article intended to teach you how to set up and configure a MacOS X Server efficiently, effectively, and with the least amount of wear and tear to your geekdom. In fact, we assume you already have an X server in that state of mind and are just wanting to configure the file and print services properly to work in an existing mixed network. We also aren't going to fidget with the internals of setting up a WinNT PDC or an Active Directory server hierarchy - again, we assume you have one of those already that you're either trying to replace with an X server, or make sure the X server works with it.

In general, when you set up an X server, the good news is that you don't have to know everything up front - all of the services cane be added/changed/reconfigured at will. But you will have to get a couple of things right the first time in order to avoid a nasty quandary later -- the domain name this server is working on and if this server will be the primary or secondary directory server. If you're adding the X server as the first server in your LAN, congrats! You can provide the best for all worlds without too much hassle. If you're migrating a Windows server to an X server, double-kudos! It's an easy migration, and we'll step you through the basics for the file and print services in this article. If you're adding an X server into an existing domain already controlled by a Windows-based server and only want the Mac Server to provide services to Macs, shame on you! It's worth the extra set-up to replace the Windows server to act as everything and so help to secure your LAN better.

X SERVER RE-CONFIGURATION - GENERAL FILE SERVICES

Either sitting at the X server, or from a X client with the Server Admin Tools installed, start up the Server Admin program, which is located by default in a folder called "Server" inside "Applications". If this is your first time opening this program, you'll need to click on "Add Server" and give the Rendezvous or IP address of the server, along with one of the administrator-level accounts on the server and its password. In a few moments, the current status of the server and a quick overview of its status will be listed on the left pane. Click the triangle in front of that name downward and you'll get the complete list of services, and their current state (green - go, yellow - recoverable problem, red - ouch, clear - service not active).

We'll start with the Mac-side file services - which works for both pre-X and X Mac clients. This protocols is known as AppleShare File Protocol, or AFP for short. Click once on the indented item named AFP in the list, then on the Settings tab at the bottom, and you'll get this dialog:

Here we enable Rendezvous and AppleTalk browsing to make sure the server shows up under the "Browse" button in the "Connect to Server" dialog (for MacOS X) or under the list of servers in the same AppleTalk zone of Chooser (For Pre-X or Classic mode). Add a greeting that will be shown to the user once connected, and check the last box to only show it to them the first time they log in...not subsequent times.

Clicking on the Access tab here shows the next set of changes/settings to review:

This group of settings have to do with how people log in to the server. Enable Guest access lets that button be shown on the Chooser for Pre-X/Classic access, or a "Guest" account to be used under X. Enable secure connections is used with Kerberos or the standard basic encryption technique for AFP under Pre-X/Classic. We'll talk more about Kerberos later, but there's no problem with having this option checked whether you use that approach or not. Enable administrator to masquerade... gives the System Administrator account to "pretend" it's a normal user ID as needed for diagnostics and checking access rights. Set the maximum number of connections (both normal and guest) to what you want the server to handle, then walk on to the Idle Users tab.

While the defaults (which you see above) are pretty much okay, if you have people who leave their Macs running all the time you may want to have them disconnected when idle. This is the place to set that. You can also set a message that explains why they've been disconnected.

If you've changed any of these, you'll have the "Save" button active in the lower right. Click on that and your changes are put into place right away. If the service isn't running, the Stop Service icon in the top pane will be a green Start Service one. Click that and you're done with AFP.

Configuring for UNIX file service clients is very easy. Click on the NFS service in the list on the left, and then the Settings tab at the bottom. Here's the dialog:

Defaults here are pretty much what you'll stick with, since underneath X is UNIX. But if you're a stickler for the protocols used on your network, or if you want to optimize the number of simultaneous UNIX clients, here's where to change and save the settings.

X SERVER RE-CONFIGURATION - WINDOWS SERVICES

As you might guess, configuring the Windows file sharing is the most difficult of the client triumvirate. It involves a two-stage process: setting up Windows-type authentication (so that the Windows machines can log in) and settings up the Windows file sharing protocols (so that they show up at all in the Network Neighborhood).

Authentication for Macs and UNIX boxes is straight forward - if the user ID is in the list of users on the X server (whether in a directory or in the list of local users), you get in. Windows isn't that easy. We must create a directory and services that the Windows clients can understand and use. All Windows clients can use the "basic" Client for Microsoft Networks access, which is WINS-based or NT Services (depending on the client). Newer clients can also use a domain controller (NT-based servers) or Active Directory (2000 and later servers) to authenticate and encrypt the sessions. In addition, 2000 and XP can use an LDAP-based authentication, but that has to be added via 3rd party extensions.

We're going to examine the three possible X server directory service configurations and indicate which context they're used, so you can select which one fits your bill. First is the Open Directory Master, as shown in Figure 5.

Click on your Open Directory service in the left list, then on the Settings tab. The "Role" menu has four options: Standalone Server, Connected to a Directory System, Open Directory Replica, or Open Directory Master. If you took the defaults when you set up your X server, you may see "Standalone Server" here. We will have to change that to one of the others, of course...but which one? Here's how to decide:

Connected to a Directory System means there's already another directory service in your LAN, and you want the X Server to use that one without replicating the directory on the server. That directory can be an NT-server, Active Directory Server, LDAP server, etc. Setting the server up to do this is done not in Server Admin, but with the normal Directory Access program, and must be done on the server itself - not from a remote location. While this sounds like what you may want if you have such a server in place, doing this would also force the Macs and UNIX clients to authenticate to the existing server...and would eliminate all of your Pre-X clients and some of the UNIX clients, as there are restrictions on this approach. If you feel you fall into this category, we recommend that you leave this server as an Open Directory, and change the Windows server settings instead - we cover those later in the article.

Open Directory Replica means you have a master X server someplace that you want this X server to bow to and get orders from. A directory replica is a way of divvying up the directory services load when you have more than a few hundred folks using it. Since in this example, we're trying to get the first step done, we don't use this setting now. However, once we get the first X server's configuration in place, the rest of the X servers that you add can be "chained" to it using this setting and providing the right information. This setting would also be the one to use if your existing authentication directory was UNIX or LDAP based.

Open Directory Master is the best setting for doing the deed, because it provides something for everyone. It works as a standalone directory server, it works as the boss for replications, it allows the window directory services to be part of its "domain", and it handles the Kerberos mastery when needed. Pick this one and you can't go too far wrong. Skip the replicas section, dodge the Kerberos record for now, and move over to the Protocols tab.

Under the Open Directory service is the OpenLDAP protocol. LDAP (Lightweight Directory Access Protocol) needs a few pieces of information to help its schemas and search results: the search base, the number of returned results, and how long before giving up on a search. The latter two can stay at their default values...but the search base controls the default scope of the stuff returned. If it's like in our example - dc=local - leave it alone and go on to the Authentication tab. If it isn't, then you may have entered incorrect information when you installed X server...and unfortunately, changing it is rather iffy to do (short of a few unsupported command hacks apple didn't recommend but would work) without reinstalling. If you didn't get dc=local, or find that the field can't be edited, send me an email, and I'll be glad to pass along the non-reinstall way (along with a heavy-duty dose of caveat emptor).

Notice that all of these settings are blank? These are the exceptions to how authentication is handled for odd circumstances, and doing nothing in these cases is the default approach. All of the options are pretty much self-explanatory, so I won't go deeply into them here. One we will touch base on is the password matrix to enforce stringent types of them. Pick your established practice of them (monthly, needs at least a number or two in it, etc.) and match anything you already have in the existing window directory, if you use one. Save your changes and let's move now to the Windows service settings that have to change.

Click on the Windows service at the bottom of the left list and then on the Settings tab at the bottom. The General sub-tab here picks the way the Windows-world will see this X server as a server, and again the "Role" menu gets tricky. Only three choices here, but they're really important with respect to an existing Windows/Mixed network or directory schema, so we'll go into a lot of depth here. The three choices are Standalone Server, Domain Member, or Primary Domain Controller.

A Standalone Server is the role for an X server if it is replacing an existing Windows file/print server, or if you never had a server to begin with and have a mixed client network.

A Domain Member server role is for this server if its not the main Windows file/print server controller - like the "replica" from the Open Directory settings.

The Primary Domain Controller (PDC) is only if you have an NT-server that you're replacing, that uses the old style of domains - pre-Active Directory days.

How to decide? What do you have now?

If you have no Windows-based file/print servers, then standalone.

If you have NT-based file/print servers, then PDC for the main X server and domain member for secondary domain controller roles.

If you have Active Directory, you are back to the Open Directory settings - see above.

Here are how those three dialogs look, and what to put in the fields.

In all three, the "description", "computer name", and "workgroup" are what you would use if configuring a Windows server. "Name" and "Description" show up by the icon for the server when browsing for them, and "workgroup" is the critical value used to stick the server in with the other associated machines. This is not the Windows domain! That is used by Active Directory, and would be constructed there. This is the good ole Windows workgroup those folks are familiar with seeing in the Network Neighborhood.

So with this tab, it's just the type that is important. Now we move to the Access tab.

Very critical setting here: Allow guest access. Turn it on. This isn't what you think it is, although you get that as a side-effect of turning it on. You see, the broadcast of what file and print servers are "seen" when you open the Network Neighborhood under Windows is dictated by if that server has guest access or not. If not, then you don't see them browsing. You have to connect to them by name or IP address directly - something normal Windows users may not know right off the bat. They are used to browsing for services (sounds like a game show - with Art James or Monty Hall, perhaps), so give it to them. If their PC has a "Guest" account, then its also needed to let users of that account even log in to the X server. But it's not creating an account called "guest" for the server itself - just the file and print services from the windows clients only. There. Keep it clean and as secure as possible.

Moving on to the advanced tab...

Okay, what we want here depends on that type of server again. If you chose standalone or domain member, check the Workgroup Master Browser. If PDC, check both Workgroup and Domain. If Active Directory is the way, check neither.

WINS is the really old access method. If you support 95 and 98 clients, have no domain or directory servers, and run really old 16-bit Windows programs, you may need this enabled. If you have a really, really old NT-type set up that has already a WINS server enabled on it, and you want this X server to use it, then you register the server with that old clunker here. Skip the virtual share point concept for now...that's another article for another day. Save settings and now we go to print.

X SERVER RE-CONFIGURATION - PRINT SERVICES

<Whew!> After that mess, print's a walk in the park! First off, you define the printer to the server as you would on X client through the Printer Setup Utility in the Utilities folder. Yes, you can share USB/Firewire printers through X server. Yes, anything it can see, you can share to anyone else - Windows, Macs, UNIX, etc. In fact, once you have defined the printers in Printer Setup, they will automatically appear under the Server Admin Print service. Click on that line on the left, the Settings tab at the bottom, and then the Queues at the top, and you should see all of the currently defined printers that the server knows about:

To examine the server-related settings for the automatically-generated print queue, select the name and then click on the "/" button under the list ("+" adds a queue, "-" removes one). You'll get the guts of the queue:

Here we go. The "sharing name" is what you want folks to "see" as the name of the print queue. Remember that some characters don't map too well on Windows and UNIX boxes, so use underscores and hyphens instead of spaces. Also, really old Windows clients can't handle more than eight character names too well.

Check all of the supported protocols - it doesn't hurt. AppleTalk is for the Pre-X crowd and shows up in the Chooser, LPR is for UNIX and raw MacOS X through Rendezvous, SMB is for Windows. Technically, any client can handle printing through LPR, which is via direct IP...but you get better results to use the local parley for each as needed. Check off the quota option if you need to restrict the use or quantity of printing - but those details are then passed to the Workgroup Manager to allow associating it with users, groups, or specific machines, and yes, that's again for another day. Click Save, and the printer is ready to go!

Now that the server's happy, what do we have to do on the client end?

CONFIGURING MAC OS X TO USE THE SERVICES

With the server ready to go, let's turn our attentions to the Mac. Everything will be automatically handled under X (it's an X server folks...) - but where do we find these services?

File services are done through the "Connect to Server" menu under the Finder's Go menu, and the print services are accessed and added through the Printer Setup utility - no brainers, right? But since you're in a mixed world, when you go to mount an X server volume, you may now see more things than were originally there...or more than what you expected.

Since X can handle all three flavors of file/print services (Mac, Windows, UNIX), when you do a general Browse via the Connect to Server, you will see all three ways to connect. The other two clients will see only what they're supposed to see. Will that throw you or your end users? If so, you can turn off the other two ways on the X client...or use those extra methods to your advantage. Let's see what I'm talking about by trying it from a Mac:

If you click on the Network icon on the Finder's toolbar...or to the Browse button under Connect to Server, you'll see this sort of window. And the three top folders are the three ways to access the services. An IP address shows straight IP servers (UNIX and such - using NFS). The "KAUi" folder is the Windows workgroup we put the server in (Windows using SMB). And the "Local" folder is the AppleTalk/Rendezvous set of services (Macs both old and new using AFP). Punch into a folder, see the machines/services it contains. Let's switch to a column view to show this hierarchy:

Here we go down the Windows path...KAUi is the workgroup, Osiris the server (see all the other windows boxes here? All of them have "guest" enabled...) and we click on the Connect button to provide the list of shared server mount points that will then be available.

Let's wander back down the AFP path...

We go through the AppleTalk zone named Local to the server named Osiris (note the case is sensitive now...that's a dead giveaway), and get a straight Kerberos prompt to mount it, since we turned that on in our choice of Open Directory server authentication. So right here, we see a reason why you need both ways to go from a X client. If you have a person needing to use services that doesn't have an account, then SMB guest access will provide a secure, non-intrusive approach. Permissions to the guest access control what that user will see.

CONFIGURING WINDOWS TO USE THE SERVICES

Meanwhile on the other side of the client, what did all of this configuring and such buy us? Well, it looks even simpler from a Windows user's perspective - another feather in your decision-making cap! Here's the basic Network Neighborhood:

Ah! Sacrilege! A Windows Figure in a MacTech Magazine?!? No, just conclusive proof that X server does the trick...see the icon for Osiris? That's a Mac X Server! It even says it from the description we put in to the server settings! They'll flinch but be in awe when they double-click on that icon and see...

WOW! Is that the proverbial duck I hear quacking? Look! All of the X server-based mount points show up as mountable folders...and there's the shared printer queue! This is spiffy...and we didn't have to do any wicked tweaks or buy 3rd party software to do it! Hey, may we can add an X server shared printer that easy...

No way! Too easy! How did this happen? Did the Boys From Redmond invade Cupertino when Steve wasn't looking? Tsk, tsk, tsk. You, the Mac Faithful, should have known better. If it works, it's a Mac, right? And you Switchers - both IT staffers and end users - did you think they were going to forget that "mixed" is just that? Negatory!

CONCLUSIONS

Here we see how the whole concept of a "mixer" changes...with the advent of consistent document formats in all of the major apps for the last three years, the next step of making the clients and servers really see and interact each other normally was icing on the cake - but a very tasty one indeed, and well worth the UNIX revision that was X.

As you might guess, once this is in place, other side-effects come in, such as straight point-to-point file transfers, cross-platform co-authoring, and more. I won't even begin to talk here about the system administrator benefits, such as adding Macs to the Active Directory pool as if they were PCs, or performing full user/group administration to even an all-PC shop from a single X server to avoid all of the security and hack issues in Windows-based servers. No, I shall leave those for a future article or as a joyous exercise for the IT migration student.

by Mark Underwood