Bug 7591 - winbind doesn't obtain krb5 tickets after non-password login
Summary: winbind doesn't obtain krb5 tickets after non-password login
Status: NEW
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.5.4
Hardware: Other Linux
: P3 normal
Target Milestone: ---
Assignee: Michael Adam
QA Contact: Samba QA Contact
Depends on:
Reported: 2010-07-27 03:38 UTC by David Woodhouse
Modified: 2010-07-28 05:48 UTC (History)
0 users

See Also:

attempt to implement ESTABLISH_CREDS (21.37 KB, patch)
2010-07-27 06:59 UTC, David Woodhouse
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Woodhouse 2010-07-27 03:38:39 UTC
When I log in using SSH key auth (or presumably also with gdm autologin or fingerprint), winbind doesn't obtain and refresh my Kerberos tickets for me.

That behaviour is only triggered by a successful password login.

Perhaps pam_winbind should do something other than log 'PAM_ESTABLISH_CRED not implemented' when it's asked to establish credentials?

All it needs to do is trigger the same mechanism that retrospectively obtains the Kerberos ticket after an offline login, I think.
Comment 1 David Woodhouse 2010-07-27 06:59:16 UTC
Created attachment 5875 [details]
attempt to implement ESTABLISH_CREDS

I got this far before finding that we can't actually obtain a ticket unless we know the *real* password, not just a hash of it (which AFAICT is all we have cached).

Windows can manage though, when I log in using a fingerprint. Does it really cache the unhashed password, or is there a way to obtain a TGT using only the hash?
Comment 2 David Woodhouse 2010-07-28 05:48:27 UTC
Note that the patch is a work in progress. Known issues are that it won't pass the KRB5CCNAME back from winbindd and set it in the PAM client, and it will leak a refcount on the cached credentials it uses. And there's probably more wrong with it than that. (It probably shouldn't do anything at all if KRB5CCNAME was already set because it *was* a password login. Or maybe we should stop the password login code path from calling add_ccache_to_list() on the basis that it'll be done in the establish_cred step now.)

More caffeine required.