In-Depth
Mission Interoperate: Windows 2000 and Unix
Administering two platforms is tough. Microsoft Services for Unix 2.0 provides a practical set of tools for making sure Windows and Unix users get along—and that your job gets easier.
- By Greg Neilson
- 05/01/2001
The rapid growth of Linux translates to a major
resurgence in Unix usage. This means more of us
are in the position of having to integrate Unix
systems with Windows NT/2000 systems. Microsoft
Services for Unix 2.0 (which I’ll abbreviate as
SFU here) is a collection of tools we can use
to connect these two platforms in a myriad of
ways. Like a smorgasbord, there’s plenty here
to pick and choose from to get what you need.
SFU originally surfaced from Microsoft in 1999.
Version 2.0, released last year, costs a modest
$149, which I consider an absolute bargain. With
SFU 2.0 you can share files between Unix and Windows
environments, access telnet on your Windows servers,
run Perl and Korn shell scripts on Windows, and
perform two-way password synchronization between
Windows domain and Unix hosts.
How can you make use of this product? Here are
a few scenarios:
- You could install the NFS Gateway feature
on a Windows server that connects to NFS shares
from Unix hosts and then reshare them again
for Windows clients. Thus, the clients wouldn’t
need to have NFS client software installed.
- You could install the NFS server feature
on your Windows file servers and then be able
to share files with Unix hosts.
- You could install the Telnet Server feature
on your Windows servers to allow users to establish
text sessions remotely on your server.
- You could install the Server for NIS feature
to move your NIS user information into the Windows
2000 Active Directory database and then be able
to manage these users using the AD Users and
Computers snap-in.
- You could install Perl and the Korn shell
features on your local workstation to be able
to leverage your extensive Unix scripting skills
on the Windows platform.
More on each of these shortly.
Although there’s a lot here that’s supported,
one area isn’t. You won’t be able to work with
X Windows, the windowing system developed for
Unix. Such support would have been useful. The
Microsoft marketing material is inconsistent about
the purpose of the product, but when the company
starts talking about this product as “protecting
your investment” in Unix technologies, the unwritten
rule is that it’s intended more as a migration
tool (from Unix variants to Windows, of course!),
and not just as an interoperability toolkit. This
helps to explain the lack of X support. This means,
of course, that you can’t establish a local graphical
terminal session from a Unix host.
Several features new to this version will be
of interest to anyone involved in integrating
the two environments, particularly the gateway
for NFS, the PCNFS server, NIS Server, user name
mapping and a number of Unix command-line utilities.
SFU can be administered by a Microsoft Management
Console (MMC) snap-in, as seen in Figure 1, or
via command-line utilities. Surprisingly, the
MMC only manages a small subset of functionality.
That’s a limitation. So, more often than not,
you’ll need to use the command-line utilities
to work with the component parts of the product.
|
Figure 1. Administration
of Microsoft Services for Unix 2.0 via Microsoft
Management Console. (Click image for larger
version.) |
In this article I’ll cover what’s possible in
integrating the Windows and Unix environments
using the features of SFU and give some insights
about how these features work. I’m assuming you
already know Windows NT, that you’re working on
learning Win2K, and that you possess a smattering
of knowledge about Unix networking concepts. We’ll
cover the details about the Unix side as we go.
Installation
You can install SFU on workstations and servers
running either NT 4.0 with Service Pack 4 or greater
or Win2K. It also requires Internet Explorer 4.01
or later. The installation program uses a Microsoft
Installer file which means —in a Win2K environment—you
could potentially install it using Group Policy.
Keep in mind one limitation when installing on
an NT platform: You must install it first via
Windows rather than the command line.
Installation is straightforward. After launching
sfusetup.msi, select the installation directory
and the features to install. Once you’ve done
that, the chosen features are installed on the
local NT or Win2K workstation or server. Only
when using the password synchronization feature
(described later) do you need to install anything
on the Unix hosts.
If you install the NIS Server component of the
product (described in the next section), the NIS
database will be integrated into the AD database.
In order to extend the AD schema, you need to
use an account that’s a member of the Schema Admins
group.
You can selectively install product services
from the set-up GUI or by selecting the appropriate
keyword from the command line. One limitation
is that you can’t install both the NFS gateway
and NFS client on the same machine. This isn’t
likely to be a huge problem since the NFS client
is a subset of the features of the NFS gateway.
More on this shortly. Also, NIS can only be installed
on Win2K domain controllers and the NFS gateway
on a server, not a workstation.
Server for NIS
Network Information Service (NIS), also known
as yellow pages, is a technology from Sun Microsystems
sometimes used by Unix machines to share directory
information, such as users and groups. This is
similar to the way that a single accounts database
in NT 4.0 is shared within a domain. The Server
for NIS feature allows the NIS database to be
stored within the AD database on a Win2K domain
controller. A wizard is available to migrate existing
NIS domains to Win2K.
Once the NIS user information is stored within
AD, you use the regular Active Directory Users
and Computers snap-in to manage your user accounts.
A new property page called Unix Attributes for
each user appears and is shown in Figure 2. Here
you have the option to configure the user’s NIS
domain; his or her numeric user ID; home directory;
and, optionally, primary group name or ID.
|
Figure 2.
Managing Unix user details in Active Directory. |
Authentication
It’s one thing to be able to connect Windows with
your Unix environment, but doing this securely
is another matter. With SFU we have two options
for authenticating Windows and Unix users on a
Windows network: user name mapping and Server
for PCNFS.
With user name mapping, you match up the user
and group names between the two platforms. This
can be a simple map that matches a Windows domain
with an NIS domain. For the simple map to work,
the user or group names need to be identical,
that is, a “gneilson” account name in Windows
that maps directly to a “gneilson” account in
NIS.
An advanced map is an explicit list of accounts
from each environment mapped together. In this
case you can list each user and its equivalent
in the other environment or you can map many or
all users against one account. For example, you
could create a special user in NIS called WindowsUsers
and map all users from the Windows domain to this
account. Then—on the Unix side—you could set permissions
for this type of user, which then effectively
grants all Windows users these rights.
SFU makes use of user name mapping in both ways—to
map incoming requests from Unix hosts against
Windows domain users. Also, when a Windows user
attempts to access a Unix resource, SFU automatically
supplies the user and group information to that
Unix machine.
You can configure user name mapping using the
MMC snap-in or the MAPADMIN command.
The Server for PCNFS feature works for DOS. Mac
and Windows client machines that can’t make use
of user name mapping that are able to query a
PCNFSD server. It provides the Unix user and group
ID information for these clients when they’re
accessing drives on a Unix host using NFS.
Using the MMC snap-in, you define the various
Unix groups and users, including the user password.
When a user sends the account name and password
to the Server for PCNFS service, it returns the
numeric user ID and group ID that can be used
to connect to a Unix server. (See Figure 3 for
an explanation of the process.)
|
Figure 3. When a user
sends the account name and password to the
Server for PCNFS service (step 1), it locates
(step 2) and returns (step 3) the numeric
user ID and group ID that can be used to connect
to a Unix server. The client feeds that information
to the Unix server (step 4), which allows the client to mount the requested resource (step 5). |
SFU also offers a two-way password synchronization
feature. This propagates password changes between
accounts on your Windows domain and the accounts
on a number of configured Unix hosts and vice
versa. SFU comes with daemons to install on Solaris,
Red Hat Linux, HP-UX or Tru64 Unix to facilitate
the password changes on the Unix side. This password
synchronization SFU feature then needs to be installed
on each DC within the domain. The MMC snap-in
allows you to specify the Unix hosts to contact
to exchange password information, what TCP/IP
port to use and also debugging options such as
retries and whether to enable detailed logging.
File Sharing
The essence of Unix file sharing is the NFS (Network
File Share) protocol. SFU offers a range of options
here: an NFS server, NFS client and NFS gateway.
The NFS server option makes available shared directories
from Windows to Unix hosts. The NFS client allows
a Windows machine to attach to a shared directory
from a Unix host. The NFS gateway allows you to
connect to a shared directory from a Unix host
and then reshare that directory to Windows clients.
These installed NFS components can be stopped
or started through the SFU MMC snap-in. Select
the component, right click, and select to either
start or stop it. Also, the NFSADMIN command-line
utility can be used to start or stop each of these
components. All of these are standard Windows
services and can be managed via the Services applet
or the NET START and NET STOP commands.
The NFS client makes it possible to use Windows
Explorer to mount an NFS share on your local machine.
You can specify the machine you wish to connect
to or browse the NFS Network folder under the
Entire Network in Network Neighborhood/My Network
Places to find NFS resources. From the command
line, use the MOUNT command to mount an NFS drive
to your local machine. Once you make an NFS mount,
you can use the SHOWMOUNT –D command to view the
list of NFS mounts on the machine. You can query
an NFS server with the SHOWMOUNT –E
command to view what directories have been exported
and available to be mounted by an NFS client.
Figure 4 shows the My Network Places GUI in action.
The UNMOUNT command is used to unmount NFS network
drives.
|
Figure 4. You can use
My Network Places to view NFS exported directories
on the network. |
After installing the NFS Server, you can share
directories either via the Windows GUI or the
command line. When you select a directory in Windows
Explorer, right click and choose the Sharing option.
A new properties page for NFS Sharing allows you
to share that directory and optionally set permissions.
NFSSHARE works on the command line in the same
way that the regular NET SHARE command works.
You can use it without parameters to view the
exported NFS directories or to export a given
directory. For example:
NFSSHARE shared=f:\shared
SHOWMOUNT -A
SHOWMOUNT –A shows what clients have mounted
NFS drives from this machine. The NFS Gateway
performs a similar function as NT’s Gateway Services
for NetWare. It allows a machine to make an NFS
mount of an exported directory and share it again
on the network to clients using Windows networking.
Therefore, the clients don’t need any NFS software
on their machines.
You can set up a redirected NFS share via Windows
Explorer or by using the GWSHARE command. GWSHARE
without parameters lists all NFS shares.
Admin Tools
SFU includes a telnet server and telnet client.
The telnet protocol lets you run a text mode remote
terminal session on the server from your client
machine. It’s like opening a CMD window at the
server without actually having to be at the server.
Win2K Server comes with a telnet server that
allows a maximum of two clients at a time. The
version included with SFU allows as many client
connections as there are server client-access
licenses. In keeping with the licensing limitations
of NT 4.0 Workstation and Win2K Professional,
you can have a maximum of 10 connections.
Although the telnet feature in SFU is the same
as in Win2K, it’s worth noting that NTLM security
can be used between the Win2K telnet server and
Win2K telnet client. This is an improvement over
the regular telnet protocols that use plain text
to pass account and password information across
the network.
You can use either the MMC snap-in or the TNADMIN
command to set the configuration of the telnet
server.
Also nice is that SFU includes Active State Perl
5.6. Although you can download this for free from
the ActiveState Web site, it’s convenient to have
on CD already. Perl has rapidly become a main
scripting language on Unix platforms, and ActiveState
allows Perl scripts to be run on a Windows machine.
Although there’s a learning curve for Perl, it’s
extremely powerful and contains much more functionality
than would be available from either regular batch
file programming or the more recent Windows Script
Host technology. For example, the text-matching
features in Perl are remarkable. In addition,
modules in Perl can work with NT event logs or
installed NT services.
SFU also includes a demo version of MKS Software’s
MKS Toolkit (www.mks.com),
which provides a Korn Shell command processor
for Windows. This theoretically allows shell scripts
written for a Korn shell on a Unix platform to
be run “as is” on a Windows machine. For example,
a recent client’s Oracle DBAs were Unix folk running
NT as their server platform. They used the MKS
Toolkit to ensure that their Korn scripts could
run now on NT and later (as they hoped) on a Unix
server without alteration.
Last, the product includes a group of around
80 Unix-like command-line tools. While many have
Windows equivalents, others don’t. A couple of
tools I rely on are the “which” command and the
vi editor.
The which command searches through the PATH environment
variable to find the location of the executable
that would be run if the command were executed.
For example, if I issued the command:
which which
the software would search through each directory
listed in the PATH environment variable and return
the first instance of which.exe found:
c:\sfu\which.exe
Without trying to start a religious war about
text editors, I consider the vi editor quite potent.
Just knowing a few commands could cause you to
leave Notepad forever. These command-line tools
are useful when added to the power of being able
to run a telnet session on a Windows server. For
example, in preparing for this article I needed
to edit the HOSTS file on my Win2K server from
my Linux machine. (Due to reasons that still hurt
too much to mention, I only have one working monitor
at home at the moment.) I was able to telnet from
Linux to the Win2K server, then launch vi to edit
the HOSTS file. Then, while still in my telnet
session, I could ping my Linux server by name
to check that the update was successful.
Additional
Information |
To learn more about
Microsoft Services for Unix, check
out www.microsoft.com/windows2000/sfu/default.asp.
A number of white papers here
can help you plan your interoperability
between Windows NT/2000 and your
Unix environment. |
|
|
Let’s Get Along
In this article, I’ve covered the main features
of SFU and discussed their implementation. If
you need to integrate Windows and Unix networks,
I think you’ll find plenty here of value. And
that’s the whole advantage of considering a product
like SFU. Although other tools offer NFS services,
I know of no other product with such a grab bag
of features. Even better, the price is right.