With Windows Services for Unix version 2.0, Microsoft has filled in some of those holes and has improved the operational quality of the software. However, a variety of new problems has been introduced, and not all of the old problems have been eliminated. In addition, some of the new features are dependent upon the product being deployed on Windows 2000 servers, which is not an option for everyone who wants this functionality. This last point is particularly true for the complex, large-scale environments that feel the cross-platform integration pain most acutely, since the inherent complexity of those networks dictates that enterprisewide infrastructure changes are evolutionary rather than revolutionary.

Shows Improvement

In the end, all these factors add up to give Windows Services for Unix 2.0 a grade of "better" when compared with Windows NT Services for Unix 1.0, but it does not yet qualify as the "best" solution for administrators looking to integrate their Windows and Unix network services. Users of version 1.0 should upgrade, but many administrators will be better off keeping Unix-based integration solutions, such as Samba, in place, while other sites will be most well-served with NFS-NIS integration tools on their Windows clients. Everybody should try version 2.0, however, because it does offer some compelling features, regardless of the holes.

Administrators can pick and choose which of the numerous components that comprise Services for Unix 2.0 they wish to install. For our tests, we focused on the NIS server (which is limited to Windows 2000), the NFS server and gateway--the latter of which lets an NT server publish external NFS mounts as local SMB (Server Message Block) shares--and the telnet server. Other components include an NFS client, a PC-NFSD (NFS daemon) server, an RSH (remote shell) server, ActiveState's Perl interpreter and a multitude of Unix-centric utilities.

Consolidated User Management

The most compelling aspect of Windows Services for Unix 2.0 is the promised ability to consolidate Windows and Unix user accounts via the provided NIS and PC-NFSD servers. This is an extremely tantalizing feature because the Holy Grail for most integration quests is the ability to define and manage user accounts in a single location, while also letting users authenticate and access network resources from multiple platforms. Depending on your environment and flexibility, this objective may be obtainable for some but is not entirely within everyone's reach. Nor does it always work well.

At the core of Windows Services for Unix 2.0 is the User Name Mapping service, which maps Unix user and group accounts to their Windows equivalents, and which is used by the NFS server and gateway components for file-system ACL (access-control list) mapping.

The User Name Mapping service is flexible in that it can pull Unix user and group IDs from an NIS server or from a locally defined pair of "passwd" and "group" files. These accounts then can be mapped dynamically to Windows NT or Windows 2000 domain accounts (for example, where the "ehall" Unix account matches the "ehall" NT account), or can be defined explicitly on a one-to-many basis (where the Unix accounts of "ehall" and "eric_hall" are both matched against the NT "ehall" account).

Once the User Name Mapping data has been defined, any Windows Services for Unix host can use the information (for example, a remote NFS server can use the local server's User Name Mapping service with its ACL maps), so you need to define this mapping only once if your account data is consistent across platform lines.

Windows 2000 servers with Active Directory also have the option of running an NIS server locally. When this feature is enabled, the Active Directory schema is extended to include Unix-centric user and group data such as UID (user ID) and GID (group ID) numbers, home directory, preferred shell and so forth. This data can then be read by the User Name Mapping service described above, by pointing the mapping agent's NIS client to the local NIS server. In essence, this allows Active Directory users and groups to be recursively mapped.

In our tests, we encountered problems with each of these mechanisms. On our NT 4.0 Advanced Server system, we copied a password and group file from a local Caldera Systems OpenLinux 2.3 server and used it for dynamic and static mappings. User accounts that were mapped dynamically were unable to access the NFS shares on that server fully, with the NT permissions sporadically rejecting access requests to the dynamically mapped user accounts. Once the users were explicitly mapped, the problem disappeared. However, sometimes the static mapping database would vanish, requiring us to rebuild the maps manually whenever we made a change to the database. This particular bug got old quickly, though Microsoft support indicated that a fix would be forthcoming.

On our local Windows 2000 Advanced Server, we installed the NIS server component and defined the user- and group-specific Unix attributes, such as the UID, GID and so forth. However, the NIS server does not publish all the data completely, nor does it allow for detailed modification. For example, issuing ypcat passwd requests from remote NIS clients returned all the user data except a person's full name, with the GECOS data always being returned as an empty field. In addition, there is no provision to change the advertised Unix name of a user or group, meaning that we couldn't publish the "Domain Users" group as the "users" group expected by our Unix hosts. According to Microsoft, the only way to publish an alternative name is to change the name as it appears in Active Directory.

There are some security risks here: NIS propagates user-name and password data in a relatively insecure form, for example. If you decide to put an NIS server on top of your Active Directory user-account database, you should be aware that anybody with the ability to ypcat passwd will be able to decrypt your user accounts easily. This is a problem with all NIS implementations but is still worth noting.

Another issue we encountered with the NIS server is that it prohibits users and groups from being assigned UID or GID values less than 100, meaning you cannot use the NIS Active Directory snap-in to publish system-level accounts. Although this is probably an intelligent default security measure, it knee-capped our integration efforts since we like having "httpd" and some other system-level service accounts stored in NIS. Moreover, the static mapping service has none of these restrictions, fully letting us map the "root" user with UID 0 to the NT "Administrator" user, and the "system" group with GID 0 to the "Domain Admins" group. Although it is possible to change the UID and GID values manually by editing the values stored in Active Directory, this is not something we want to do regularly.

When all this is added up, the NIS server component--while conceptually more attractive because of its integrated nature--is substantially less functional than the static mapping service and introduces some potential security risks.

However, if you do use the file-mapping service, you will need to define explicit mappings between the various accounts in order for the NT security permissions on NFS shares to function properly, as we encountered random ACL problems with the dynamic mapping service.

Note that the software's bundled PC-NFSD server does not use the User Name Mapping server to authenticate connection requests from NFS clients but instead requires that administrators manage an additional database for this purpose. Because this doubles the administrative duties and introduces additional password-synchronization problems, it severely limits the suite's potential as a consolidated account-management platform.