Microsoft Windows Services for Unix

In a heterogeneous network environment with Windows and Unix (or Linux) machines, there can often arise a need for cross platform data/service access. For instance, if a Windows client wants to access a Unix server, then a package like Samba can be set up on the Unix server. A similar need may arise for giving Unix users access to Windows

machines. This is where Windows Services for Unix (SFU) comes in, which acts as a gateway between Unix and Windows machines. It works on Windows–NT Server and Workstation, 2000 Pro and Server, and XP Pro. We installed it on Win 2000 Server Domain Controller and Win XP Pro machines. The installation was easy with minimal prompts.

Once installed, the product can be configured through an MMC (Microsoft Management Console). The right pane of the console, where the configuration parameters are keyed in, has a Web-based look. This is a good move to provide Unix administrators, who haven’t worked with MMC, a familiar interface. The Unix machine we used was running PCQLinux 7.1 (based on RedHat 7.1).

There’s a “Server for NFS” component that has to be set up for sharing directories with Unix clients. Once set up, sharing directories is as easy as creating a Windows share, and it also creates a similar hand icon on the folder. This, however, appears only when you refresh the explorer’s view. Moreover, if this NFS shared folder is also made into a Windows share, then the latter’s graphical representation takes over. So you have no means of knowing that this folder is also an NFS share. There’s also a client for NFS component that can be installed on all Windows machines wanting to access shared directories in Unix. If you don’t want the hassle of installing an NFS client on each Windows machine, there’s a Gateway for NFS component. This allows Windows machines to access NFS shares. A User Name Mapping (UNM) service controls access to the NFS shares. It allows Windows users and groups to be mapped to the same on Unix. The system administrator should be extra careful in not mapping an unprivileged Unix user to a privileged Windows user (say the administrator). UNM does display a warning when you attempt to map a Unix user to Windows administrator. There is simple as well as advanced mapping. In simple mapping, SFU automatically maps similar named users and groups across Windows and Unix. With advanced mapping, one can map them manually. UNM can pick up Unix users and groups info from the password files or negotiates with an NIS (Network Information Service) for the same. We tested the UNM with an NIS service running on PCQLinux. Given only the NIS domain name, UNM could pick up the exported information by the

NIS. 

We found one small glitch in the mapping. Suppose a user account is created on the Windows server and mapped to a Unix/Linux user. This account is then given full access to an NFS share from Windows as well as Unix. Now, if the Windows counterpart of the mapped account is disabled, the NFS share is still accessible from the Unix machine. It’s only when the user’s account is deleted that the privileges are removed. 

The “Server for NIS” component we just mentioned uses the Active Directory to store the NIS data, therefore must be installed on a domain controller. There’s a migration wizard to migrate NIS data to Active Directory. Since PCQLinux creates a group name same as a user name (by default) conflicts occurred during the migration of the group map after the passwd map. But the causes of the conflicts were obvious and clearly stated in the log file. 

There’s a Telnet server that only supports NTLM authentication for secure access. Therefore, we were able to connect to the Telnet server only using plaintext authentication, since Linux does not support the former authentication. The need for a secure remote shell like SSH (Secure Shell) remains unquenched. Telnet server cannot be installed on a Windows XP machine. 

With the password synchronization component, same passwords can be maintained across the mapped Windows and Unix users. That is, a user (say shekhar) will have the same password to log into the Windows machine as well as Unix machine.

This is the only component for which we had to jump out of the SFU graphical configuration and set up things on the Linux machine. For the synchronization to work, an SSOD (Single Sign-On Daemon) should be running on the Unix machine.

SSOD was available on the SFU CD for HP-UX version 11, IBM AIX version 4.3.3, RedHat Linux 7.0 and Solaris 7 on Sparc. We were able to set up SSOD easily on PCQLinux 7.1 and achieve Windows to Unix password synchronization. That is, if the password of a user is changed on Windows, it also changes on Linux. SSOD can also be set up to work with NIS where it will execute the NIS Makefile on a password change. For Unix to Windows password sync to work, a PAM (Pluggable Authentication Module) had to be set up. The PAM module required for the same is available for the above mentioned Unixes. But the only way to stop the running SSOD daemon, is to force kill it (ps —9 ). 

The component of SFU worth applause is Interix. It’s a full-fledged Unix shell environment running within Windows. The Interix subsystem provides Korn and C shell environments with all the popular Linux shell commands and utilities. It also includes libraries–C, C++, Perl, Fortran, tcl/tk–GNU compilers (gcc,g++) and interpreters (ActiveState Perl). We were able to successfully run some Linux shell scripts and command line Perl programs. For task scheduling, Interix provides the popular cron daemon, which installs as a Windows service and executes the tasks specified in a crontab file picked up from Linux. The X11R5 (release 5), libc (version 3) and NCURSES libraries are provided. The X11 and libc libraries are of old versions though, with the latest versions being libc 6 (also called glibc) and X11R6.6 (release 6.6). 

The Bottom Line: SFU 3.0 is a useful service if you want to narrow down Windows and Unix administration. But to work with it, the administrator must be conversant with both Windows and Unix concepts. 

Shekhar Govindarajan at PCQ Labs