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:
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.