gnome-keyring Obtaining a TGT without unrestricted access to password.

Simo Sorce simo at redhat.com
Thu Jun 16 12:33:00 EDT 2011


On Thu, 2011-06-16 at 17:21 +0100, David Woodhouse wrote:
> On Thu, 2011-06-16 at 11:07 -0500, Nico Williams wrote:
> > > How does one square away the storing of a passwd in memory against
> > > this existing prevalent use case?  Other than simply transitioning
> > > to OTP in order to defeat it?
> > 
> > You either ignore this problem or you use OTP or PKINIT with
> > non-extractable private keys stored in smartcards. 
> 
> Or perhaps you don't consider it a problem at all, since it is the
> predominant mode of operation of Windows clients.

Windows clients do not store clear-text passwords.
And given MS is transitioning its customer based off of NTLM they will
most probably soon not store any NTLM hash either.

> I appreciate the KDC-admin viewpoint being presented, and I'm certainly
> not suggesting that you should accept this kind of caching behaviour on
> your well-run networks.
> 
> But most people running a Kerberos server probably don't even know
> they're doing it.
> 
> What I'm trying to achieve here is *optional* client behaviour which is
> acceptable on a "typical" Windows network, both from the security (for
> the admin) and the usability (for the user) point of view.
> 
> What I need to do, since I cannot *force* the admin to change policies
> for the benefit of the Linux clients, is fit in with the Windows model. 

As explained before the windows model do not use *cached* password to
renew tickets. They renew their credentials on screensaver unlock or
user the renewal period.
You can do both in Linux and we actually already do it in Fedora and
RHEL land for example when using SSSD.

You are attacking the problem at the wrong level (gnome) IMHO.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the krbdev mailing list