systematic Kerberization

[Havoc Pennington]

On Tue, 2004-05-11 at 13:25, Chris Ricker wrote:
> On Tue, 11 May 2004, Havoc Pennington wrote:
> 
> > On Tue, 2004-05-11 at 10:26, Chris Ricker wrote:
> > > I'm well aware of how it works. I'm also aware that it doesn't solve the
> > > problem of wanting to work disconnected. Kerberos ticket caching still
> > > requires initial connectivity. It also does nothing for LDAP, NIS, etc.
> > > You'd need a totally new ad-hoc caching mechanism above and beyond the krb
> > > ticket cache, and I don't think it would turn out to be something any sane
> > > organization would want.... Local accounts, OTOH, are an access control
> > > mechanism that is at least well-understood, which is why our standard is to
> > > fall back to them if distributed is unavailable.
> > 
> > What does Windows do for laptops?
> 
> By default, domain accounts are cached locally, so that once you've logged
> into a machine joined to the domain as a specific user, you can in the
> future log in as that domain user to that machine using the cached password
> even when disconnected. This caching of domain accounts can be disabled
> through a registry edit, and various aspects of the caching can be
> configured through the registry as well.
> 
> Also, it's always possible to select the local computer and log into that,
> rather than into the domain.
> 

So the message I've gotten from others is "Windows solves this problem
and Linux does not" and they were aware of the ability to set up a local
passwd file when complaining.

I think the question we have to answer is why is there a perceived
deficiency vs. Windows, and can we address that without fundamental
security problems. Appears the perceived deficiency would include 1) we
aren't working out of the box, only if you fool around with it and
possibly requiring the end user to run authconfig 2) the local/remote
passwords can get out of sync.

Havoc