Where winbindd is not used Samba ( smbd ) uses the underlying UNIX/Linux mechanisms to resolve the identity of incoming network traffic. This is done using the LoginID (account name) in the session setup request and passing it to the getpwnam() system function call. This call is implemented using the name service switch (NSS) mechanism on modern UNIX/Linux systems. By saying "users and groups are local," we are implying that they are stored only on the local system, in the /etc/passwd and /etc/group respectively.

For example, when the user BERYLIUM\WambatW tries to open a connection to a Samba server the incoming SessionSetupAndX request will make a system call to look up the user WambatW in the /etc/passwd file.

This configuration may be used with standalone Samba servers, domain member servers (NT4 or ADS), and for a PDC that uses either an smbpasswd or a tdbsam-based Samba passdb backend.

In this situation user and group accounts are treated as if they are local accounts. The only way in which this differs from having local accounts is that the accounts are stored in a repository that can be shared. In practice this means that they will reside in either an NIS-type database or else in LDAP.

This configuration may be used with standalone Samba servers, domain member servers (NT4 or ADS), and for a PDC that uses either an smbpasswd or a tdbsam-based Samba passdb backend.

There are many sites that require only a simple Samba server or a single Samba server that is a member of a Windows NT4 domain or an ADS domain. A typical example is an appliance like file server on which no local accounts are configured and winbind is used to obtain account credentials from the domain controllers for the domain. The domain control can be provided by Samba-3, MS Windows NT4, or MS Windows Active Directory.

Winbind is a great convenience in this situation. All that is needed is a range of UID numbers and GID numbers that can be defined in the smb.conf file. The /etc/nsswitch.conf file is configured to use winbind , which does all the difficult work of mapping incoming SIDs to appropriate UIDs and GIDs. The SIDs are allocated a UID/GID in the order in which winbind receives them.

This configuration is not convenient or practical in sites that have more than one Samba server and that require the same UID or GID for the same user or group across all servers. One of the hazards of this method is that in the event that the winbind IDMAP file becomes corrupted or lost, the repaired or rebuilt IDMAP file may allocate UIDs and GIDs to different users and groups from what was there previously with the result that MS Windows files that are stored on the Samba server may now not belong to the rightful owners.

The IDMAP_RID facility is new to Samba version 3.0.8. It was added to make life easier for a number of sites that are committed to use of MS ADS, that do not apply an ADS schema extension, and that do not have an installed an LDAP directory server just for the purpose of maintaining an IDMAP table. If you have a single ADS domain (not a forest of domains, and not multiple domain trees) and you want a simple cookie-cutter solution to the IDMAP table problem, then IDMAP_RID is an obvious choice.

This facility requires the allocation of the idmap uid and the idmap gid ranges, and within the idmap uid it is possible to allocate a subset of this range for automatic mapping of the relative identifier (RID) portion of the SID directly to the base of the UID plus the RID value. For example, if the idmap uid range is 1000-100000000 and the idmap backend = idmap_rid:DOMAIN_NAME=1000-50000000 , and a SID is encountered that has the value S-1-5-21-34567898-12529001-32973135-1234, the resulting UID will be 1000 + 1234 = 2234.

In this configuration winbind resolved SIDs to UIDs and GIDs from the idmap uid and idmap gid ranges specified in the smb.conf file, but instead of using a local winbind IDMAP table, it is stored in an LDAP directory so that all domain member machines (clients and servers) can share a common IDMAP table.

It is important that all LDAP IDMAP clients use only the master LDAP server because the idmap backend facility in the smb.conf file does not correctly handle LDAP redirects.

The use of LDAP as the passdb backend is a smart solution for PDC, BDC, and domain member servers. It is a neat method for assuring that UIDs, GIDs, and the matching SIDs are consistent across all servers.

The use of the LDAP-based passdb backend requires use of the PADL nss_ldap utility or an equivalent. In this situation winbind is used to handle foreign SIDs, that is, SIDs from standalone Windows clients (i.e., not a member of our domain) as well as SIDs from another domain. The foreign UID/GID is mapped from allocated ranges (idmap uid and idmap gid) in precisely the same manner as when using winbind with a local IDMAP table.

The nss_ldap tool set can be used to access UIDs and GIDs via LDAP as well as via Active Directory. In order to use Active Directory, it is necessary to modify the ADS schema by installing either the AD4UNIX schema extension or using the Microsoft Services for UNIX version 3.5 or later to extend the ADS schema so it maintains UNIX account credentials. Where the ADS schema is extended, a Microsoft Management Console (MMC) snap-in is also installed to permit the UNIX credentials to be set and managed from the ADS User and Computer Management tool. Each account must be separately UNIX-enabled before the UID and GID data can be used by Samba.