Introduction to Microsoft Windows Services for UNIX 3.5
Introduction
Microsoft® Windows® Services for UNIX (SFU) 3.5 allows Windows–based and UNIX–based computers to share data, security credentials, and scripts. And SFU 3.5 includes technology to provide a high performance scripting and application execution environment that enables UNIX applications and scripts to be retargeted to run natively on Windows.
Administrators are looking for solutions to integrate a heterogeneous network and share information seamlessly between their Windows and UNIX systems. Users should not face impediments when moving among networked computers running different operating systems. Businesses are looking for ways to use their investments in UNIX applications, resources, and expertise while minimizing the total cost of ownership (TCO) as they move forward.
The TCO of Windows–based computers is compelling. Microsoft Windows XP and Microsoft Windows Server™ 2003 have added new features and have improved security, reliability, availability, and scalability. CPU performance continues to advance at exponential rates, as does the price–performance of the PC as a standardized, high-volume server and workstation platform. Businesses have integrated Windows–based computers into their traditionally UNIX–based enterprise networks, and Windows–based systems are being used in concert with and as a replacement for UNIX–based computers.
Businesses have significant investments in both UNIX–based and Windows–based applications, databases, and business processes, so there is a need for comprehensive integration between these two environments. Staff skilled in one environment need to be able to translate experience and knowledge to the other so that they can work constructively there. SFU delivers the protocol support, interoperability tools, execution environment, and administrative framework to make doing so as simple as possible.
Services for UNIX Objectives
SFU’s primary objective is to provide interoperability tools that bridge the gap between UNIX and Windows for users, administrators, and developers. As a result, enterprise networks can be created in which resources can be shared seamlessly. Access to resources is determined by enterprise policies and must accommodate the sharing of credentials, authorization, and authentication information from either the Windows or UNIX domain.
The design goals that shape SFU are:
| • | Seamless sharing of data between Windows and UNIX network protocols. |
| • | Remote command-line access to both Windows–based computers and UNIX–based computers using existing UNIX practices and protocols. |
| • | Heterogeneous network administration, including common directory management and user password synchronization. |
| • | Full UNIX scripting support on Windows, including shells, utilities, hard and soft (symbolic) links, and a single rooted file system |
| • | High performance application development and execution environment to permit easy retargeting of key business applications. |
| • | A single, integrated installation process. |
| • | Simplicity of administration and management for all SFU components. |
This paper describes SFU’s features and benefits in typical deployment scenarios.
Interoperability Requirements
SFU easily and seamlessly integrates networks that have both UNIX–based and Windows–based computers. This section describes the issues faced in the environment, and the next section explains how SFU’s features address those issues.
Resource Sharing
In a seamless logical network, users share resources regardless of location. Access to resources is controlled by corporate policies and is independent of implementation technology. Users can access applications and databases residing anywhere in a network.
Differences in Windows and UNIX Environments
Authentication mechanisms, file access protocols, user interface standards, conventions, and procedures are inherently different in UNIX and Windows. Yet the underlying network protocols and the tasks at hand are identical. SFU provides protocol support and utilities to manage these differences.
Multiple Authentications and Separate Identities
UNIX–based and Windows–based operating systems use different directories and access control mechanisms. Because the two systems use different authentication mechanisms, users have separate user identities for each system, even when their user names appear identical. These different identities and their separate passwords are a problem for both users and administrators. In a logical enterprise network, users have a single sign-on mechanism to access resources transparently on both systems. .Access to resources on UNIX from a Windows–based computer, or vice versa, requires separate authentication. Consequently, the network is split into disjointed Windows–based and UNIX–based domains, creating an artificial barrier that divides a single enterprise network.
Differences in Environments
Many applications that were previously available only on UNIX–based computers are now available on Windows computers, while existing UNIX applications are being ported to Windows. Similarly, new high-end workstation applications are being developed on Windows.
With many UNIX developers now working on applications for Windows–based computers, they expect a UNIX-like environment to ease the transition. UNIX users expect the shell and tools, such as grep, find, ps, tar, and make, to support the more complex scripting requirements they’ve come to depend on. The availability of a familiar environment on Windows is needed to reduce the cost of learning different tool sets. The availability of UNIX-like tools also helps increase the efficiency of UNIX programmers when they switch to Windows software development.
Common Administration
The system administration tools and mechanisms on Windows and UNIX are significantly different. UNIX system administrators typically use command-line tools and shell scripts, while Windows system administrators rely primarily on graphical tools supplemented by command-line scripts using the Windows Scripting Host (WSH). Without a common language or toolset, administration and management of heterogeneous enterprise networks is a challenge.
Familiar Management Tools
For administrators, managing two different networks entails a significant workload in both acquiring and maintaining the requisite skills, adding significantly to overall IT costs. Administrators of a heterogeneous network need similar mechanisms and tools to administer both Windows–based and UNIX–based computers. Such tools should allow remote administration as well as automation of repetitive administration tasks.
Differences in Directory Services
In addition to the differences in administration mechanisms, UNIX and Windows operating systems use different directories to store users, groups, and other network objects. Managing them separately and keeping them synchronized is a time-consuming burden.
Adding, changing, or deleting network resources such as users and devices requires changes to two separate directories using two separate processes. This duplication of effort increases costs and reduces efficiency while greatly increasing the risk of inconsistencies.
Needs of Windows–based Network Administrators
Windows–based network administrators increasingly use scripting and command-line tools to simplify routine system management tasks. GUI-based tools are useful for novice users to help discover and increase their productivity quickly. However, command-line tools and scripts are required for automating repetitive tasks and ensuring consistent results. Scripting is a useful mechanism for experienced users seeking increased productivity through reuse and automation.
Features of Services for UNIX
SFU provides a single, comprehensive package to meet the interoperability requirements described above. SFU implements the following features:
| • | File sharing between UNIX and Windows using NFS. SFU provides:
|
||||||||||
| • | Remote command-line access between Windows and UNIX. SFU provides:
|
||||||||||
| • | Comprehensive cross-platform scripting abilities. SFU provides a consistent implementation of:
|
||||||||||
| • | Common network administration by providing NIS server functionality using the Windows Active Directory® service. |
||||||||||
| • | Password synchronization between Windows and UNIX. Includes precompiled binaries for Solaris 7 and 8, HP-UX 11i, Redhat Linux 8.0, and IBM AIX 5L 5.2, and source code to support compilation on other platforms. |
||||||||||
| • | Installation using Microsoft Windows Installer. |
||||||||||
| • | Administration of SFU components and services using Microsoft Management Console (MMC) or a fully scriptable command line |
||||||||||
| • | Management of SFU components using Windows Management Instrumentation (WMI). |
||||||||||
| • | Installation on computers running Windows 2000, Windows XP Professional, and Windows Server 2003.1 |
||||||||||
| • | Compatibility with a variety of UNIX–based computers, but specifically tested against Solaris 7 and 8, HP-UX 11i, Redhat Linux 8.0, and IBM AIX 5L 5.2. |
File Sharing Between UNIX and Windows Using NFS
SFU supports the NFS file sharing protocol, versions 2 and 3, and provides three separate NFS components: Server for NFS, Client for NFS, and Gateway for NFS. In addition, the User Name Mapping service allows access control based on existing Windows and UNIX identities.
Server for NFS
Server for NFS is a Windows–based NFS server sharing files using NFS exports. Server for NFS allows NFS clients to access files on Windows–based computers. For the UNIX–based NFS client, this process is completely transparent and requires no additional software to be installed on the UNIX client. File access is regulated by user and group identities (UID and GID). Server for NFS supports NFS exports from CDFS, and NTFS file systems only. FAT and FAT32 are not supported.
| • | NFS versions 2 and 3 support. Server for NFS allows UNIX and other NFS clients to access files stored on Windows file servers and provides complete support for NFS version 2 and 3. It supports NFS file locking specified by the Network Lock Manager (NLM) protocol. |
| • | Simple sharing. Server for NFS provides an easy way to share directories and set NFS access permissions on Windows–based computers. The NFS Sharing tab is a GUI interface accessible from the directory context menu (by right clicking the directory in Windows Explorer.) The command-line utility, nfsshare, allows scripted share management from either Windows or UNIX shells. NFS access permissions can be set to read, read/write, and to control root access to individual computers or groups of computers. |
| • | Access control and authentication. Server for NFS integrates UNIX and Windows access control mechanisms in a natural manner. The credentials and permissions of both local users and domain users are honored. UNIX UIDs and GIDs presented using the NFS protocol are mapped to a corresponding Windows security principal (user or group identity), known as a SID, by the SFU User Name Mapping service. File access is managed by using a mapped user’s context. Server for NFS Authentication provides authentication of NFS requests. This process ensures that a user’s file access is consistent with the UID/GID settings of the UNIX computer and prevents circumvention of the Windows security settings. |
| • | Simple administration. Server for NFS provides both graphical and command-line administration tools with options for configuring server settings and for logging all NFS activities. It also enables monitoring and reclaiming of NFS locks. |
Client for NFS
Client for NFS enables Windows computers to access files and directories that are exported from NFS file servers and requires no additional software on UNIX hosts. Client for NFS supports NFS versions 2 and 3 and has the following features:
| • | Simple access mechanism. For a user, accessing an NFS export is the same as accessing a Windows share. Users browse NFS servers in the NFS network by using Windows Explorer and can access NFS exports by either mapping them to a drive letter or using Universal Naming Convention (UNC) names. NFS exports can also be accessed by using the net or mount commands. (Windows implementations of the showmount and umount commands are also provided.) |
| • | Authentication. Authentication of NFS requests uses the User Name Mapping service that provides single sign-on for Windows users accessing NFS exports and takes advantate of the Windows authentication process to access NFS resources. NFS requests are sent using the UID or GID of a mapped user, and thus a Windows user operates in the context of the mapped UNIX user when accessing NFS resources. Users with accounts on both UNIX and Windows receive the same privileges whether accessing files from a UNIX NFS client or from a Windows NFS client. |
| • | Performance tuning. Administrators can tune the performance characteristics of an NFS mount by using the administration tools of Client for NFS. They can set or change the read/write buffer size and select soft or hard mount. In addition, the Autotune tool helps detect optimum read/write buffer sizes for connecting to a particular NFS share. |
Gateway for NFS
Gateway for NFS provides access to NFS exports without requiring additional software on downstream Windows clients. It does so by acting as a gateway between the Windows network and the UNIX (NFS) network.
Gateway for NFS mounts NFS exports and then exposes them as Windows shares. Windows computers on the network access the NFS exports indirectly by using standard windows file sharing protocols, and they see the NFS exports as shared Windows drives on the Gateway Server.
Gateway for NFS also uses the User Name Mapping service to map Windows credentials to UNIX UIDs or GIDs before forwarding file access requests to NFS servers. Each gateway request from a separate user is properly identified, and Windows user names are mapped to corresponding UNIX users before being forwarded to the NFS server. This process ensures that clients accessing NFS servers either directly from machines with Client for NFS or indirectly through Gateway for NFS get the same privileges that they would get from UNIX NFS clients. Because access to Gateway for NFS shares is provided by Windows–based networking, these requests are authenticated using Windows credentials, and then mapped to the corresponding UNIX UID/GID pair through User Name Mapping.
User Name Mapping
The User Name Mapping service is an SFU component providing bidirectional, one-to-one, and many-to-one mapping among UNIX UIDs/GIDs and Windows user and group identities (SID).
Note: The many-to-one mapping allows many UNIX identities to map to a single Windows identity, but not the reverse.
User Name Mapping administration, performed through the graphical user interface or a command-line tool, mapadmin, associates user names or identifications between the Windows–based and UNIX–based domains. All the NFS components of SFU utilize the User Name Mapping service. The User Name Mapping service can be installed on any machine that has SFU installed. User Name Mapping equates an authenticated Windows user’s identity, or SID, to a UID/GID pair. Client for NFS and Gateway for NFS use User Name Mapping to control a Windows user’s access to NFS resources, while Server for NFS uses the mappings when processing NFS requests originating from UNIX–based computers. Such requests contain UNIX UID/GIDs.2 (It is the Windows NT Security subsystem that actually performs the authorization checks.)
User Name Mapping can be deployed as a service on any server connected to the network, simplifying administration and deployment. All SFU NFS components that use the central User Name Mapping service receive consistent access to NFS resources from anywhere on a network. User Name Mapping also provides the following features:
| • | Support for NIS or PCNFS. User Name Mapping retrieves UNIX user names from an NIS domain or reads them from PCNFS-style passwd and group files. With support for NIS, User Name Mapping can be used with very little disruption to the rest of the NIS infrastructure. For Windows users, it obtains user names from the Windows Domain Controllers. It also periodically refreshes user names from both UNIX and Windows domains. |
| • | Support for simple and advanced mappings. By default, User Name Mapping equates Windows domain users and UNIX users with the same names. Additionally, administrators can map users with different Windows and UNIX names (or multiple Windows user names to the same UNIX user name) using advanced mappings. |
| • | Squashing support. User name mapping supports the ability to squash a Windows or UNIX user’s identity—that is, to map all or selected users to an unmapped user context. (Unmapped users are assigned a UID/GID pair of “nobody” which is –2/–2 by default. Squashing and the squash to UID/GID value can be specified on a per mount basis.) This feature is useful to override automatically mapped users (due to simple mappings) or those users who should be explicitly squashed. This behavior results in a squashed user being explicitly treated as an anonymous user. |
| • | Group mapping. User Name Mapping also maps groups (GID to SID and vice versa) between Windows and UNIX. Thus, group membership and access rights are preserved. |
Remote Access Using Telnet
SFU includes both a Windows–based and Interix–based Telnet server and client. Telnet is a TCP/IP-based protocol that allows platform independent remote terminal access through a network or dialup connection.
The SFU Windows Telnet client and server are installed on Windows 2000 machines as part of SFU, but are not installed on Windows XP and Windows Server 2003, because they are essentially the same. However, SFU can administer the included Telnet server. In addition to ANSI, VT100, and VT52 terminal support, the Windows Telnet client and server also support the VTNT terminal type to provide access to all functions of the Windows command console.
Windows NT LAN Manager (NTLM) authentication is supported to allow logon without sending a password over the network. Traditional plain-text logons are also supported. Telnet server supports both console mode and stream mode, and console mode supports screen-oriented programs such as vi. Stream mode operates similar to a UNIX dumb terminal type but is not suitable for use with programs such as vi.
Telnet server logs a variety of telnet-related activities, such as auditing, monitoring Telnet sessions, and sending messages to Telnet connections. Telnet server enables a user to keep applications running even after disconnecting.
Interix includes a Telnet daemon (server), telnetd, that can be enabled instead of the Windows–based Telnet server. The Interix Telnet server is more UNIX-like in its behavior and administration. The Interix telnetd is started by inetd and establishes a remote session under the Interix subsystem. More details can be found in the appropriate man pages.
Common Network Administration Using Server for NIS
SFU includes Server for NIS, based on Active Directory. Server for NIS is installed on a Windows 2000 Server or Windows Server 2003 domain controller and can be used as a master NIS server to administer a UNIX NIS domain by using the NIS 2.0 protocol. It supports both UNIX–based NIS subordinate (slave) servers as well UNIX–based NIS clients.
Server for NIS stores NIS objects in Active Directory, which integrates UNIX users, groups, and hosts into their Windows–based equivalents. Thus, UNIX users and groups are administered in an identical manner to Windows users and groups. NIS data can be managed by using Active Directory tools such as the Users and Computers snap-in. Further, any users common to both UNIX and Windows networks can be represented uniquely in Active Directory. Doing so creates a common namespace, reducing the administrative overhead involved in managing two separate namespaces and directories. Using Server for NIS has the following benefits:
| • | Use of Active Directory to store NIS data. Active Directory has the advantages of a secure data store, multi-master data replication, and schematized data storage and access. Through Active Directory, NIS data may be accessed by using the COM-enabled Active Directory Services Interface (ADSI) and LDAP protocols, in addition to NIS tools, such as ypcat, ypget, and others. |
| • | Migration of NIS domains to Server for NIS. Server for NIS includes the NIS Migration Wizard, a tool to migrate NIS domains or maps. In addition to simple domain migrations, multiple domains can be merged into existing NIS domains. This tool simplifies the migration of existing UNIX NIS domains to Active Directory domains. |
| • | Supports yppasswd and user password synchronization. Server for NIS keeps Windows and UNIX passwords synchronized. Whenever a user’s Windows password is changed, the corresponding UNIX password is also changed. At the same time, it supports yppasswd, which enables UNIX users to change their passwords from UNIX client computers. However, if a password change is initiated from a UNIX NIS client, the Windows password is not changed unless Password Synchronization (see the next section) is also installed on the UNIX system. |
Password Synchronization
SFU includes bidirectional Windows-to-UNIX and UNIX-to-Windows password synchronization that supports both local and domain account Windows password synchronization. Domain account synchronization requires that Password Synchronization be installed on Windows 2000 or Windows Server 2003 domain controllers.
Password change requests are sent to only those computers that administrators select. For UNIX-to-Windows synchronization, the ssod.conf file controls the password synchronization behavior. Configuration of the Windows-to-UNIX synchronization uses the SFU Administration snap-in.
Password change requests can be restricted to specific users. Administrators can stipulate users for whom passwords should be synchronized and others whose passwords should not be synchronized. The password change requests from Windows to UNIX and UNIX to Windows are encrypted by using strong encryption. Password Synchronization uses the Triple-DES algorithm. The source code for the UNIX components, PAM and SSOD, is included with SFU.
UNIX Utilities and Shells
SFU 3.5 includes Interix, a complete POSIX development environment tightly integrated with the Windows kernel. Both Korn and C shells are included, and the Bash shell is available as a free download. With more than 350 UNIX utilities and a single rooted file system, SFU provides a familiar environment for UNIX developers, users, and administrators.
The Interix SDK includes more than 2,000 APIs that are consistent with the ISO 9945-1 ANSI IEE 1003.1 POSIX specification. As a result, existing business applications and scripts can be retargeted without a performance penalty.
Support of Microsoft Technologies
SFU is well integrated with Windows and utilizes many underlying Microsoft technologies. Supported technologies include:
| • | Microsoft Windows Installer. Provides a consistent installation across a wide variety of Microsoft products and supports custom installation scripting, adding and removing features and repair of an existing installation. |
| • | Microsoft Management Console (MMC). Provides a consistent and feature-rich management console that supports remote management and customization. |
| • | Windows Management Instrumentation (WMI). Provides programmatic and scripting access to automate data gathering and system configuration. |
| • | Windows Explorer interface. Provides a consistent look and feel for NFS client and server operations, enabling users to use and share NFS resources transparently. |
Summary
SFU 3.5 provides a comprehensive set of tools to bridge the gap between UNIX and Windows computers for both users and administrators. With SFU, a consistent, logical enterprise network can be created in which resources are shared seamlessly and access control is determined by enterprise policies instead of the platform.
SFU includes many benefits, such as the following:
| • | Seamless sharing of data between servers and clients running either a UNIX or Windows operating system. |
| • | Remote command-line access to both UNIX or Windows computers from either Windows or UNIX computers. |
| • | Scripting and application development. The Interix subsystem technology provides familiar UNIX shells and utilities, along with a full set of UNIX APIs. |
| • | Heterogeneous network administration, including password synchronization. |
| • | Simple, integrated installation. |
| • | Easy-to-use, single-point administration and management of SFU components. |