Samba Upgrade Offers Greater Flexibility

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 last 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, in San Jose, Calif.

Not only does winbind make Samba much easier to administer, but it also has profound implications for many other Unix programs.

The winbind component uses PAM (Pluggable Authentication Module), found in Linux and 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 in to 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 in to GNOME, or GNU Network Object Model Environment (KDE, or K Desktop Environment, should work as well, although we didnt test this), or to access the server using Secure Shell 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 user names (or groups of user names) to Unix user names.

For us at eWeek Labs, this meant we used Samba servers only 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 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 might 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.