Kerberos is certainly a barrier to adoption, and that's why I'm *not* dropping the PAM support. it works, it's well tested, and it's a perfectly reasonalbe implementation. That will remain in the code permanently, and we'll just recommend a Best Practice of use krb5.
Password caching is as good as dead... On Fri, Jun 11, 2010 at 10:00 AM, Steven Jenkins <[email protected]>wrote: > 2010/6/11 Phillip Moore <[email protected]>: > > > > Well, AD *is* Kerberos, but it's another matter entirely to manage the > > configuration of Kerberos on the UNIX clients. If someone doesn't have > > support for it today, adding it is non-trivial. > > OTOH, it isn't that hard, once you understand how the peices fit > together. > > Certainly, being able to help clients leverage this is a valuable > service > > to offer. > > Yes, and a former employer (as well as other companies) offers such > services. > > Looking at the experience of AFS, though, I think that requiring > Kerberos has been a significant barrier to adoption. EFS should not > require Kerberos in all cases, however -- using the same security > model as the underlying network filesystem is very understandable to > new adopters, so ... > > NFSv2/3 - use uids and -trust- the client > NFSv4 - use whatever model (uids, GSSAPI..) > AFS - whatever model (Kerberos right now, but others are in the works) > > And, yes, password caching is bad. Trusting the client is arguably > worse, but at least trusting the client is what a site is currently > doing. > > Steven > _______________________________________________ > EFS-dev mailing list > [email protected] > http://mailman.openefs.org/mailman/listinfo/efs-dev >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
