Bug 6750 - After 'machine password timeout' /etc/krb5.keytab is not updated
Summary: After 'machine password timeout' /etc/krb5.keytab is not updated
Status: RESOLVED FIXED
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
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-21 16:25 UTC by Jason Gunthorpe
Modified: 2024-07-26 20:28 UTC (History)
9 users (show)

See Also:


Attachments
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?
Comment 15 Samba QA Contact 2024-07-26 18:17:05 UTC
This bug was referenced in samba master:

3de8d2941529af5a89069bd8e0caed0bcb508869
731a25b5c80690609b4ed5523cea3a098e42de28
09c302995826a8c54fce97b60e4bab98aec472c0
27ca58f9bf14fcdc834869fad5631fca9e1c4652
1185b03b275a093a6dda84fc7d8cf3b983c9a07f
b007fb89d59e275a82e717ea33c264d52f6899ba
f3ff6871197f9b3aef58804c07328ecf4feec5fe
da622ccc16413c3020dd314ba50f9c1a0317824d
49d09906890dbd864de155cfdb90e96527fc478e
7c65aa8c7bc1cd3e0da1621c24ccfeaa0c4d4a53
683f6eec40f2efbb122329800ebb2f5d2f518746
eeb79875c6edc82bfcaa8ed5d0eade77d64f7e8d
253625dabf8c1e736820c4dc5c1f5d170d960574
aff928268adf66df029a126814ac3fad7262eacb
90ec8adf1f2ef8ec25ea67c066fec7f731bbb4dc
d18babd1d70cec47889b6426a63275a1b8ceecd7
18aedcc84c873ab649accab42ad5ee19727ae4cb
2304d96db328da2c6481cee9d22cfed66374187a
abbf926067be41db11ed1cac4027e59d030db8ac
ad6a91ba745304fe53ae5d0faf4f00c25d027877
c10c49b3f00f7da2319d59b707a8c9d2acefc172
f819ad25027e3b9c2fd46d57bd1a830af678b42c
e08b2963d98ea82cb5989f5e7c80e808859e98dd
1fcaf066f42cf01c6978416e99b132fdbb1f55de
bf13d9b3ef76a0d017fa7d81069f1d9da117de41
fb0c2774ca75d076994452a037e2dd3609383e04
c76727b3c77bece515064c2948e01919501367b7
be29fe50adb8732d5ddaceffe12a284f7a25f296
6a97f8e16d888ac16069dcccccb81541520f6e5e
e61f53b656f074a80ae66dfda776b56b03cc9918