Danke für den Hinweis, das klingt so, als ob die zuvor exportierte Keytab noch keine AES-Keys enthalten hat. Das könnte man mit einem Kommando analog zu ktutil -k old.keytab list verifizieren. Ich vermute, dass dieser Hinweis im UCS 5.0-4 Changelog Abschnitt zu Samba dabei eine Rolle spielt:
- By default allow the KDC to issue services tickets using AES encryption. Prior to UCS 5.0-4, by default Samba only issued service tickets that use the
RC4 cipher (also known as arcfour) as ticket encryption type. This default applies unless a service principal explicitly has msDS-SupportedEncryptionTypes set in the SAM database, which is the case for domain controllers, which explicitly also support AES as ticket encryption type for service tickets, for example for SMB or DCERPC. With UCS 5.0-4, the Samba configuration now additionally supports AES ticket encryption types for service tickets by default. This is controlled by a new Univention Configuration Registry Variable samba/kdc_default_domain_supported_enctypes (Bug #56077).
Durch diese Änderung ist dem durch Samba bereitgestellten Kerberos KDC erlaubt, per Default nicht nur die RC4-Keys zur Erstellung von Tickets zu verwenden, sondern auch AES-Keys, sofern Serivces solche an ihrem Konto gespeichert haben. Letzteres sollte schon seit einigen Releases in UCS der Fall sein. Für den Zugriff auf UCS Samba/AD Domain Controller z.B. ist die Möglichkeit, AES für Kerberos-Tickets zu verwenden, standardmäßig auch schon explizit an ihren Rechnerkonten aktiviert, unabhängig von dieser Änderung in UCS 5.0-4, die andere Services betrifft, bei denen das nicht explizit am Konto aktiviert ist.
Da der Re-export in Ihrem Fall das Problem gelöst hat, vermute ich, dass dadurch jetzt auch die AES-Keys aus der SAM Datenbank, die der KDC als Backend verwendet, in die Datei gespeichert wurden und somit die Hosts mit der neuen Keytab dann in die Lage versetzt wurden, solche Tickets auch zu entschlüsseln und somit den stärken Kryptographie-Algorithmus zu nutzen.
