Embracing Unix and Linux Desktops -- Microsoft Certified Professional Magazine Online

Embracing Unix and Linux Desktops

These OSs work well on a Windows network when it comes to printing. File-sharing and e-mail, however, are more complicated.

By Don Jones
05/01/2003

Unix and Linux clients can do quite well on a Windows network. Microsoft, in fact, released its own Services for Unix, which provides some basic cross-compatibility features for Unix clients accessing Windows servers. Other, more robust interoperability solutions are also available for various network services. Fortunately, Unix has been using TCP/IP for longer than Windows, so the two operating systems at least have a networking protocol in common.

Authentication
One of Windows 2000’s most touted features was its new native authentication protocol, Kerberos. Microsoft didn’t invent Kerberos, so it’s no surprise that Unix platforms have a number of Kerberos options. Unfortunately, Microsoft did have to extend Kerberos a bit to make it work well with Windows, so cross-platform domain authentication still isn’t a cinch.

Most Unix clients can authenticate to a Kerberos realm, which Microsoft calls a domain. Unix servers can act as quasi-domain controllers within a realm, and Active Directory supports trusts between realms and domains. The practical upshot of this capability is that Unix clients can authenticate to a Kerberos realm, which is trusted by an AD domain, effectively authenticating to the domain itself. Unfortunately, that cross-compatibility isn’t perfect. For example, realm members can’t belong to AD user groups, meaning you have to set up some kind of user account mapping to continue to assign security permissions to groups and have Unix users fall into those groups. It’s all pretty complicated.

Fortunately, Unix clients can interoperate directly with AD domain controllers (DCs). For example, Unix Kerberos implementations can request Kerberos tickets from a DC and use those tickets to access Unix-based resources in a realm that trusts the ticket-issuing domain. To authenticate to AD, Unix clients simply need to use the Kerberos utilities, included with most Linux builds. Unfortunately, the exact usage of these utilities differs from brand to brand, so you’ll need to consult the system’s documentation. It’ll involve inserting the phrase “AD domain” wherever the documentation mentions a “Kerberos realm.”

For example, you’ll need to create a user account in AD to represent each Unix host. Just set the new user’s name to be the name of the Unix client. Then open a command-line window and type:

Ktpass.exe –princ host/computer name@domainname –mapuser username –pass password –out UNIX/ machine.keytab.

Computername and username should be the same, and the result will be a keytab file you can copy to your Unix client computers. Then use the system’s built-in ktutil utility to merge the keytab file with the client’s existing Kerberos configuration file. (Ktutil differs from system to system; see the client’s documentation for details.)

Unix Kerberos can also be used to access Windows-based resources, provided the Unix client has the capability to access those resources. For example, the ability to pass Kerberos tickets to a file server doesn’t necessarily mean you can even talk to the file server initially. Unix’s native Kerberos capabilities are only half the puzzle; I’ll talk about the other half next.

The downside to all this Kerberos stuff on Unix is that most Unix variants don’t provide a great graphical user interface (GUI) for their Kerberos bits. Instead, users are forced to contend with command-line utilities like kclient, kinit, kdestroy and so on. Of course, if your Unix users complain about having to use command-line tools, you can simply remind them that that’s why they’re diehard Unix users and offer to get them a Windows-based PC with a nice, friendly GUI.

By the way, domain authentication to NT domains just won’t happen. There aren’t any reliable NT domain clients for Unix. Fortunately, you don’t need domain authentication to access other resources and services; most Windows file and print sharing clients will allow you to provide your domain credentials when you need to access a resource. You won’t authenticate against the domain per se, but you’ll get to the resources you need. It’s pretty much the same as how Windows 9x prompts you for a username and password when you attempt to access a file server not in a domain.

File Sharing
Unix’s native file-sharing protocol is the Network File System (NFS). Windows doesn’t include a native NFS implementation; Windows’ native file-sharing protocol is Server Message Blocks (SMB). Microsoft sells an add-on, however, called Services for Unix, which adds an NFS file server to Windows servers. The combination of Kerberos and Services for Unix would seem to offer a seamless file-sharing solution for Unix clients. Sadly, the NFS protocol doesn’t actually support the use of Kerberos yet, so Services for Unix isn’t kerberized, or designed to take advantage of Kerberos.

So how can Unix clients access Windows-based shared files? Well, given that nobody is really implementing a combined file-sharing and Kerberos solution, you’ll have to accept the fact that Unix users will have to authenticate individually to each resource they access. That’s because, although they can get domain credentials via Kerberos, none of the file-sharing solutions takes advantage of Kerberos. Fortunately, most file-sharing solutions do cache user names and passwords, allowing the solution to authenticate to each resource transparently. That’s pretty much how Windows 9x works, as it can’t take advantage of Kerberos, either, or even properly belong to a Windows domain.

You have two choices for file sharing: Teach Windows how to speak NFS or teach Unix how to speak SMB. Microsoft’s Services for Unix takes the first approach, adding NFS capabilities to Windows servers.

Your second choice is to install an SMB client on your Unix clients, which will let them speak directly to an unmodified Windows file server. One popular client is jCIFS, available from www.jcifs.samba.org. Another popular client is the commercial product Sharity, available from ObjectiveDevelopment, www.obdev.at. The figure shows a typical Sharity screen. Sharity provides a full Network Neighborhood and generally Windows-like operation and is available both for Mac OS X and several Unix variants. A big advantage of Sharity is that you can configure it with a list of your network credentials. Sharity can then map sets of credentials to specific resources, allowing it to authenticate transparently on the user’s behalf and saving the user from having to look at username dialog boxes every time he or she tries to access a resource.

Sharity allows Unix to connect to Windows

Sharity allows Unix clients to connect to Windows servers and resources. (Click image to view larger version.)

Messaging and Collaboration
Unfortunately, nobody makes an Exchange client for Unix. Fortunately, Exchange provides support to clients using both POP3 and the more feature-rich IMAP4 protocols. These are enabled in Exchange by default, making it easy for POP3 or IMAP4 clients to access their e-mail. Unix users can obtain a number of e-mail clients, including the Unix version of Eudora, which can access POP3 and IMAP4 servers. That’ll get your Unix users connected to corporate e-mail, but it won’t connect them to calendaring, tasks or anything else provided by Exchange. They may be willing to access those features from Outlook Web Access (OWA), but that’s far from a perfect solution. Worse, the version of OWA included with Exchange 2000 is highly optimized for Internet Explorer 5.5 and higher—which isn’t available on Unix. It’ll work fine with other browsers, but the user experience leaves a good bit to be desired.

Document Formats
There’s no version of Microsoft Office for Unix platforms, so you’ll need to find an office suite providing file compatibility with Microsoft Office. Depending on the level of compatibility needed, you can start shopping at www.kde.org, which offers KOffice. KOffice has limited capabilities for importing Microsoft Office documents, though, and it can’t save in any Microsoft Office file types. Instead, it uses the Acrobat PDF format as its native file type, which at least guarantees that documents produced in KOffice can be viewed on practically any other operating system.

OpenOffice, www.openoffice.org, won’t cost you a cent, as it’s an open source project. OpenOffice was actually initiated by Sun Microsystems, owner of StarOffice; OpenOffice is a somewhat stripped-down version of StarOffice, as Sun pays to license some of the components included in StarOffice (meaning they can’t give StarOffice away for free anymore, as they used to). Sadly, OpenOffice doesn’t have great cross-platform file support with Microsoft Office file types. Like KOffice, OpenOffice is designed to interoperate through Acrobat PDF files, not by reading and writing other vendors’ file formats.

Speaking of StarOffice, it’s probably your best bet for a Unix/Linux office suite, as it seamlessly reads and writes Microsoft Office file formats.

Printing
Printing is where Unix offers some great interoperability options. In fact, Windows has gradually been adopting more Unix-style printing technologies, bringing the two operating systems closer together.

If you’ve standardized on network-connected printers, chances are your printers themselves (or the devices that connect them, such as HP Jetdirect) are line printer daemon (LPD) servers. Your Windows servers probably print to the printers using LPD, and there’s no reason Unix clients can’t do the same. That means your Windows servers and Unix clients will be competing for access to the printer, which may or may not make you happy.

Ideally, what you want is your Unix clients printing to your Windows servers, like your Windows clients. That allows the server to queue up all the print jobs and send them to the printer in an orderly fashion. One way to accomplish that is to run an LPD service on your Windows servers, allowing Unix clients to print to them natively. Windows includes an optional LPD service for this purpose.

To install the LPD service, open Add or Remove Programs from the Control Panel. Click on Add/Remove Windows Components, and then open “Other Network File and Print Services.” Select “Print Services for Unix” (that’s what Microsoft calls the LPD service), and click OK. Once the service is installed, any shared printer will be accessible via LPD. Use the Unix client’s print utilities (which differ from brand to brand; see your client’s documentation for details) to set up a mapping to the appropriate shared printer.