winbind vs. pam/nss alternatives

[Luke Howard]

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

We have always argued that caching of nameservice information should be 
performed by a provider-agnostic mechanism, such as nscd. We agree that
the existing implementation of nscd is flawed in that it does not cache
enumerations, and to that end we suggest that one may run a caching LDAP
proxy on each client machine and have nss_ldap communicate with it via
domain sockets (ldapi://).

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

As I see it, daemon architecture notwithstanding, winbindd and nss_ldap
cater to different problem spaces. That could change if winbindd supported
RFC 2307, admiteddly.

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

Not everyone uses Kerberos; particularly on UNIX, the deployment cost for a
long time has been quite high (no integrated directory and authentication
server, perceived complexity, etc), and many organisations have chosen to
deploy LDAP-based authentication solutions. I for a long time argued that
LDAP was not an authentication protocol, and that a pam_ldap module should
not exist, but in the end there was a demonstrable need for such a module.

>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

As long as you can avoid namespace collision, there is no problem with this.
Of course, avoiding namespace collision is difficult without a hierchical
namespace, and thus requires some administrative collusion.

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

There are schema conflicts between RFC 2307 and Active Directory. Microsoft
chose to resolve this in their Services for UNIX product by renaming some
attributes and object classes (moreso in subsequent versions). We have had
to address similar issues in our domain controller implementation, albeit
less aggressively.

-- Luke

--
Luke Howard | PADL Software Pty Ltd | www.padl.com