Getting Unix/Linux and Windows servers to coexist in the same network environment is a little like interpreting...
for emissaries from two foreign countries. Neither one speaks the same language; each wants to do everything its own way. And yet with work and patience, it's possible to get them to sit in the same room at the same time and agree on something.
In this article, I will run through a number of common methods that people use to get Unix/Linux and Windows servers to work together, and I will identify many of the common issues that come up (and possible solutions for those issues).
SMB / Samba and its related protocols
SMB is the network protocol that Windows uses to share system resources like files and printers. Anyone who's tried to get Windows and non-Windows machines talking to each other to share files over a network knows about SMB -- and probably not in a good way. Even in a wholly Windows-centric network environment, SMB can be ornery; getting a Unix or Linux server to speak to a Windows file share can be just as annoying.
On the plus side, the tools to get Unix/Linux systems to speak SMB have been around for over a decade now and are well supported and understood. Samba, a free implementation of not only SMB but many other proprietary Microsoft network protocols (including Active Directory Logon), is the de facto tool in this regard. With Samba, SMB network shares can be mounted directly as directories in the local file system or accessed with the smbclient tool via an FTP server. (It's probably more convenient to just mount the shares as directories whenever possible.)
Some of the common problems that come up with Samba are trying to talk to an antiquated Windows 9x client that uses NetBEUI (which is not supported by Samba; get rid of it) and upgrading an older (pre-2.0) version of Samba to a newer version without being mindful of how some of the default behaviors might have changed.
Another common problem people run into with Samba is when they try to browse the Windows network and can't see anything at all. This is generally an artifact of an existing problem with Windows peer-to-peer networking -- the lack of a designated master browser on the network, a master browser being a machine that tabulates what other machines on the network are doing. This can be fixed by editing Samba's configuration files and changing the local master, os level and preferred master settings, consequently forcing the Samba server to act as the master browser. (You can also edit the Windows registry, if you'd rather do it that way.)
I ought to mention there's a code fork of Samba called Samba TNG, which has been reorganized to consolidate many NT-domain networking functions into a common code base. This is more useful for programmers and developers, although it's functionally similar for the rest of us.
Active Directory and Exchange
Historically, it hasn't been possible to have Unix clients authenticate against Active Directory. The newest version of Samba allows this, because it supports Kerberos authentication. It's even possible to map Windows SIDs to UNIX UIDs and GIDs, although this only works with a single Active Directory domain and doesn't work across domain trusts (yet).
Exchange relies extensively on Active Directory for its own capabilities, which has led people to wonder if it is possible to have a Unix client of some kind interoperate with Exchange using the above tools. The short answer is "sort of," depending on what approach you take.
- You can use the Ximian Connector to plug the Ximian Evolution (now Novell Evolution) suite into Exchange. Many of Exchange's groupware functions, such as calendaring, will work this way, but this requires that you're using Evolution in the first place.
- You can run conventional Unix mail tools and talk to Exchange by using vanilla SMTP and POP3 protocols. You'll be able to send and receive mail, but you won't be able to take advantage of any of Exchange's groupware functions.
- You can use Outlook Web Access for Exchange, which works with many Web browsers to provide a Web-based mail interface that behaves almost exactly like Outlook.
- Finally, you can run Microsoft Outlook itself (if you have it), either through an emulation layer like WINE or in a virtual machine). Obviously this only works if you have a licensed copy of Outlook.
NFS is a file-sharing protocol that's broadly supported in Unix but not as broadly available in Windows. Windows may have a command-line ftp client included by default (even if it isn't very good), but Windows includes no tools to mount or read NFS fileshares. To do that, you'll need to do one of two things:
- Use Microsoft's own Windows Services for Unix package, which includes NFS tools and is now in revision 35. and includes tools to allow Windows servers to function as NFS clients, servers or gateways. (One big drawback to the SFU package is that it only runs on Windows Server or Windows XP Professional, although a published hack allegedly allows it to be installed in Windows XP Home.)
- Use a third-party NFS package. The freeware Allegro NFS Server is one such product, but runs only as a server and not as a client, which is useful if you want to allow Unix clients access to Windows machines through NFS but not vice versa.