Keep the dedicated Samba keytab in sync for FreeIPA-joined systems (mirror the existing AD keytab-refresh job)

Problem/Justification

On TrueNAS SCALE joined to FreeIPA with Samba configured for kerberos method = dedicated keytab (dedicated keytab file /etc/ipa/smb.keytab, internally IPA_SMB_KEYTAB), that keytab is populated only once, at initial join/setup — it is never refreshed afterward. Meanwhile the general system keytab’s host/ and cifs/ principals can get rotated independently (re-join after reboot, IPA-side maintenance, or routine ipa-getkeytab troubleshooting). Kerberos kvno (key version number) is tracked per-principal on the KDC, not per keytab file, so any later rotation of the host/cifs key silently invalidates the copy stored in the dedicated Samba keytab. The result: smbd starts rejecting Kerberos tickets with gss_accept_sec_context failed ... kvno N not found in keytab; keytab is likely out of date in log.smbd, and Kerberos SSO for SMB breaks for every client — with FreeIPA’s NT-hash design, the usual NTLM fallback doesn’t work either, so it’s a hard failure, not just a password prompt.

We confirmed via the middleware source that the existing periodic keytab-check job (check_updated_keytab, hourly @periodic(3600) in kerberos.py) only runs for Active Directory joins (if service_type != 'ACTIVEDIRECTORY': return). There is no equivalent for IPA joins, and nothing keeps IPA_SMB_KEYTAB in sync with the general keytab or with KDC-side kvno changes.

Impact

Any TrueNAS SCALE system joined to FreeIPA with SMB shares can silently lose Kerberos SSO for SMB after any event that rotates the host/cifs key. Since there’s no monitoring or alerting for this, admins typically only find out when users start getting password prompts (or, in FreeIPA’s case, a broken NTLM fallback that never succeeds). This can recur repeatedly and is easy to miss, since the general keytab and directory-services status both look completely healthy while it’s happening. This is directly relevant to Enterprise deployments, since FreeIPA/IdM is a common enterprise directory service and unplanned SMB authentication outages are exactly the kind of production risk this platform is expected to avoid.

User Story

As a TrueNAS SCALE admin running SMB on a FreeIPA-joined system, I want the dedicated Samba keytab to be kept automatically in sync with the current KDC state — or at minimum flagged when it falls out of sync — the same way TrueNAS already checks/refreshes keytabs for Active Directory joins, so that Kerberos SSO for SMB doesn’t silently break every time the host or cifs key rotates.

Suggested approach (for engineering to evaluate): extend the existing periodic keytab-check job to also run for service_type == 'IPA', or add an IPA-specific equivalent; on each directory-services health check / cache refresh, compare the kvno of the cifs/<hostname> principal in the dedicated keytab against the KDC (or against /etc/krb5.keytab, when both exist) and re-fetch via ipa-getkeytab if stale; at minimum, surface a health-check warning similar to the existing certificate-expiry alerts.

Reproduced and documented in detail, including the exact log.smbd signature and a working manual workaround (ipa-getkeytab -s <ipa-server> -p cifs/<hostname> -k /etc/ipa/smb.keytab followed by an SMB service restart) — happy to share more detail if useful.

yeah, this looks like a real gap. The important part is avoiding an automatic key rotation just to refresh the copy. A health check could compare kvno cifs/<hostname> with klist -k /etc/ipa/smb.keytab, then use ipa-getkeytab -r to retrieve the current keys without changing the principal, followed by an SMB restart only when the kvno is stale. Even a warning in Directory Services would be much better than waiting for gss_accept_sec_context failures.