winbind vs. pam/nss alternatives

Steven French sfrench at us.ibm.com
Tue Mar 18 01:08:14 GMT 2003





>While there are probably more domain controllers than RFC 2307-compliant
>LDAP servers, it is the de facto LDAP nameservice schema for the UNIX
>platform, and is thus unlikely to disappear overnight. Many large
>organisations have deployed this schema (they are our customers).

I agree, but was thinking about ease of use, and longer term whether we
could have the
logon/caching/performance intensive UID/GID caching leveraged by the four
and five
main alternatives (winbind already supports two) and whether the caching
code for
a particular pam/nss daemon was already significantly better than winbind.
Seems
like extending one or the other pam/nss pair could be done in theory so the
client
logon daemon could autodetect RFC 2307 vs. AD vs. DCE/RPC and take away
some
of the configuration headache of moving a machine around to different
security
domains in heterogeneous environments.

The other thing that seems a little unusual is the idea of using pam_ldap
for authentication
(on the other hand nss_ldap makes more sense to me) because intuitively it
seems like
I need Kerberos tickets anyway (for nfs v4 client and eventually cifs
client) so why
don't I just get my TGT in the pam module (ala pam_winbind or pam_kerberos)
and only
use nss_ldap or nss_winbind (or a convergence of the two that autosenses
the server
schema).   The ldap client presumably prefers binding via Kerberos anyway
so seems
like Kerberos authentication is going to occur in any case.

Today Linux (and a few other Unix platforms) can require manual
reconfiguration
to switch to a different type of logon server, e.g. if an RFC 2307 server
is ever
replaced by Samba or Windows or vice versa even though PAM/NSS has
quite a bit of flexibility.  What are the implications if different users
from
different security domains (one Kerberized & RFC 2307 and one Samba or AD)
on the same physical client

I don't know how easily RFC 2307 could be reconciled with ActiveDirectory
on the
OpenLDAP side to make the issue on the client almost moot, but in the
meantime.

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



More information about the samba-technical mailing list