Univention Bugzilla – Bug 42949
samba-tool exports only weak kerberos enctypes for Service Prinicipal Names
Last modified: 2020-07-13 14:30:50 CEST
According to http://sdb.univention.de/1275 we can use the following to export a keytab for an existing kerberos principal: > samba-tool domain exportkeytab /tmp/foobar.keytab --principal "service/foobar@OGR.EXAMPLE.ORG" But then, the keytab contains only weak enctypes: > root@ucs01:~# ktutil -k foobar.keytab list > foobar.keytab: > > Vno Type Principal Aliases > 2 arcfour-hmac-md5 service/foobar@OGR.EXAMPLE.ORG > 2 des-cbc-md5 service/foobar@OGR.EXAMPLE.ORG > 2 des-cbc-crc service/foobar@OGR.EXAMPLE.ORG We do get also AES as enctype if ... a) the account is a regular user (no SPN) b) we use the keytab that was created with "/usr/share/univention-samba4/scripts/create_spn_account.sh": > root@ucs01:~# ktutil -k /var/lib/samba/private/foobar.keytab list > /var/lib/samba/private/foobar.keytab: > > Vno Type Principal Aliases > 2 des-cbc-crc service/foobar@OGR.EXAMPLE.ORG > 2 des-cbc-md5 service/foobar@OGR.EXAMPLE.ORG > 2 arcfour-hmac-md5 service/foobar@OGR.EXAMPLE.ORG > 2 aes128-cts-hmac-sha1-96 service/foobar@OGR.EXAMPLE.ORG > 2 aes256-cts-hmac-sha1-96 service/foobar@OGR.EXAMPLE.ORG The problem with "create_spn_account.sh" is that it only creates the keytab once and cannot be used to export it a second time. The Samba Wiki lists the following command as a solution: > net ads enctypes set <ACCOUNTNAME> But this needs to be run for every single account, afaik. Maybe it is sufficient to add "net ads enctypes set" to "create_spn_account.sh"?
> But then, the keytab contains only weak enctypes Ok, then we probably have to patch the corresponding samba-tool code. > The problem with "create_spn_account.sh" is that it only creates the keytab once and cannot be used to export it a second time. What do you mean by "a second time"? You could copy the file (just kidding). What's the use case? Ticket?
(In reply to Arvid Requate from comment #1) > What do you mean by "a second time"? You could copy the file (just kidding). > What's the use case? Ticket? "create_spn_account.sh" does not tell you where it puts the keytab file. The first assumptiom would be the current working directory just as "samba-tool domain exportkeytab" does, but that's not true. (For the record: it's in /var/lib/samba/private/ ) One can easily get the impression that one needs to export the keytab via samba-tool in any case - that's the "second time" and then the AES enctypes are missing. So what am I asking for? We should avoid a "don't hold it that way"-attitude and make our proposed (SDB) solutions ("samba-tool doman exportkeytab" and "create_spn_account.sh") behave consistently (output all enctypes, tell the file location) regarding the keytab file.
The Enterprise Customer affected flag is set but neither a Ticket number is referenced nor a Customer ID is set. Please set a Ticket number or a Customer ID. Otherwise the Enterprise Customer affected flag will be reset.
Created attachment 9764 [details] support_AES_for_Kerberos_SPNs.patch Here's a fairly trivial patch for the create_spn_account.sh that sets the msDS-SupportedEncryptionTypes attribute to signal the KDC that this service account supports AES. We should add that. As a workaround for existing dns-servcie accounts you may either run kinit Administrator net ads enctypes set "dns-$(hostname)" 31 or use ldb-tools to add the attribute. After that samba-tool will export AES keys too. Probably the Samba KDC will also start issuing tickets with that too. * https://blogs.msdn.microsoft.com/openspecification/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts/ * https://blogs.msdn.microsoft.com/openspecification/2011/05/30/windows-configurations-for-kerberos-supported-encryption-type/
FYI: This is only required for serverPrincipalName, not for userPrincipalName. For UPNs the exported keytab contains also AES keys by default.
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
applied patch to branch : https://git.knut.univention.de/univention/ucs/tree/fvidjaja/42949
patch merged with commit : https://git.knut.univention.de/univention/ucs/commit/dbf9a8f0218b2a9d7c23211456699891395540e5
Ok, you still need to build the package and add an entry to the advisory: ssh dimma and then: repo_admin.py -G git@git.knut.univention.de:univention/ucs.git -b 4.4-0 -P services/univention-samba4 -p univention-samba4 \ -r 4.4-0-0 -s errata4.4-0 b44-scope errata4.4-0 You will find the binary package version in the output header as "Version: ". Add this version string to doc/errata/staging/univention-samba4.inst in the univention/ucs git repository.
Ah, the debian/changelog would have required a new entry to, otherwise you cannot import the new package version into our build system. But: I just experimented with this and I think that we may to do more research here before fixing anything. Also, I think that, if we want to fix this, we should not only add AES capability to new service accounts but also for existing ones. I experimented a bit and this could be done like this: ====================================================== tempfile="$(mktemp)" ldbsearch -H /var/lib/samba/private/secrets.ldb \ samaccountname="dns-$(hostname)" secret \ | sed -n 's/^secret: //p' > "$tempfile" kdestroy kinit --password-file="$tempfile" "dns-$(hostname)" rm "$tempfile" net ads enctypes set "dns-$(hostname)" 31 -k kdestroy ====================================================== We should check what happens, if we do this in a domain with function level less than 2008 R2. So, sorry, please revert the changes in the 4.4-0 branch for now.