The Samba-Bugzilla – Bug 6750
After 'machine password timeout' /etc/krb5.keytab is not updated
Last modified: 2018-09-07 14:04:47 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.
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.
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.
reassigning to günther...
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
Planning to finally fix this for 3.6.x
(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.
I am using 3.6.19 currently and experience the same problem.. Is there any chance on fixing/workaround?
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.
Created attachment 9722 [details]
keytab autorefresh patch for 3.6
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 :)
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.
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.
I use Debian, and I solved that problem for myself by maintaining a small repository with a patched package :)
(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?