In-Depth
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.
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 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.
Terminal Services
Microsoft doesn’t make an official Remote Desktop Protocal (RDP) client
for Unix, but that doesn’t mean you can’t get one. Probably the most popular
one is rdesktop, www.rdesktop.org,
which is free and works great with Terminal Services. It runs on a variety
of Unix platforms.
Keep in mind that there’s always VNC, a free and decent alternative to
Terminal Services, at least for administrative purposes. VNC servers and
clients are available from www.uk.research.att.com/vnc
and many other Web sites. VNC won’t work for users who need to access
a Windows terminal server, though, so it’s not a complete replacement
for Terminal Services.
Your best bet is to consider investing in Citrix’s MetaFrame XP product,
www.citrix.com. MetaFrame adds Citrix’s
cross-platform ICA protocol on top of Terminal Services, and Citrix provides
ICA clients for just about every major Unix variant. Terminal Services
can be a great way to provide non-Windows users with access to Windows-specific
applications, such as Outlook or other line of business applications.
Unfortunately, Terminal Services requires a significant investment in
server hardware, so you’ll need to weigh the costs vs. the benefits.