winbind does not refresh kerberos tickets
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
samba |
Fix Released
|
Medium
|
|||
samba (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Precise |
Fix Released
|
Low
|
Unassigned |
Bug Description
[Impact]
* If it happens on the client, the client can't authenticate to any kerberised servers (Windows or Linux).
* If it happens on the server, all clients (Windows or Linux) are unable to connect to that server any more.
* The main impact is very flaky network authentication on an LTS release that we will have to live with for a few more years.
[Workaround]
On the desktop run kinit to create a new ticket cache, or on a server restart the winbind daemon after logging in with a local account. This usually needs to be done once or twice a week on my desktop, but less frequently on servers.
[Test Case]
Requires an AD (or Samba 4?) domain with winbind configured to use it.
Use winbind refresh ticket = true
Set cached_login for pam_winbind.
Log onto a domain member using a domain account.
Winbind will create a standard Kerberos credential cache containing a TGT (Ticket Granting Ticket - eg something like krbtgt/
The klist command will verify the existence of the cache and the TGT in it.
At some point before the renewal lifetime is up, the credential cache will disappear preventing Kerberos apps from working. It is often at about 25-50% of the renewal lifetime, but not always.
The klist command will now report that it can't find the ccache.
With the bugfix, the ccache never disappears and Winbind will successfully renew the TGT.
[Original Description]
winbindd will renew kerberos tickets until they expire, but it seems unable to refresh them before expiry.
I have the following in smb.conf:
winbind refresh ticket = true
and have cached_login set for pam_winbind
After 7 days ( the renewal limit on AD kerberos tickets) the ticket expires and I lose access to my NFS home directory which uses sec=krb5
I have tried to debug why this is happening and have come to the conclusion that there are two important variables for ticket refreshing to work (both in winbind/
ccache_list
memory_creds_list
and that the function that stores the password for later refreshing use is called
winbindd_
This function though requires that the user is in ccache_list before it stores the password in a way it can be used by the rekinit part of the function krb5_ticket_
The problem as I see it is that winbind forks and the parent populates ccache_list and the child populates memory_creds_list.
This leads to the password not being stored in a way that can be used by the rekinit code in krb5_ticket_
As a dirty hack (attached) I tried populating memory_creds_list from the same location as ccache_list get populated (winbindd_
This hack "fixes" the problem.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: winbind 2:3.6.3-2ubuntu2.3
ProcVersionSign
Uname: Linux 3.2.0-27-generic x86_64
ApportVersion: 2.0.1-0ubuntu12
Architecture: amd64
Date: Wed Aug 15 11:30:27 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
ProcEnviron:
LANGUAGE=en_GB:en
TERM=xterm
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SambaClientRegr
SourcePackage: samba
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile.
mtime.conffile.
description: | updated |
Changed in samba: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
description: | updated |
description: | updated |
Changed in samba (Ubuntu): | |
status: | Confirmed → Fix Released |
Changed in samba (Ubuntu Precise): | |
importance: | Undecided → Low |
status: | New → Triaged |
Thank you for taking the time to report this bug and helping to make Ubuntu better. I appreciate the quality of this bug report and I'm sure it'll be helpful to others experiencing the same issue.
This sounds like an upstream bug to me. Please can you verify this by building directly from the latest upstream source? If this can be confirmed as an upstream bug, the best route to getting it fixed in Ubuntu in this case would be to file an upstream bug if you're able to do that. Otherwise, I'm not sure what we can do directly in Ubuntu to fix the problem.
If you do end up filing an upstream bug, please link to it from here. Thanks!