systematic Kerberization

[Felipe Alfaro Solana]

On Tue, 2004-05-11 at 19: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.

Yep... It has worked that way since NT 4.0.

> Also, it's always possible to select the local computer and log into that,
> rather than into the domain.

Which is the same as authenticating against the local shadow password
;-)

We see there aren't much differences, indeed.
What worries me is how cached login information can be used by an
attacker to later gain access to resources on the local machine or the
network.