Bug 42949 - samba-tool exports only weak kerberos enctypes for Service Prinicipal Names
samba-tool exports only weak kerberos enctypes for Service Prinicipal Names
Status: REOPENED
Product: UCS
Classification: Unclassified
Component: Samba4
UCS 4.4
Other Linux
: P5 normal with 1 vote (vote)
: ---
Assigned To: Samba maintainers
Samba maintainers
https://wiki.samba.org/index.php/Gene...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-11-14 15:47 CET by Michael Grandjean
Modified: 2020-07-13 14:30 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.069
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): External feedback
Max CVSS v3 score:
requate: Patch_Available+


Attachments
support_AES_for_Kerberos_SPNs.patch (601 bytes, patch)
2018-11-28 22:08 CET, Arvid Requate
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Grandjean univentionstaff 2016-11-14 15:47:49 CET
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"?
Comment 1 Arvid Requate univentionstaff 2016-11-14 17:42:39 CET
> 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?
Comment 2 Michael Grandjean univentionstaff 2016-11-15 13:09:08 CET
(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.
Comment 3 Stefan Gohmann univentionstaff 2016-12-13 08:10:41 CET
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.
Comment 4 Arvid Requate univentionstaff 2018-11-28 22:08:27 CET
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/
Comment 5 Arvid Requate univentionstaff 2018-11-28 22:16:32 CET
FYI: This is only required for serverPrincipalName, not for userPrincipalName. For UPNs the exported keytab contains also AES keys by default.
Comment 6 Stefan Gohmann univentionstaff 2019-01-03 07:21:48 CET
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.
Comment 7 Fathan Vidjaja univentionstaff 2019-03-26 12:44:52 CET
applied patch to branch : 
https://git.knut.univention.de/univention/ucs/tree/fvidjaja/42949
Comment 8 Fathan Vidjaja univentionstaff 2019-03-26 14:03:49 CET
patch merged with commit :
https://git.knut.univention.de/univention/ucs/commit/dbf9a8f0218b2a9d7c23211456699891395540e5
Comment 9 Arvid Requate univentionstaff 2019-03-26 21:03:18 CET
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.
Comment 10 Arvid Requate univentionstaff 2019-03-26 21:49:26 CET
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.