When joining an AD domain with "net ads join" and smb.conf contains "kerberos method = secrets and keytab", the host keytab /etc/krb5.keytab is being created and a valid host principal of form HOSTNAME$@REALM in included in the file. However, only des-cbc-crc, des-cbc-md5, and arcfour-hmac enctypes are included, no aes256 or aes128 even in AD 2008R2 domain which has full AES support. Aside from weaker security, with the aforementioned three enctypes things like "kinit -k -t /etc/krb5.keytab 'HOSTNAME$@REALM'" fail with the default krb5.conf (default_{tkt,tgs}_enctypes must be adjusted to be able to kinit). "net ads join" should provide AES keys in the host keytab at least optionally if the domain controller supports AES, not only the previously mentioned three types (which are currently hard-coded in the source code).
Created attachment 8019 [details] v4-0-test patch
Created attachment 8020 [details] v3-6-test patch
Can someone please provide a network capture including a keytab file, that shows that smb signing as client (smbclient or winbindd) still works with this?
Comment on attachment 8019 [details] v4-0-test patch LGTM.
Comment on attachment 8020 [details] v3-6-test patch LGTM.
Ok, both these patches (for 4.0.0rc3 and 3.6.next) look good to me. They are exactly the same code that has been added to master. However metze's concern is a valid one, in that once we use these new enctypes we may affect the code that generates the key used for SMB1 and SMB2 signing. With that, can you hold off transferring this bug to Karolin until you have performed a test using smbclient from master connecting to a 4.0.0rc3 and a 3.6.next Samba server using both SMB1 and SMB2 with mandatory signing turned on. This that I'm going to flag this bug as "NEEDINFO" and ask for review from asn@samba.org for both patches. Set them to '+' when you've performed this test and confirmed it all works on. Thanks ! Jeremy.
Looking into this again.
Comment on attachment 8019 [details] v4-0-test patch The first patch is wrong, it adds the aes types at the end, which means the kdc still gives us arcfour-hmac-md5 session keys. See smbclient-krb5-01.pcap.gz If I add it to before ENCTYPE_ARCFOUR_HMAC, we'll get aes session keys
Comment on attachment 8020 [details] v3-6-test patch The first patch is wrong, it adds the aes types at the end, which means the kdc still gives us arcfour-hmac-md5 session keys. See smbclient-krb5-01.pcap.gz If I add it to before ENCTYPE_ARCFOUR_HMAC, we'll get aes session keys
Created attachment 8093 [details] capture that still uses arcfour-hmac-md5
Created attachment 8094 [details] capture that uses aes session keys
Created attachment 8095 [details] keytab to decrypt smbclient-krb5*.pcap
Created attachment 8096 [details] Additional patch for master Andreas or Günther please push this to master after testing with MIT. I just used the builtin heimdal for testing.
Created attachment 8136 [details] Patches for v4-0-test
Created attachment 8137 [details] Patches for v3-6-test
So, we have to remember that Samba 3.6 can't ever be permitted to accept AES tickets, as it doesn't have the new spnego, so things will break. If we are marked as accepting AES on the KDC, this implies support for new SPNEGO. Indeed, this was one of the major motivations for me pushing the gensec changes into the smbd code. That said, writing AES keys into the local keytab when we join with krb5 would give the advantage of being able to use it when we deal with the machine account principal as a client. Having extra keys that are used only in this client case is mostly harmless, and this code changes nothing about what the KDC will create tickets encrypted to.
(In reply to comment #16) > So, we have to remember that Samba 3.6 can't ever be permitted to accept AES > tickets, as it doesn't have the new spnego, so things will break. > > If we are marked as accepting AES on the KDC, this implies support for new > SPNEGO. Indeed, this was one of the major motivations for me pushing the > gensec changes into the smbd code. > > That said, writing AES keys into the local keytab when we join with krb5 would > give the advantage of being able to use it when we deal with the machine > account principal as a client. > > Having extra keys that are used only in this client case is mostly harmless, > and this code changes nothing about what the KDC will create tickets encrypted > to. Please keep in mind that Samba is not the only one who's using the keytab. Remember Heimdal, MIT, JGSS. What is the new SPNEGO? Samba 3.6 does support that as far as I have seen in 'net ads join'.
(In reply to comment #16) > So, we have to remember that Samba 3.6 can't ever be permitted to accept AES > tickets, as it doesn't have the new spnego, so things will break. > > If we are marked as accepting AES on the KDC, this implies support for new > SPNEGO. Indeed, this was one of the major motivations for me pushing the > gensec changes into the smbd code. But that won't happen unless we set the msDS-SupportedEncryptionTypes, correct? We should think about adding that in net ads join for 4.0.x or 4.1. > That said, writing AES keys into the local keytab when we join with krb5 would > give the advantage of being able to use it when we deal with the machine > account principal as a client. > > Having extra keys that are used only in this client case is mostly harmless, > and this code changes nothing about what the KDC will create tickets encrypted > to. This patches are mostly for the client side. At lease we should include them in v4-0-test.
Comment on attachment 8137 [details] Patches for v3-6-test Looks good, I tested this with a 64bit win7 client in a w2k8r2 domain against a 3.6.9 samba server including this patch. I tested both, with and without a manual "msDS-SupportedEncryptionTypes: 31" value on the samba machine account, also with smb signing enforced and not enforced. It all worked and used a 32bit AES session key then.
Comment on attachment 8136 [details] Patches for v4-0-test Looks good, just like the 3.6 variant.
Karolin, please pick this for v4-0-test
(In reply to comment #21) > Karolin, please pick this for v4-0-test Pushed to v3-6-test and autobuild-v4-0-test.
Pushed to v4-0-test. Closing out bug report. Thanks!
Patchset not covering all issues, in 3.6 at least.
Created attachment 8188 [details] patch for 3.6.x
Comment on attachment 8188 [details] patch for 3.6.x In the 3rd patch you should add the new types before ENCTYPE_ARCFOUR_HMAC. We should keep them ordered by priority. Otherwise this looks good
Created attachment 8189 [details] fixed patch for 3.6.x
Comment on attachment 8189 [details] fixed patch for 3.6.x Looks good
Karolin, please pick this to 3.6
(In reply to comment #29) > Karolin, please pick this to 3.6 Pushed to v3-6-test. Closing out bug report. Thanks!