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?
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