Problem solve Get help with specific problems with your technologies, process and projects.

Taking Samba-3 beyond file and print serving, part one

Those who are familiar with Samba know it provides file and print services, but not everyone is aware of the other services that Samba provides.

Those who are familiar with Samba know it provides file and print services, but not everyone is aware of the other services that Samba provides. With Samba running on Linux, IT administrators can provide high levels of interoperability with the Microsoft Windows environment extending well beyond simple file and print services.

This tip reviews key factors in the interoperability between the host platform that Samba is running on and the Microsoft Windows environment and some of its essential services. In part one, I cover the interoperability challenges inherent in heterogeneous IT environments and Active Directory domain membership. In part two, I offer tips on Windows NT 4 domain replacement and SQUID integration with Windows networking.

Of course, many IT pros are Linux fans and want to run Linux and Linux only in the enterprise. Well, good luck with that; but, in the meantime, just about everyone is living in a heterogeneous IT world. So, interoperability between all platforms is a condition that must be achieved for an enterprise to work well, and Samba helps the sys admin meet that requirement.

With IT heterogeneity as a given, of course network administrators are interested to know how to integrate Samba file and print servers into their existing Microsoft Active Directory environments. Also, sites that are still using Microsoft Windows NT4 style domains are interested to know how Samba-3 can migrate domain user accounts to a Samba server, and sites that have used Microsoft ISA proxy server will be pleased to know that Samba and Squid can play together to provide similar capabilities.

The Challenge

Samba is a user space application that runs on many platforms, but is used primarily on Unix and Linux systems to provide a high level of interoperability. An understanding of some key differences between the Samba host environment and the Microsoft Windows networking world will help us to appreciate the intricacies of the interoperability challenge. Whatever problems there may be in bridging the gap between these two very different worlds are aptly handled by Samba, with a little help from the network administrator.

The typical Windows networking administrator does not care how Samba works, he just wants to meet user needs in the rapidly changing IT world.

The administrator's and network manager's questions typically boil down to:

  • How can I integrate my Samba server into my Active Directory so that my users will have transparent access to their files without having to worry about the server the files are stored on?
  • How can I replace my aging Window NT 4 domain without losing user accounts and passwords and avoid having to migrate to Active Directory?
  • How can I restrict access to the proxy server to only users who are logged onto Windows workstations?

Under the hood

It is well recognized that Microsoft Windows uses a security model that differs entirely from that of the typical Unix system that plays host to Samba. Samba implements mechanisms that map Windows security identifiers (SIDs) to Unix security identifiers (UIDs and GIDs). The precise method employed depends on how Samba is deployed.

Active Directory domain membership

The integration of Samba-3 servers into an existing Microsoft Windows Active Directory (ADS) environment requires the use of Kerberos based authentication. Samba-3 can be compiled and linked with either MIT Kerberos 1.3.1 (or later) or Heimdal Kerberos 0.6.3 (or later).

The configuration settings required for ADS interoperability are documented in the Samba-HOWTO-Collection (chapter six, Section 6.4). A detailed example of a Samba-3 server joining an Active Directory domain as a domain member server is provided in chapter nine of the Samba Guide.

In respect to the mapping of Windows SIDs to UNIX UIDs/GIDs the administrator should refer to chapter 12 of the Samba-HOWTO-Collection. The three main methods used to manage identity mapping are:

  • Use of winbind with per-machine mappings (Note: the actual UID that is mapped to a particular SID will not be the same on all Samba servers that are domain members.);
  • Use of winbind_idmap - this uses the relative identifier (RID) component of the user SID as the UID (This method can be used only within a single ADS domain); and,
  • Use of an LDAP directory to store the IDMAP data.

The IDMAP facility is requires platform support for the Name Service Switcher (NSS). In addition, on platforms that have support for the Pluggable Authentication Modules (PAM), winbind can be used to provide native Unix/Linux system logins using login account information from Active Directory.

The level of integration afforded by Samba's winbind utilities is convenient to use and eliminates the need to create local UNIX or Linux accounts. The result is a level of integration many call Single-Sign-On (SSO), but this is not the technically correct term for this functionality. A more correct description of this functionality is centrally managed and centrally stored user and group accounts.

Integration of Samba-3 servers into the Active Directory is the highest growth area for Samba-3 deployment today.

Continue to part two for a discussion on Windows NT 4 replacement, SQUID integration with Windows networking and more.

About the author: John H. Terpstra is CTP of IT an consulting firm, Primastasys Inc., as well as author of several IT books and Ask the Expert advisor for

Dig Deeper on Linux servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.