winbind vs. pam/nss alternatives

[Steven French]

>From a quick check of a couple of distributions it looks like winbind is
not included as part of the logon (pam/nss) configuration choices although
users who know what they are doing could manually configure it by hand
editing files after the installation of Samba.

Discounting the esoteric, useless or insecure options for pam/nss, leaves a
few common choices (for remote authentication/user information) which
distributions seem to offer:

pam_ldap/nss_ldap or
pam_kerberos/nss_ldap
and the older pam_smb? (pam_ntdom?)

Given that rather meagre list, winbind looks more appealing among other
reasons because it can handle these operations via a choice of multiple
network protocols, and also because it presumably performs better.

A couple of obvious questions:
1) Is winbind likely to be preferable (e.g. due to better performance with
the new dual daemon approach) than pam_ldap/nss_ldap?
2) In particular is it likely to be better than the alternatives for the
case of the common kerberized client applications (not just nfs v4 and
eventually the cifs vfs clients)
3) Could winbind easily handle some of the nss lookups via ldap ala rfc
2307 schema (if it matters anymore - it is just an experimental RFC) as a
fallback choice if the ldap server did not store user/group info in the
ActiveDirectory style.  It looks like winbindd_ cache.c already handles two
backends winbindd_ads and winbindd_rpc      With the addition of ldap to
winbind, it seems odd to have to worry about the older pam_ldap/nss_ldap
which has a much, much smaller installed base (ie lots more domain
controllers than RFC2307 compliant security servers)
4) Is the reason that winbind doesn't appear particular important for
distributions because it is (relatively) hard to configure (smb.conf,
machine joining the domain etc.)? or that they haven't recognized winbind
improvements?



Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at us.ibm.com