Windows domain accounts can now be used as if they were local accounts on Linux and Solaris systems.
Samba, the Windows-compatible file and print server, takes a major manageability step forward with Version 2.2.2, providing new flexibility for administrators who want to use Unix servers as Windows file servers.
The open-source Samba (downloadable from www.samba.org
) also makes it easier than ever before to integrate Unix workstations into a Windows environment.
The 2.2.2 update, which became available earlier this month, includes a new component called winbind that provides real-time directory integration between a Unix workstation and a Windows NT or Windows 2000 domain controller. "All of a sudden, you get single sign-on, with no maintenance of users," said Jeremy Allison, a Samba lead developer.
Not only does windbind make Samba much easier to administer, but it also has profound implications for many other Unix programs.
Winbind uses the Pluggable Authentication Module found in Linux and Sun Microsystems Inc.s Solaris to make the Windows directory a native authentication back end for the many PAM-aware Unix programs.
Once we had made the appropriate PAM configuration file changes, we could log into a Linux workstation at the console using any Windows domain account (including using accounts in trusted domains). We could also use Windows accounts to log into Gnome (KDE should work as well, although we didnt test this) or to access the server using SSH or FTP.
Previous versions of Samba required that administrators manually create a Unix user name that matched the account name of a Windows user (if per-user security was required), or use a mapping file that statically matched Windows usernames (or groups of usernames) to Unix usernames.
For us at eWEEK Labs, this meant that we only used Samba servers for public file shares open to everyone, to avoid having to manually keep Windows and Unix user directories in sync. (We mapped all Windows domain names to a "nobody" Unix user.)
Winbind does this mapping dynamically, creating a local user ID on the fly and storing the result so that the mapping is permanent. However, the mapping is generated and stored locally, so winbind could have interoperability problems with other winbind-equipped servers sharing data using Network File System (which may have the same Windows account mapped to a different Unix user ID).
The Samba development team is working on ways to keep the winbind ID mappings in sync between multiple machines, and expects to release code for this in the next few months.
eWEEK Labs West Coast Technical Director Timothy Dyck can be reached at email@example.com.