When winbind rotates the secrets in Active Directory either via planned rotation or by manually calling the command "wbinfo --change-secret", the KVNO in system keytab at /etc/krb5.keytab and the AD attribute msDS-KeyVersionNumber are not set correctly. It looks like the KVNO in the system keytab always lags one increment behind (eg, where Active Directory reports msDS-KeyVersionNumber = 18, the system keytab have at maximum KVNO 17). I'm using the defaults of secrets only and sync machine password to keytab = /etc/krb5.keytab:spn_prefixes=host:account_name:sync_spns:sync_kvno:machine_password The workaround is to join the machine again (e.g. by using realmd and --do-not-touch-config option), until winbind does rotate the keytab again. The environment is a standard Windows Server 2022 AD DS with 2016 Functional Level.
Hi Luca, can you please set "log level = 10", reproduce it and attach /var/log/samba/log.w* log files?
Hello Pavel, while I was trying to reproduce the bug for you I noticed that now it's rotating the secrets and settings msDS-KeyVersionNumber coherently. I'm using version 4.22.2, that was upgraded from 4.22.1 on 2025-06-12. Now that I think about it, I didn't have to reapply the workaround stated in the bug report this month. It seems that it is behaving correctly. Except patching it I didn't touch it and I could reproduce it consistently. I see that in the 4.22.2 release you fixed "BUG 15727: net ad join fails with "Failed to join domain: failed to create kerberos keytab"."; could this be related? Thank you, Luca
Hello Luca, It is not not very likely that it was caused by https://bugzilla.samba.org/show_bug.cgi?id=15727 . In such case, there would be error message: pw2kt_process_add_info: Failed to parse principal Probably there was some inconsistent state between winbind and Windows DC, that was cleared during the update. I will close the bug for now. Please re-open if it happens again. Thank you, Pavel
We have this issue on 4.21.7, where we have kerberos method = secrets only sync machine password to keytab = "/etc/krb5.keytab:account_name:sync_spns:spn_prefixes=host:sync_kvno:machine_password" This should be correct, I believe. But from the attached we see if I force password update the keytab is re-written as seen from the timestamp on the file, but the KVNO isn't upped. In this example AD shows msDS-KeyVersionNumber: 28, but this doesn't appear in the file. This is intermittent, when this does succeeded the highest KVNO in the keytab will jump by 2 (it catches up), and SSH GSSAPI will work again. It's like (in theory) the password change is applied to one DC and then the keytab is read or data (kvno?) for it is read from another DC? And sometimes, when successful, it either gets keytab data from the same dc it wrote to or replication just happened fast enough or something like that? These are just theories, does this seem possible from the code?
Created attachment 18699 [details] Output ktutil of manual password change