Section 7.2. Dissection and Discussion

7.2. Dissection and Discussion

Recent Samba mailing-list activity is witness to how many sites are using winbind. Some have no trouble at all with it, yet to others the problems seem insurmountable. Periodically there are complaints concerning an inability to achieve identical user and group IDs between Windows and UNIX environments.

You provide step-by-step implementations of the various tools that can be used for identity resolution. You also provide working examples of solutions for integrated authentication for both UNIX/Linux and Windows environments.

7.2.1. Technical Issues

One of the great challenges we face when people ask us, "What is the best way to solve this problem?" is to get beyond the facts so we not only can clearly comprehend the immediate technical problem, but also can understand how needs may change.

There are a few facts we should note when dealing with the question of how best to integrate UNIX/Linux clients and servers into a Windows networking environment:

• A domain controller (PDC or BDC) is always authoritative for all accounts in its domain. This means that a BDC must (of necessity) be able to resolve all account UIDs and GIDs to the same values that the PDC resolved them to.

• A domain member can be authoritative for local accounts, but is never authoritative for domain accounts. If a user is accessing a domain member server and that user's account is not known locally, the domain member server must resolve the identity of that user from the domain in which that user's account resides. It must then map that ID to a UID/GID pair that it can use locally. This is handled by winbindd.

• Samba, when running on a domain member server, can resolve user identities from a number of sources:

  - By executing a system getpwnam() or getgrnam() call. On systems that support it, this utilizes the name service switch (NSS) facility to resolve names according to the configuration of the /etc/nsswitch.conf file. NSS can be configured to use LDAP, winbind, NIS, or local files.

  - Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured). This requires the use of the PADL nss_ldap tool (or equivalent).

  - Directly by querying winbindd. The winbindd contacts a domain controller to attempt to resolve the identity of the user or group. It receives the Windows networking security identifier (SID) for that appropriate account and then allocates a local UID or GID from the range of available IDs and creates an entry in its winbindd_idmap.tdb and winbindd_cache.tdb files.

  If the parameter idmap backend = ldap:ldap://myserver.domain was specified and the LDAP server has been configured with a container in which it may store the IDMAP entries, all domain members may share a common mapping.

  Irrespective of how smb.conf is configured, winbind creates and caches a local copy of the ID mapping database. It uses the winbindd_idmap.tdb and winbindd_cache.tdb files to do this.

  Which of the resolver methods is chosen is determined by the way that Samba is configured in the smb.conf file. Some of the configuration options are rather less than obvious to the casual user.

• If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable of being resolved using) the NSS facility, it is possible to use the winbind trusted domains only = Yes in the smb.conf file. This parameter specifically applies to domain controllers, and to domain member servers.

For many administrators, it should be plain that the use of an LDAP-based repository for all network accounts (both for POSIX accounts and for Samba accounts) provides the most elegant and controllable facility. You eventually appreciate the decision to use LDAP.

If your network account information resides in an LDAP repository, you should use it ahead of any alternative method. This means that if it is humanly possible to use the nss_ldap tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, because it provides a more readily controllable method for asserting the exact same user and group identifiers throughout the network.

In the situation where UNIX accounts are held on the domain member server itself, the only effective way to use them involves the smb.conf entry winbind trusted domains only = Yes. This forces Samba (smbd) to perform a getpwnam() system call that can then be controlled via /etc/nsswitch.conf file settings. The use of this parameter disables the use of Samba with trusted domains (i.e., external domains).

Winbind can be used to create an appliance mode domain member server. In this capacity, winbindd is configured to automatically allocate UIDs/GIDs from numeric ranges set in the smb.conf file. The allocation is made for all accounts that connect to that domain member server, whether within its own domain or from trusted domains. If not stored in an LDAP backend, each domain member maintains its own unique mapping database. This means that it is almost certain that a given user who accesses two domain member servers does not have the same UID/GID on both servers however, this is transparent to the Windows network user. This data is stored in the winbindd_idmap.tdb and winbindd_cache.tdb files.

The use of an LDAP backend for the Winbind IDMAP facility permits Windows domain SIDs mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all domain member servers so configured. This solves one of the major headaches for network administrators who need to copy files between or across network file servers.

7.2.2. Political Issues

One of the most fierce conflicts recently being waged is resistance to the adoption of LDAP, in particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP is different and requires a new approach to the need for a better identity management solution. The more you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm.

LDAP is a most suitable solution for heterogenous environments. If you need crypto, add Kerberos. The reason these are preferable is because they are heterogenous. Windows solutions of this sort are not heterogenous by design. This is fundamental it isn't religious or political. This also doesn't say that you can't use Windows Active Directory in a heterogenous environment it can be done, it just requires commercial integration products. But it's not what Active Directory was designed for.

A number of long-term UNIX devotees have recently commented in various communications that the Samba Team is the first application group to almost force network administrators to use LDAP. It should be pointed out that we resisted this for as long as we could. It is not out of laziness or malice that LDAP has finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total organizational directory needs.