Bug 6750 - After 'machine password timeout' /etc/krb5.keytab is not updated
Summary: After 'machine password timeout' /etc/krb5.keytab is not updated
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.6.1
Hardware: x86 Linux
: P3 major
Target Milestone: ---
Assignee: Pavel Filipenský
QA Contact: Samba QA Contact
Depends on:
Reported: 2009-09-21 16:25 UTC by Jason Gunthorpe
Modified: 2021-06-30 06:46 UTC (History)
9 users (show)

See Also:

keytab autorefresh patch for 3.6 (1.96 KB, patch)
2014-02-25 15:12 UTC, Vitaliy Filippov
no flags Details
Keytab auto-refresh patch for 4.1 (2.05 KB, patch)
2014-06-14 07:33 UTC, Vitaliy Filippov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Gunthorpe 2009-09-21 16:25:18 UTC
It is great that samba has leaned how to refresh the machine password, but when it does this and doesn't update the /etc/krb5.keytab it breaks every other kerberos service on the machine.

I can't figure out how to get it do this..

My smb.conf has:
kerberos method = secrets and keytab

I can't find any code that looks like it would update the keytab so I guess it is broken..

The keytab should be refreshed, but a better job is needed compared to 'net ads keytab create' the latter doesn't create entries for any additional SPNs the host may have (say created by net ads keytab add). Which I think is a separate bug in of itself..

No idea how to handle multiple keytabs, my webserver for instance has a apache-only keytab with just the various http SPNs in it.
Comment 1 Guenther Deschner 2009-09-22 10:03:02 UTC
The current code will simply don't do any machine account password changes once you use a kerberos keytab as per smb.conf setting. Are you saying winbind tries to do so ?

Auto refreshing the keytab potentially requires admin credentials, for that reason it wasn't added when implementing the automatic machine password change mechanism initially.
Comment 2 Jason Gunthorpe 2009-09-22 15:13:54 UTC
Which smb.conf setting are you referring to? I have 'kerberos method = secrets and keytab' and the kvno of my host is increasing once a week. This is samba 3.4.0

Why does regenerating the keytab require admin credentials? Is that some weird corner case? It works for me using my ordinary user (non-admin) credentials. I thought the process would be to generate the keytab entries from the machine password and current kvno - just as samba must be doing on the fly internally to compute the keys. The machine account can surely be used to access any ancillary data?

I always thought it was just a bug that net ads keytab create prompted for a password..

FWIW, this was not happening in 3.3.2 and prior versions.
Comment 3 Michael Adam 2009-09-22 15:57:01 UTC
reassigning to günther...
Comment 4 Simo Sorce 2009-09-23 11:02:09 UTC
Guenther, I think that if the password change is successful we should just generate a new keytab locally and save it over /etc/krb5.keytab
Comment 5 Guenther Deschner 2011-10-28 11:51:43 UTC
Planning to finally fix this for 3.6.x
Comment 6 Martin 2013-04-14 17:43:13 UTC
(In reply to comment #5)
> Planning to finally fix this for 3.6.x

Is this fixed in 3.6.x?

Does there need to be any special setting in smb.conf to enable this functionality? Using 3.6.3 over here.
Comment 7 Lars Maes 2013-10-31 12:01:36 UTC
I am using 3.6.19 currently and experience the same problem.. Is there any chance on fixing/workaround?
Comment 8 Vitaliy Filippov 2014-02-21 12:14:57 UTC
We've also faced the same problem, and I've just discovered some ways of fixing it:

1) Set a big 'machine password timeout' in smb.conf to disable refreshing of the machine password. The default value is 604800 = 1 week, and that's what makes krb5.keytab break 1 time a week.

2) Put 'net ads keytab create -P' in your crontab (-P means doing it using the machine account). The problem of this approach is that the command should be ran JUST AFTER samba changes the machine password, and generally speaking, you can't know that time for sure; although you can get the time of last change by looking at the output of 'tdbdump /var/lib/samba/secrets.tdb'. The key is 'SECRETS/MACHINE_LAST_CHANGE_TIME/<your_domain>', the value is binary-encoded UNIX time (for example, "=L\06S") which you can decode for example using: perl -e 'print unpack("L", "=L\06S")'. So if you get the time from there, your cron job should probably run with the interval of 1 week starting at (this time + a couple of seconds).

3) Patch Samba so it refreshes the keytab automatically! :) that's what I'm trying to do now. I'll post the patch after testing.
Comment 9 Vitaliy Filippov 2014-02-25 15:12:19 UTC
Created attachment 9722 [details]
keytab autorefresh patch for 3.6
Comment 10 Vitaliy Filippov 2014-02-25 15:16:43 UTC
Updates on my initial comment:

1) machine password timeout = 0 disables updating of the machine password (and it seems it's OK to disable it, there is no policy that will prevent machine to log on some time)

2) indeed, it seems that it's correct that the only mode in which winbind refresh the machine password is 'kerberos method = secrets only' (but it's still the default). So, setting it to any other value (secrets and keytab, system keytab, dedicated keytab) also fixes the problem.

3) my patch from the previous comment works for me :)
Comment 11 Vitaliy Filippov 2014-06-14 07:33:01 UTC
Created attachment 10032 [details]
Keytab auto-refresh patch for 4.1

Another update - the issue also reproduces on newer versions, for example 4.1.

The patch for 4.1 is in attachment.
Comment 12 Michael Osipov 2014-06-25 10:23:05 UTC
Just hit this as well with 3.6.33 on FreeBSD. This is pita for our SPNEGO-protected HTTP services. I am not really inclined to apply Vitaliy's patches because I have to do this with every single port update.
Comment 13 Vitaliy Filippov 2014-06-25 17:35:19 UTC
I use Debian, and I solved that problem for myself by maintaining a small repository with a patched package :)
Comment 14 Michael Osipov 2014-06-25 18:24:09 UTC
(In reply to comment #13)
> I use Debian, and I solved that problem for myself by maintaining a small
> repository with a patched package :)

This is of course possible but unnecessary overhead.

I followed your tip with the cronjob and SECRETS/MACHINE_LAST_CHANGE_TIME/<your_domain> but it does not seems to work.

When I apply the unpack the string with Perl, I get a date back to 2005 which cannot be true because the AD entry of that machine says: password last set: 2014-06-24 10:34:00

Is there any trap or something else to take care of?