A Window into the Unix World

• 12/13/2000

As it turnsout, Microsoft has made good on its promise. Not only did the company releaseits long-awaited Windows 2000 Services for Unix in early April, but it alsotook the wraps off its much anticipated Windows 2000 Services for NetWare inJuly. Not bad, eh?

How, then,does Windows 2000 Services for Unix -- renamed Windows Services for Unix 2.0 --measure up? Does it provide IT managers with the tools they need to effectivelymanage Unix environments from Windows 2000, and -- more importantly -- tomanage their Windows 2000 environments from Unix? How does it compare withother freely available open source software (OSS) tools from both the opensource community and established vendors?

To answerthese and other questions, we put Windows Services for Unix 2.0 through itspaces.

Installation

Weinstalled Windows Services for Unix 2.0, MKS Toolkit, and Cygnus Solutions’Cygwin on an AMD Athlon 600-MHz system with 256 MB of RAM running Windows 2000Advanced Server with Service Pack 1 (SP1) installed. Our lab environmentconsisted of a melange of Windows NT 4.0 client machines; a Windows NT 4.0Server with SP5 running Oracle8; a Sun Solaris box running Netscape EnterpriseServer 3.0; and a variety of Debian Linux servers -- six in all -- that handletasks ranging in scope from simple Web serving with Apache to firewall and IPmasquerading to DNS.

WindowsServices for Unix 2.0 does not install remote shell (rsh) by default. This isgood because rsh is generally considered even less secure than the legacyTelnet protocol.

On the otherhand, it also doesn't install the Unix cron scheduling utility by defaulteither. This means administrators will have to use cron on Unix systems andAT.EXE on Windows NT/2000 systems to schedule tasks. We installed cron afterinstallation was complete, which allowed us to manage scheduling on our Windows2000 and Windows NT systems from our Solaris and Linux servers. Very nice. Perlfans out there will also want to note the fact that Windows Services for Unix2.0 doesn't install Microsoft's ActivePerl implementation by default. We're bigPerl boosters, so we installed ActivePerl during our post-install configurationof Windows Services for Unix.

On theTreadmill

Two of thestar acts in Windows Services for Unix's portfolio are its support for NetworkFile System (NFS) -- the Unix standard for network file sharing -- and itsintegration, by way of Active Directory, with NIS, a pseudo-directory namingservice first developed by Sun Microsystems that has become a de facto Unixstandard.

We didn'thave a chance to put NIS through its paces -- we don't use it internally, andwe weren't too keen on rolling out Active Directory to test the integration andinteroperability between the two -- but we did take advantage of WindowsServices for Unix's NFS gateway support. In all, we found that administratorsand users who would rather mouse in a GUI than cat from a Unix command linewill love the integration of NFS with the now-familiar Network Neighborhood.NFS shares are easily mapped just like SMB shares, and the NFS Gatewaytranslates NFS shares to Windows-native SMB shares, for easy exporting to 9xclients.

We alsofound Windows Services for Unix's new Telnet client to be a godsend: We wouldhave much rather instructed a monkey to carry index cards to a terminal andenter commands manually than use the old Windows Telnet client. But the clientshipping with Windows Services for Unix 2.0 is as close to a standardRFC-compliant implementation as Microsoft will probably ever get. For anyonewho is not interested in preserving network security by encrypting terminalemulation settings -- using secure shell (ssh), for example -- the new Telnetclient is a huge improvement over what was previously available.

Microsoft'sActivePerl implementation seems to be the real deal, as well. Although wedidn't get to play around with it extensively, it seemed to offer a fundamentalreduplication of the feature set found on Unix platforms. More importantly, ournoses could barely detect a whiff of the proprietary embrace-and-extend odorthat hovers around many of Microsoft's other adoptions of OSS technologies,such as Kerberos.

As far asoverall manageability is concerned, we found the management tools included withWindows Services for Unix to be exactly what we expected: simple yet powerful,and requiring a minimum of interaction with the command line. This has alwaysbeen Windows' strong suit. We do have more than our fair share of gripes aboutWindows Services for Unix 2.0, however. Although the Telnet daemon that itships with provides enhanced support for more simultaneous multiuser sessions-- up to 50 -- it still supports only the legacy Telnet protocol. With this inmind, we have to wonder to what extent enterprise IT organizations are stillusing vanilla Telnet, anyway, because it sends passwords in clear-text over thewire and consequently poses a significant security risk. Why, then, couldn'tMicrosoft have provided an ssh daemon for Windows Services for Unix 2.0? Suchwould have been of real value to mixed Windows and Unix shops alike -- and italone could have justified the deployment of Windows Services for Unix 2.0 inmany enterprise IT organizations.

Then thereis the issue of Windows Services for Unix only providing support for the shshell, which lacks Unix essentials such as tab completion and which is suitableprimarily as a scripting environment. As it is, we wonder why Microsoftcouldn't have included support for a shell such as bash, which has gottenpretty popular. It's even included with Solaris. And if not bash, why couldn'tRedmond at least have provided support for ksh or csh? As it stands, if youwant a functional Unix shell in a Windows environment, you'll have to pay forthe MKS Toolkit, which ships with both ksh and csh.

Theprospect of using Windows Services for Unix's Password Synchronizationcomponent to simultaneously manage passwords on Windows and on Unix boxesexcited us, so we were destined to be disappointed in this regard. Indeed,while Windows Services for Unix 2.0 does perform secure password propagation,it only leverages the deprecated Unix crypt encryption scheme and does notsupport the modern MD5 algorithms that any sensible administrator would use. Wedid find Windows Services for Unix 2.0's User Name Mapping feature to be a joy.It allowed us to map the Windows 2000 group privileges to equivalent Unix groupprivileges. Thus, we could map our Windows 2000 "Administrator" groupto our Unix "root" group -- which means that we could access NFSshares and perform other administrative tasks with less acrobatics. Finally --and this is nothing more than a quibble -- while putting Windows Services forUnix through its paces, we discovered that its "find" command causesa conflict with Windows 2000's own FIND.EXE command. This occurs because whenWindows Services for Unix 2.0 is installed, Windows 2000's command path ismodified to place the %SFUDIR%\common directory before other directories. As aresult, the Windows Services for Unix “Find” command will run instead of theWindows find command unless the path to the Windows find command is specifiedon the command line.

Conclusions

We're notquite sure what to make of Windows Services for Unix 2.0. On the one hand, webelieve that both its native support for NFS and its integration with NIS arepowerful features that many IT organizations will welcome. And we think that itwill make it much easier for Windows administrators to manage Unix systems fromWindows environments.

However, wesuspect that most Unix administrators will be dissatisfied with WindowsServices for Unix. First of all, many of the features that it purports toprovide -- a Unix shell environment, enhanced support for multiuser terminalhosting, and a Perl implementation, among others -- are usually availableseparately, and free of charge, from open source software development projects.Secondly, its support for necessities such as multiuser terminal hosting --Telnet only -- and a Unix shell environment -- sh only -- is bare bones, atbest, and is of dubious value. On the plus side, its cron utility did let usschedule Windows 2000 events from our Unix platforms, which was a welcometouch. And we were able to establish password synchronization and user namemapping between our Unix and Windows 2000 systems, which also was welcome.

In summary,Windows Services for Unix 2.0 seems to have stacked the deck, so to speak, infavor of managing Unix systems from Windows -- rather than the other wayaround.

WindowsServices for Unix 2.0
Microsoft Corp., Redmond, Wash.
www.microsoft.com

Price: $149

Pros/Cons:
+ Simple, yet powerful, management tools require minimum interaction withcommand line

+ Supportfor NFS and NIS are powerful features

- Stillsupports only the legacy TELNET protocol

- Onlyprovides support for the legacy sh shell