Windows to UNIX®

Converting an existing Windows-based network to
a UNIX-based or Linux-based Network
The term UNIX is a registered trademark by The Open Group, and is used within this document
for the purpose of generically describing all BSD and System V derived operating systems.

INTRODUCTION

One of the scariest notions, and one that can significantly reduce the cost of operating and maintaining a network (or, in the worst of cases, increase the cost dramatically) is to abandon the use of Microsoft® Windows(tm) network servers and switch over to a UNIX or Linux based solution.

Let's face it: Microsoft is making things more expensive for end-users. Whether it's the weekly (if not daily) security patches, or the "per seat" licensing cost, or the threat 'on the horizon' of a SUBSCRIPTION-BASED licensing scheme for everyone, or even 'no more support for older operating systems' (which would enforce the subscription-based licensing), it's certainly not the kind of situation that makes the average Information Services manager comfortable. Nor does it allow for any kind of fixed-cost analysis on network operations.

A lot of companies nowadays are looking into UNIX or Linux as the operating system of choice for their servers. Tradititionally, when 'big iron' was the rule, an operating system like UNIX was more than just a viable option, it was often the BEST option, or at least as good as the hardware vendor's "native" operating system. But when computers shrank, and networks replaced timeshare systems, Microsoft dominated the desktop world with their Windows operating system, and later added inexpensive networking options to their operating systems, beginning with 'Windows for Workgroups'. Small office networks were often created using this 'workgroup' networking concept, to provide for simple file and printer sharing among a handful of computers, and many companies began setting up these smaller networks, since they no longer relied on an expensive server to operate. Eventually these small office networks could become large enough to warrant having a file server, and it would then be a very easy choice for the network administrator or IS manager to choose a Microsoft Windows Server for their Microsoft Windows network. At one time, the price for a Microsoft Windows Server operating system was relatively low, almost like an 'introductory price'. But that does not seem to be the case any longer.

Without any real competition, Microsoft would eventually become the dominant operating system for network servers, and would basically be able to charge whatever they could get for their operating systems, even to the point of forcing people to upgrade to a 'subscription-based' licensing scheme, so that Microsoft could guarantee a future revenue stream. Fortunately, UNIX and Linux also provide quality network servers, often performing better than their Microsoft equivalent, and at a fraction of the cost of an equivalent Windows-based network server. And for UNIX and Linux, you don't need to buy expensive hardware. In fact, UNIX and Linux servers will often run equally well using less expensive hardware than a Microsoft Windows Server operating system.

Known Issues

There are a few known issues that always seem to come up whenever you are converting an existing Windows-based network to a UNIX or Linux solution. There will be existing configurations for each machine, based on the user, and each user will need to keep his configuration intact. There will be a set of valid user names that will need preservation (or re-entry). Directory systems (such as LDAP) may need reconfiguration. Company web sites that use features found in IIS may need to be re-written to use PHP or CGI. And mail systems will need to be configured so that users don't lose their ability to read e-mail.

Additionally, Samba 3 may not have all of the functionality that a Windows 2000/2003 'Primary Domain Controller' (or PDC) might be providing for the network. In such a case, it may be well worth the time to analyze exactly what it is that the Windows server is doing, and whether it justifies additional cost of operation to continue using a Windows server, or whether switching to a UNIX or Linux server and using some other solution might be the better alternative.

A good example of this is the hierarchical domain tree that a Windows 2000/2003 server can allow you to set up. For a very large corporation, this may make sense. But for a small organization, where only a single domain is likely to exist, there is no need to have that kind of capability anyway. It is only when you have a very large organization, and the need for an "Enterprise" domain, that Samba 3 would not be able to meet that particular need.

Fortunately none of the remaining issues are a MAJOR problem to solve. Each can be handled separately, as needed, so that the total solution would become a collection of a limited number of individual problems, each one relatively easy to solve on its own.

The Hardware and Operating System

It is obviously important to begin by choosing the hardware and the operating system that you want to install as your network server. It would probably be a very good idea NOT to install a new operating system on an existing operational server, but instead to use a different computer for the new server. Since the existing server is likely to be an 'older machine' anyway, purchasing a hardware upgrade might not be a bad idea. And in some cases, you may find that an equivalent machine can be purchased for significantly under $1000, maybe even under $500. Given the risk of losing data from the existing server during the upgrade process, it's probably a good idea to use a separate computer.

So you've chosen your operating system and hardware platform. In my case, I used FreeBSD version 5.2.1, primarily because I do development, and so using a 'beta' release isn't a problem for me. Most people using FreeBSD would want to use the most recent '-STABLE' release, which at the time of this writing is version 4.10 . Others may choose to use Linux, and there are a large number of vendors and 'free' providers for Linux.

Of course, the basic operating system isn't going to do you a whole lot of good. Without installing 'package' or 'port' software, you won't be able to operate it as a network server. The following is a list of software packages that you will most likely need, once you have installed UNIX or Linux on your server. These should be made available to you through the installer that comes with your operating system.

When properly configured, SAMBA, DHCP, and BIND all work together to resolve workstation names and IP addresses automatically. As machines are powered up, they are automatically assigned an IP address, and the DNS system is informed of the workstation's name so that it can automatically update its name table.

Of course, you may want additional packages/ports for your system. The ones I mention here are the most popular (and most critical) necessary to get a server running for a Windows-based network.

Domain Controllers

Samba is capable of operating as a 'domain controller' for your network, which means that you can control users and passwords from a single server, to be used throughout the entire network. Samba 3 also supports some of the features of 'Active Directory' and can work with LDAP to allow you to have a primary and backup domain controller. If your network does not already have a domain controller, you may have problems sharing files between computers, or if you are using older Windows clients (Windows 95, 98, or ME) you may only be able to share folders using a password rather than having user-based access. Having a domain controller would also give your 'workgroup based' network additional security.

It may be the cost of a 'Windows Server' operating system that has kept a small business from setting up a domain controller. And that is exactly the point. On a 'workgroup' type of network, converting to a domain-based network with a UNIX or Linux system is, from the user's perspective, about the same as converting to a domain-based network with a Windows server. The difference is in the total cost of ownership. But when properly configured, and with the right tools installed, the UNIX or Linux server can be easy enough to maintain, which would keep the total cost of ownership low enough to be affordable.

Setting up the Domain Controller

When you install Samba 3 from source, the configuration allows you to specify which options that you want to include. Two of these options are very important. The first one is LDAP support, which is on by default in Samba 3. The second is CUPS support, which may NOT be on by default. If you choose to use CUPS, it will make setting up the print server a LOT easier.

Additionally, Samba3 needs to be configured to be a WINS server, and should be configured as the 'master browser' if it will become the Primary Domain Controller (PDC). Fortunately this is well documented at the Samba web site, and in the 'man' pages for the configuration file 'smb.conf'. The 'smb.conf' options for Samba 3 are slightly different than for earlier versions of Samba so it is important to look at the documentation for the correct version.

The 'bind' service ('named' in FreeBSD) supports DNS queries inside the network. In a system where you are providing internet services, you will want to set this up to do 'forwarding' for any query that the DNS server cannot resolve. Setting the DNS server up for forwarding is relatively easy. Setting it up for internal updates is much more difficult, and requires a reasonable understanding of DNS (and patience) to accomplish successfully. Once set up, however, it is highly unlikely that it will have to be modified. And it is possible to do the configuration using a 'standard set of configuration files', and then editing them for the network you are using them on. It must correctly specify the private addresses used by the network, and the name and IP address of the DNS server must be correctly specified in the appropriate 'zone' files. The zones themselves must also be adjusted to reflect the domain name used by the network. Typically this will be 'DOMAIN.local' where 'DOMAIN' specifies the name of the domain (or the previous workgroup name). The suffix '.local' is necessary because DNS is a hierarchical system, and the domain name you choose may someday be chosen as a URL suffix (like '.com', '.org', and so forth). Rather than 'breaking' DNS by allowing 'address.DOMAIN' to break, choosing 'DOMAIN.local' prevents this, and does so in a reasonably standard fashion.

NOTE:  You should NOT use your company's web domain address as your domain name unless the name servers on the Internet resolves it to the same machine that is running the domain controller and DNS. If you are using 'example.com' as your domain, and your ISP assigns you the address 10.254.1.1, and you also have a web server at 10.254.254.1 that is supplied by a different ISP (virtual host as 'www.example.com'), using 'example.com' as your domain name CAN (and probably will) interfere with the operation of DNS, particularly if you decide to create a computer named 'www'. This would cause 'www.example.com' to resolve inside your network with a DIFFERENT 'authoritative' IP address than your ISP. Further, the root name server for 'example.com' is actually handled by the ISP that provides the web site, and NOT the domain controller (as far as the internet is concerned). This is an example of a 'broken' DNS configuration. And I have seen it done before, which is why I mention it here.

Setting up DHCP is a bit simpler, but requires an understanding of DHCP to accomplish without any significant reading. It, too, can be accomplished by using a 'standard set of files' and then modifying them for your network.

Unfamiliar Operating System?

UNIX and Linux, to many, is unfamiliar territory. But to put things in perspective, consider that Apple with their newest operating system 'OSX' has based it upon UNIX (FreeBSD in fact), and so you can see that user familiarity with UNIX is only going to increase over time. Many features found in MS-DOS had their UNIX and Linux equivalents. Sometimes it's just a matter of knowing that you use 'ls' instead of 'dir', or 'cp' instead of 'copy', and maybe set up some simple 'script files' that let Windows users (that are familiar with DOS commands) navigate around on a UNIX or Linux system without too much of a learning curve.

But if all else fails, you can always install 'X Windows' on the UNIX machine, and allow one of the users to boot up into the GUI, and the familiar-looking interface would likely appeal to a number of people that are unfamiliar with command-line interfaces. And of course there's always web-based configuration tools, so that a web browser could be used to maintain the server systems.

Additional Benefits of UNIX and Linux

Some of the additional benefits you get with a UNIX or Linux based solution can include a more user-friendly way of connecting to the internet through a DSL modem, a built-in pop3 server for e-mail, an FTP server, a telnet server, an SSH server, a better way of implementing 'Network Address Translation' routing to the internet (sometimes called 'internet connection sharing' on windows systems), WAN capability, IP Filtering, and many other features that just don't seem to work as well with Windows servers, either because you have to jump through too many 'hoops' to get what you want, or else because the 'defaults' are too inflexible or too hard to work with.

You may find, for example, that you want to implement a NAT router for a DSL connection with Windows 2000 Server, only to find out that if you don't want to choose the IP addresses that "Internet Connection Sharing" supplies you with, and you have a dynamic IP address, you won't be able to use Network Address Translation any more. You're stuck with limitations that don't exist when using FreeBSD to do the exact same thing. And if you want to set up a WAN connection with another network, FreeBSD makes this easier, too. And because you could pick a private address range for your network that's different than the Microsoft default (Internet Connection sharing forces you to use '192.168.0.1 through 192.168.0.255') it is possible for you to choose private addresses that do not conflict with any WAN setup that might exist from people dialing into a company server with dynamically assigned IP addresses, if their individual windows servers were forcing them to use the SAME IP address range. And for individual remote offices to be spared the need of a static IP address, just so they can connect to the 'home office' network, this can be an additional cost savings in setting up a WAN using UNIX or Linux servers.

On FreeBSD the setup for DSL and NAT was relatively easy. I would expect that Linux and other UNIX operating systems would have very similar configurations. In the case of FreeBSD it was a matter of enabling the 'ppp' daemon (for those familiar with Windows, a 'service' under Windows and a 'daemon' under UNIX/Linux are equivalent), putting the login information into a configuration file, and on bootup, the DSL connection is automatically made and kept alive indefinitely. And so, for the price of an additional network card, you can use your domain controller, file server, printer server, web server, and mail server as a NAT router for a DSL internet connection. And by combining all of these functions into a single box, you save money.

SECURITY

Network Security, and the possibility of intrusion on a network server, is always a major concern, particularly nowadays with the advent of internet worms and trojan horse applications, and malicious 'crackers' that would intentionally harm your files or deface your website, or host illegal material on your web server, or use your web server to hide their identity while they perform some illegal act. Windows systems have recently been plagued with security problems, and patches are being issued on a weekly basis, sometimes more often than that. It is very important that a server that exposes itself to the internet be very secure, with no known vulnerabilities, and well tested against the kinds of intrusion attempts that happen all of the time.

UNIX and Linux systems have a distinct advantage in that they are 'open source'; that is, the source files can be viewed by anyone who wants to check these operating systems for security flaws. Conversely, Windows systems must be reverse-engineered for third parties to determine whether a security problem exists, and the truth of the matter is that when such reverse engineering happens, it's not always by a security company that posts alerts and notifies Microsoft of the problem. It's often done by people who intend to exploit some flaw for other than honorable purposes. In truth, the same is true for open source operating systems, but time has tested the code base of these systems, to the point where undiscovered flaws are at an absolute minimum. Open source in and of itself minimizes the time in which this can happen. 'Closed Source' (binaries only) extends this time period, and so Microsoft is dealing with security problems a lot more frequently than UNIX and Linux providers.

With proper firewalling, and IP filtering, and correct use of built-in security features, a UNIX or Linux system 'out of the box' can easily be more secure than a Microsoft server. Obviously you could set up a UNIX or Linux system to be extremely unsecure as well. And you have to know what you are doing a lot of the time (though default settings for FreeBSD seem to be pretty secure without too much user intervention).

Setting up a process with 'chroot' and 'Jails'

Quick Start Pages

The following additional web pages were set up as 'quick start' guides. They contain shell scripts, sample configuration files, and basic instructions for getting things up and running. In short, if you were to install the software (that includes things like enabling it in 'rc.conf'), then use the sample files and follow the instructions, you could have a domain controller up and running in a minimum amount of time. And that's not normally an easy thing to do.
(NOTE: links that are not active would refer to pages that are still 'under construction')

1. DNS (aka BIND)
2. DHCP
3. CUPS
4. Samba 3
5. IPFW (firewall)
6. Sample 'System Backup' Shell Script