On Fri, Sep 16, 2016 at 6:08 PM, Achim Gottinger via samba <samba at lists.samba.org> wrote:> > > Am 17.09.2016 um 02:36 schrieb Achim Gottinger via samba: >> >> >> >> Am 17.09.2016 um 02:19 schrieb Achim Gottinger via samba: >>> >>> >>> >>> Am 17.09.2016 um 01:23 schrieb Robert Moulton: >>>> >>>> Achim Gottinger via samba wrote on 9/16/16 4:14 PM: >>>>> >>>>> >>>>> >>>>> Am 17.09.2016 um 00:54 schrieb Achim Gottinger via samba: >>>>>> >>>>>> >>>>>> >>>>>> Am 17.09.2016 um 00:29 schrieb Robert Moulton via samba: >>>>>>> >>>>>>> Achim Gottinger via samba wrote on 9/16/16 3:05 PM: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Am 16.09.2016 um 23:00 schrieb Robert Moulton via samba: >>>>>>>>> >>>>>>>>> Rowland Penny via samba wrote on 9/16/16 1:43 PM: >>>>>>>>>> >>>>>>>>>> On Fri, 16 Sep 2016 13:00:52 -0700 >>>>>>>>>> Robert Moulton via samba <samba at lists.samba.org> wrote: >>>>>>>>>> >>>>>>>>>>> Achim Gottinger via samba wrote on 9/15/16 1:20 AM: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Am 15.09.2016 um 09:35 schrieb Rowland Penny via samba: >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, 14 Sep 2016 16:23:27 -0500 >>>>>>>>>>>>> Michael A Weber via samba <samba at lists.samba.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 14, 2016, at 2:00 PM, Achim Gottinger >>>>>>>>>>>>>>> <achim at ag-web.biz> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 14.09.2016 um 20:33 schrieb Michael A Weber: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 14, 2016, at 1:10 PM, Achim Gottinger >>>>>>>>>>>>>>>>> <achim at ag-web.biz >>>>>>>>>>>>>>>>> <mailto:achim at ag-web.biz>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Am 14.09.2016 um 19:53 schrieb Michael A Weber: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Sep 14, 2016, at 12:23 PM, Achim Gottinger via samba >>>>>>>>>>>>>>>>>>> <samba at lists.samba.org <mailto:samba at lists.samba.org>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Am 14.09.2016 um 18:23 schrieb Michael A Weber: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Question though, just for my curiosity: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The encryption algorithms specified after each SPN: I >>>>>>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>>>>>> that aes-256 is listed when I export the user, but not >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> SPN. Are those expected, or have I done something wrong >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> used incorrect algorithms somewhere? I recall reading >>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>> DES is not secure enough and that AES-256 (I think I >>>>>>>>>>>>>>>>>>>> read >>>>>>>>>>>>>>>>>>>> this during TLS enablement) is what should be used. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I get the same behaviour here. If i do nout use the FQDN >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> only the hostname without the domain part the aes keys >>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>> included. In your case --principal HTTP/intranet. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So, now I’m a little more confused. I’ve added the SPN to >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> user without the realm part, which succeeds. I listed it >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> verify, and it’s there (sanitized here): >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> samba-tool spn list web-intranet-macmini >>>>>>>>>>>>>>>>>> web-intranet-macmini >>>>>>>>>>>>>>>>>> User >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> CN=web-intranet-macmini,CN=Users,DC=domain2,DC=domain1,DC=tld >>>>>>>>>>>>>>>>>> has the following servicePrincipalName: >>>>>>>>>>>>>>>>>> HTTP/intranet.domain2.domain1.tld >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Then, if I go to export the keytab as you have indicated >>>>>>>>>>>>>>>>>> above >>>>>>>>>>>>>>>>>> with —principal=HTTP/intranet it errors: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> samba-tool domain exportkeytab ~/intranet-macmini.keytab >>>>>>>>>>>>>>>>>> --principal=HTTP/intranet ERROR(runtime): uncaught >>>>>>>>>>>>>>>>>> exception - >>>>>>>>>>>>>>>>>> Key table entry not found File >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> "/usr/lib64/python2.6/site-packages/samba/netcmd/__init__.py", >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> line 175, in _run return self.run(*args, **kwargs) File >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> "/usr/lib64/python2.6/site-packages/samba/netcmd/domain.py", >>>>>>>>>>>>>>>>>> line 129, in run net.export_keytab(keytab=keytab, >>>>>>>>>>>>>>>>>> principal=principal) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Should that command work? Or, was that for >>>>>>>>>>>>>>>>>> demonstration/explanation purposes only? I’m assuming it >>>>>>>>>>>>>>>>>> worked for you since you referenced my specific case. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I feel I’m missing something. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The encryption methods used can be controlled with net >>>>>>>>>>>>>>>>>>> ads >>>>>>>>>>>>>>>>>>> enctypes. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If i run (after kinit Administrator) >>>>>>>>>>>>>>>>>>> net ads enctypes list dc1$ >>>>>>>>>>>>>>>>>>> i get >>>>>>>>>>>>>>>>>>> 'dc1$' uses "msDS-SupportedEncryptionTypes": 31 >>>>>>>>>>>>>>>>>>> (0x0000001f) >>>>>>>>>>>>>>>>>>> [X] 0x00000001 DES-CBC-CRC >>>>>>>>>>>>>>>>>>> [X] 0x00000002 DES-CBC-MD5 >>>>>>>>>>>>>>>>>>> [X] 0x00000004 RC4-HMAC >>>>>>>>>>>>>>>>>>> [X] 0x00000008 AES128-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>>>>>> [X] 0x00000010 AES256-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I get this as well. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If i use >>>>>>>>>>>>>>>>>>> net ads enctypes list dc1.domain.local$ >>>>>>>>>>>>>>>>>>> i get >>>>>>>>>>>>>>>>>>> no account found with filter: >>>>>>>>>>>>>>>>>>> (&(objectclass=user)(sAMAccountName=dc1.domain.local$)) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Again, I get this as well. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Seems "samba-tool domain exportkeytab" uses an similar >>>>>>>>>>>>>>>>>>> algorythm and therefore does not find the account and >>>>>>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>>>>> des and arcfour keys per default. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> To unsubscribe from this list go to the following URL and >>>>>>>>>>>>>>>>>>> read the instructions: >>>>>>>>>>>>>>>>>>> https://lists.samba.org/mailman/options/samba >>>>>>>>>>>>>>>>>>> <https://lists.samba.org/mailman/options/samba> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Try this >>>>>>>>>>>>>>>>> net ads enctypes set web-intranet-macmini 31 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Afterwards "domain export" will export also aes keys for >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> SPN's. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And, this is why I addressed you as “experts” earlier. >>>>>>>>>>>>>>>> Indeed, >>>>>>>>>>>>>>>> it did! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Now, I’m going to use ktutil to pull these into my existing >>>>>>>>>>>>>>>> keytab on the destination machine and begin my testing. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you tremendously (although I think we may have created >>>>>>>>>>>>>>>> hell for Rowland with the wiki documentation)! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I was wondering about the missing aes keys for an while. So >>>>>>>>>>>>>>> thanks for bringing it up on the list. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If an user gets created the attribute >>>>>>>>>>>>>>> msDS-SupportedEncryptionTypes remains undefined and in this >>>>>>>>>>>>>>> case >>>>>>>>>>>>>>> only des and rc4 keys are exported. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> net ads enctypes set [hostname] [key value] can be used to >>>>>>>>>>>>>>> define >>>>>>>>>>>>>>> the valid keys for an accound (and it's spn's). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The key value is repesented as >>>>>>>>>>>>>>> 0x00000001 DES-CBC-CRC >>>>>>>>>>>>>>> 0x00000002 DES-CBC-MD5 >>>>>>>>>>>>>>> 0x00000004 RC4-HMAC >>>>>>>>>>>>>>> 0x00000008 AES128-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>> 0x00000010 AES256-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>> >>>>>>>>>>>>>> (you mean, 0x00000016, for the last entry) >>>>>>>>>>>>>> >>>>>>>>>>>>>>> So using 31 enables all of them. samba-tool domain >>>>>>>>>>>>>>> exportkeytab >>>>>>>>>>>>>>> does always export des and rc4 keys but honours 0x8 for >>>>>>>>>>>>>>> aes128 >>>>>>>>>>>>>>> and 0x10 for aes256. I assume if enctypes are set to 24 for >>>>>>>>>>>>>>> example (only aes128/256) the server will honour this and >>>>>>>>>>>>>>> decline des and rc4 attempts. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> That’s interesting, indeed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rowland— >>>>>>>>>>>>>> >>>>>>>>>>>>>> This whole thing seems to me like we are duplicating the >>>>>>>>>>>>>> functionality of the ktpass command on a Windows AD. With that >>>>>>>>>>>>>> command, one would need to include an encoding type, and I’m >>>>>>>>>>>>>> just >>>>>>>>>>>>>> wondering if it should be included in the wiki pages as well >>>>>>>>>>>>>> rather than trying to add it back manually after the export. >>>>>>>>>>>>>> Also, something tells me that the ktpass command, when >>>>>>>>>>>>>> creating >>>>>>>>>>>>>> the SPN for a user, also sets the required encoding type. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mike >>>>>>>>>>>>> >>>>>>>>>>>>> The problem is the command 'samba-tool spn add' does just that, >>>>>>>>>>>>> it >>>>>>>>>>>>> only adds the 'servicePrincipalName', no enctypes are >>>>>>>>>>>>> mentioned. >>>>>>>>>>>>> >>>>>>>>>>>>> Exporting the keytab is the same, there is no mention of >>>>>>>>>>>>> enctypes >>>>>>>>>>>>> >>>>>>>>>>>>> So, until this changes, the wiki can only document what >>>>>>>>>>>>> actually >>>>>>>>>>>>> happens. >>>>>>>>>>>>> >>>>>>>>>>>>> Rowland >>>>>>>>>>>>> >>>>>>>>>>>> Hello Rowland, >>>>>>>>>>>> >>>>>>>>>>>> As I wrote before you can use the command >>>>>>>>>>>> >>>>>>>>>>>> net ads enctypes set [username] 31 >>>>>>>>>>>> >>>>>>>>>>>> to convince domain export to export also the aes keys for the >>>>>>>>>>>> SPN's >>>>>>>>>>>> assigned to [username] like it is done for [username]. >>>>>>>>>>>> If only aes keys are wanted in the keytab file unwanted keys can >>>>>>>>>>>> be >>>>>>>>>>>> removed from the keytab file with ktutil. >>>>>>>>>>>> >>>>>>>>>>>> See here for more info about "net ads enctypes" >>>>>>>>>>>> >>>>>>>>>>>> https://www.mail-archive.com/cifs-protocol at lists.samba.org/msg00062.html. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It controls which encryption types are used for ticket >>>>>>>>>>>> generation >>>>>>>>>>>> on the server. >>>>>>>>>>>> >>>>>>>>>>>> achim~ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've been trying to follow this thread but admit I'm still >>>>>>>>>>> missing >>>>>>>>>>> something. Given the example below, what needs to be done to get >>>>>>>>>>> the >>>>>>>>>>> aes keys in the keytab, exactly? >>>>>>>>>>> >>>>>>>>>>> # net ads enctypes list hostname$ >>>>>>>>>>> 'hostname$' uses "msDS-SupportedEncryptionTypes": 31 (0x0000001f) >>>>>>>>>>> [X] 0x00000001 DES-CBC-CRC >>>>>>>>>>> [X] 0x00000002 DES-CBC-MD5 >>>>>>>>>>> [X] 0x00000004 RC4-HMAC >>>>>>>>>>> [X] 0x00000008 AES128-CTS-HMAC-SHA1-96 >>>>>>>>>>> [X] 0x00000010 AES256-CTS-HMAC-SHA1-96 >>>>>>>>>>> >>>>>>>>>>> # samba-tool domain exportkeytab test --principal=hostname$ >>>>>>>>>>> >>>>>>>>>>> # klist -ke test >>>>>>>>>>> Keytab name: FILE:test >>>>>>>>>>> KVNO Principal >>>>>>>>>>> ---- >>>>>>>>>>> >>>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1 hostname$@EXAMPLE.COM (des-cbc-crc) >>>>>>>>>>> 1 hostname$@EXAMPLE.COM (des-cbc-md5) >>>>>>>>>>> 1 hostname$@EXAMPLE.COM (arcfour-hmac) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If I 'kinit Administrator' before running your commands as root on >>>>>>>>>> a >>>>>>>>>> DC, I get this: >>>>>>>>>> >>>>>>>>>> klist -ke devstation.keytab >>>>>>>>>> Keytab name: FILE:devstation.keytab >>>>>>>>>> KVNO Principal >>>>>>>>>> ---- >>>>>>>>>> >>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (arcfour-hmac) >>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (des-cbc-md5) >>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (des-cbc-crc) >>>>>>>>>> >>>>>>>>>> Rowland >>>>>>>>> >>>>>>>>> >>>>>>>>> Yeah, sorry, I should have specified that I did exactly that -- >>>>>>>>> 'kinit >>>>>>>>> Administrator' as root, on a DC -- followed by the sequence of >>>>>>>>> commands I listed. >>>>>>>>> >>>>>>>>> Hm ... would domain/forest functional level matter? we've never >>>>>>>>> bothered to raise ours from the default. >>>>>>>>> >>>>>>>> That's it. On my 4.2.10 server the domain and forest level was 2003 >>>>>>>> so i >>>>>>>> raised it to 2008 R2. Tested with an user account and at first it >>>>>>>> exported only des and rc4 keys. After setting the password for that >>>>>>>> user >>>>>>>> again (what rowland recommended in an other reply) it does now >>>>>>>> export >>>>>>>> aes keys for that user. For an computer account you may have to >>>>>>>> rejoin >>>>>>>> the computer to trigger the generation of an new password for that >>>>>>>> account immediate. >>>>>>>> >>>>>>> >>>>>>> Excellent, thanks. Indeed, it worked for me here, too, on a test >>>>>>> domain. One final (I think/hope) question: How might I deal with >>>>>>> password resets of the DC computer accounts themselves, to trigger >>>>>>> the creation of their AES keys? >>>>>>> >>>>>> The password is changed every 30 days by default if you did not >>>>>> disable it via gpo. >>>>>> >>>>>> https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/ >>>>>> >>>>>> See here how to reset the computer account passwords manualy. >>>>>> >>>>> For the samba dc's you can use >>>>> >>>>> samba-tool user setpassword hostname$ >>>> >>>> >>>> Heh, sheesh, embarrassing ... as easy as that. >>>> >>>> Thanks for your guidance! Rowland, thank you for chiming in as well! >>> >>> Hmm, can be this does mess up replication. >>> >> Yes it does mess up replication! Do not use setpassword for the samba host >> !!! >> Glad I made an snapshot of my test vm before i tried it. >> It worked for an windows 7 client hosever the LDAP and cifs tickets where >> using aes256 > > > Reading https://wiki.samba.org/index.php/Keytab_Extraction > ----- snip ---------------- > Offline Keytab Creation from Secrets.tdb > > If the net command fails (after all, that could be the reason for us to > start sniffing...), you can still generate a keytab without domain admin > credentials, if you can get a hold on the server's secrets.tdb. This method > can also be done offline on a different machine. > > tdbdump secrets.tdb > > Now look for the key SECRETS/MACHINE_PASSWORD/<domain> - the password is the > value without the trailing zero. Use the *ktutil* utility to construct the > keytab: > ------ snap ------------- > > We do not use ktutil but use the password mentioned here for the "samba-tool > user setpassword hostname$" command. > > This does not break replication and the aes keys are exported.Ah, okay, I think I've got it, for my production domain: - step 1: use the above tdbdump trick to identify the existing password - step 2: use samba-tool to "reset" the password to the same value I already reset the password of the single DC in my test domain. Without other DCs in the picture there's effectively no harm done, right? I do have a fairly recent samba_backup dump to use, if necessary.
Am 17.09.2016 um 03:24 schrieb r moulton via samba:> On Fri, Sep 16, 2016 at 6:08 PM, Achim Gottinger via samba > <samba at lists.samba.org> wrote: >> >> Am 17.09.2016 um 02:36 schrieb Achim Gottinger via samba: >>> >>> >>> Am 17.09.2016 um 02:19 schrieb Achim Gottinger via samba: >>>> >>>> >>>> Am 17.09.2016 um 01:23 schrieb Robert Moulton: >>>>> Achim Gottinger via samba wrote on 9/16/16 4:14 PM: >>>>>> >>>>>> >>>>>> Am 17.09.2016 um 00:54 schrieb Achim Gottinger via samba: >>>>>>> >>>>>>> >>>>>>> Am 17.09.2016 um 00:29 schrieb Robert Moulton via samba: >>>>>>>> Achim Gottinger via samba wrote on 9/16/16 3:05 PM: >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 16.09.2016 um 23:00 schrieb Robert Moulton via samba: >>>>>>>>>> Rowland Penny via samba wrote on 9/16/16 1:43 PM: >>>>>>>>>>> On Fri, 16 Sep 2016 13:00:52 -0700 >>>>>>>>>>> Robert Moulton via samba <samba at lists.samba.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Achim Gottinger via samba wrote on 9/15/16 1:20 AM: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Am 15.09.2016 um 09:35 schrieb Rowland Penny via samba: >>>>>>>>>>>>>> On Wed, 14 Sep 2016 16:23:27 -0500 >>>>>>>>>>>>>> Michael A Weber via samba <samba at lists.samba.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sep 14, 2016, at 2:00 PM, Achim Gottinger >>>>>>>>>>>>>>>> <achim at ag-web.biz> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Am 14.09.2016 um 20:33 schrieb Michael A Weber: >>>>>>>>>>>>>>>>>> On Sep 14, 2016, at 1:10 PM, Achim Gottinger >>>>>>>>>>>>>>>>>> <achim at ag-web.biz >>>>>>>>>>>>>>>>>> <mailto:achim at ag-web.biz>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Am 14.09.2016 um 19:53 schrieb Michael A Weber: >>>>>>>>>>>>>>>>>>>> On Sep 14, 2016, at 12:23 PM, Achim Gottinger via samba >>>>>>>>>>>>>>>>>>>> <samba at lists.samba.org <mailto:samba at lists.samba.org>> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Am 14.09.2016 um 18:23 schrieb Michael A Weber: >>>>>>>>>>>>>>>>>>>>> Question though, just for my curiosity: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The encryption algorithms specified after each SPN: I >>>>>>>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>>>>>>> that aes-256 is listed when I export the user, but not >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> SPN. Are those expected, or have I done something wrong >>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> used incorrect algorithms somewhere? I recall reading >>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>> DES is not secure enough and that AES-256 (I think I >>>>>>>>>>>>>>>>>>>>> read >>>>>>>>>>>>>>>>>>>>> this during TLS enablement) is what should be used. >>>>>>>>>>>>>>>>>>>> I get the same behaviour here. If i do nout use the FQDN >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> only the hostname without the domain part the aes keys >>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>> included. In your case --principal HTTP/intranet. >>>>>>>>>>>>>>>>>>> So, now I’m a little more confused. I’ve added the SPN to >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> user without the realm part, which succeeds. I listed it >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> verify, and it’s there (sanitized here): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> samba-tool spn list web-intranet-macmini >>>>>>>>>>>>>>>>>>> web-intranet-macmini >>>>>>>>>>>>>>>>>>> User >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> CN=web-intranet-macmini,CN=Users,DC=domain2,DC=domain1,DC=tld >>>>>>>>>>>>>>>>>>> has the following servicePrincipalName: >>>>>>>>>>>>>>>>>>> HTTP/intranet.domain2.domain1.tld >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Then, if I go to export the keytab as you have indicated >>>>>>>>>>>>>>>>>>> above >>>>>>>>>>>>>>>>>>> with —principal=HTTP/intranet it errors: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> samba-tool domain exportkeytab ~/intranet-macmini.keytab >>>>>>>>>>>>>>>>>>> --principal=HTTP/intranet ERROR(runtime): uncaught >>>>>>>>>>>>>>>>>>> exception - >>>>>>>>>>>>>>>>>>> Key table entry not found File >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> "/usr/lib64/python2.6/site-packages/samba/netcmd/__init__.py", >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> line 175, in _run return self.run(*args, **kwargs) File >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> "/usr/lib64/python2.6/site-packages/samba/netcmd/domain.py", >>>>>>>>>>>>>>>>>>> line 129, in run net.export_keytab(keytab=keytab, >>>>>>>>>>>>>>>>>>> principal=principal) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Should that command work? Or, was that for >>>>>>>>>>>>>>>>>>> demonstration/explanation purposes only? I’m assuming it >>>>>>>>>>>>>>>>>>> worked for you since you referenced my specific case. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I feel I’m missing something. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The encryption methods used can be controlled with net >>>>>>>>>>>>>>>>>>>> ads >>>>>>>>>>>>>>>>>>>> enctypes. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If i run (after kinit Administrator) >>>>>>>>>>>>>>>>>>>> net ads enctypes list dc1$ >>>>>>>>>>>>>>>>>>>> i get >>>>>>>>>>>>>>>>>>>> 'dc1$' uses "msDS-SupportedEncryptionTypes": 31 >>>>>>>>>>>>>>>>>>>> (0x0000001f) >>>>>>>>>>>>>>>>>>>> [X] 0x00000001 DES-CBC-CRC >>>>>>>>>>>>>>>>>>>> [X] 0x00000002 DES-CBC-MD5 >>>>>>>>>>>>>>>>>>>> [X] 0x00000004 RC4-HMAC >>>>>>>>>>>>>>>>>>>> [X] 0x00000008 AES128-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>>>>>>> [X] 0x00000010 AES256-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I get this as well. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If i use >>>>>>>>>>>>>>>>>>>> net ads enctypes list dc1.domain.local$ >>>>>>>>>>>>>>>>>>>> i get >>>>>>>>>>>>>>>>>>>> no account found with filter: >>>>>>>>>>>>>>>>>>>> (&(objectclass=user)(sAMAccountName=dc1.domain.local$)) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Again, I get this as well. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Seems "samba-tool domain exportkeytab" uses an similar >>>>>>>>>>>>>>>>>>>> algorythm and therefore does not find the account and >>>>>>>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>>>>>> des and arcfour keys per default. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> To unsubscribe from this list go to the following URL and >>>>>>>>>>>>>>>>>>>> read the instructions: >>>>>>>>>>>>>>>>>>>> https://lists.samba.org/mailman/options/samba >>>>>>>>>>>>>>>>>>>> <https://lists.samba.org/mailman/options/samba> >>>>>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>>>> Try this >>>>>>>>>>>>>>>>>> net ads enctypes set web-intranet-macmini 31 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Afterwards "domain export" will export also aes keys for >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> SPN's. >>>>>>>>>>>>>>>>> And, this is why I addressed you as “experts” earlier. >>>>>>>>>>>>>>>>> Indeed, >>>>>>>>>>>>>>>>> it did! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Now, I’m going to use ktutil to pull these into my existing >>>>>>>>>>>>>>>>> keytab on the destination machine and begin my testing. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you tremendously (although I think we may have created >>>>>>>>>>>>>>>>> hell for Rowland with the wiki documentation)! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>> I was wondering about the missing aes keys for an while. So >>>>>>>>>>>>>>>> thanks for bringing it up on the list. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If an user gets created the attribute >>>>>>>>>>>>>>>> msDS-SupportedEncryptionTypes remains undefined and in this >>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>> only des and rc4 keys are exported. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> net ads enctypes set [hostname] [key value] can be used to >>>>>>>>>>>>>>>> define >>>>>>>>>>>>>>>> the valid keys for an accound (and it's spn's). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The key value is repesented as >>>>>>>>>>>>>>>> 0x00000001 DES-CBC-CRC >>>>>>>>>>>>>>>> 0x00000002 DES-CBC-MD5 >>>>>>>>>>>>>>>> 0x00000004 RC4-HMAC >>>>>>>>>>>>>>>> 0x00000008 AES128-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>>> 0x00000010 AES256-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>> (you mean, 0x00000016, for the last entry) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So using 31 enables all of them. samba-tool domain >>>>>>>>>>>>>>>> exportkeytab >>>>>>>>>>>>>>>> does always export des and rc4 keys but honours 0x8 for >>>>>>>>>>>>>>>> aes128 >>>>>>>>>>>>>>>> and 0x10 for aes256. I assume if enctypes are set to 24 for >>>>>>>>>>>>>>>> example (only aes128/256) the server will honour this and >>>>>>>>>>>>>>>> decline des and rc4 attempts. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That’s interesting, indeed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Rowland— >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This whole thing seems to me like we are duplicating the >>>>>>>>>>>>>>> functionality of the ktpass command on a Windows AD. With that >>>>>>>>>>>>>>> command, one would need to include an encoding type, and I’m >>>>>>>>>>>>>>> just >>>>>>>>>>>>>>> wondering if it should be included in the wiki pages as well >>>>>>>>>>>>>>> rather than trying to add it back manually after the export. >>>>>>>>>>>>>>> Also, something tells me that the ktpass command, when >>>>>>>>>>>>>>> creating >>>>>>>>>>>>>>> the SPN for a user, also sets the required encoding type. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>> The problem is the command 'samba-tool spn add' does just that, >>>>>>>>>>>>>> it >>>>>>>>>>>>>> only adds the 'servicePrincipalName', no enctypes are >>>>>>>>>>>>>> mentioned. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Exporting the keytab is the same, there is no mention of >>>>>>>>>>>>>> enctypes >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, until this changes, the wiki can only document what >>>>>>>>>>>>>> actually >>>>>>>>>>>>>> happens. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rowland >>>>>>>>>>>>>> >>>>>>>>>>>>> Hello Rowland, >>>>>>>>>>>>> >>>>>>>>>>>>> As I wrote before you can use the command >>>>>>>>>>>>> >>>>>>>>>>>>> net ads enctypes set [username] 31 >>>>>>>>>>>>> >>>>>>>>>>>>> to convince domain export to export also the aes keys for the >>>>>>>>>>>>> SPN's >>>>>>>>>>>>> assigned to [username] like it is done for [username]. >>>>>>>>>>>>> If only aes keys are wanted in the keytab file unwanted keys can >>>>>>>>>>>>> be >>>>>>>>>>>>> removed from the keytab file with ktutil. >>>>>>>>>>>>> >>>>>>>>>>>>> See here for more info about "net ads enctypes" >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.mail-archive.com/cifs-protocol at lists.samba.org/msg00062.html. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It controls which encryption types are used for ticket >>>>>>>>>>>>> generation >>>>>>>>>>>>> on the server. >>>>>>>>>>>>> >>>>>>>>>>>>> achim~ >>>>>>>>>>>> >>>>>>>>>>>> I've been trying to follow this thread but admit I'm still >>>>>>>>>>>> missing >>>>>>>>>>>> something. Given the example below, what needs to be done to get >>>>>>>>>>>> the >>>>>>>>>>>> aes keys in the keytab, exactly? >>>>>>>>>>>> >>>>>>>>>>>> # net ads enctypes list hostname$ >>>>>>>>>>>> 'hostname$' uses "msDS-SupportedEncryptionTypes": 31 (0x0000001f) >>>>>>>>>>>> [X] 0x00000001 DES-CBC-CRC >>>>>>>>>>>> [X] 0x00000002 DES-CBC-MD5 >>>>>>>>>>>> [X] 0x00000004 RC4-HMAC >>>>>>>>>>>> [X] 0x00000008 AES128-CTS-HMAC-SHA1-96 >>>>>>>>>>>> [X] 0x00000010 AES256-CTS-HMAC-SHA1-96 >>>>>>>>>>>> >>>>>>>>>>>> # samba-tool domain exportkeytab test --principal=hostname$ >>>>>>>>>>>> >>>>>>>>>>>> # klist -ke test >>>>>>>>>>>> Keytab name: FILE:test >>>>>>>>>>>> KVNO Principal >>>>>>>>>>>> ---- >>>>>>>>>>>> >>>>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1 hostname$@EXAMPLE.COM (des-cbc-crc) >>>>>>>>>>>> 1 hostname$@EXAMPLE.COM (des-cbc-md5) >>>>>>>>>>>> 1 hostname$@EXAMPLE.COM (arcfour-hmac) >>>>>>>>>>>> >>>>>>>>>>> If I 'kinit Administrator' before running your commands as root on >>>>>>>>>>> a >>>>>>>>>>> DC, I get this: >>>>>>>>>>> >>>>>>>>>>> klist -ke devstation.keytab >>>>>>>>>>> Keytab name: FILE:devstation.keytab >>>>>>>>>>> KVNO Principal >>>>>>>>>>> ---- >>>>>>>>>>> >>>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (arcfour-hmac) >>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (des-cbc-md5) >>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (des-cbc-crc) >>>>>>>>>>> >>>>>>>>>>> Rowland >>>>>>>>>> >>>>>>>>>> Yeah, sorry, I should have specified that I did exactly that -- >>>>>>>>>> 'kinit >>>>>>>>>> Administrator' as root, on a DC -- followed by the sequence of >>>>>>>>>> commands I listed. >>>>>>>>>> >>>>>>>>>> Hm ... would domain/forest functional level matter? we've never >>>>>>>>>> bothered to raise ours from the default. >>>>>>>>>> >>>>>>>>> That's it. On my 4.2.10 server the domain and forest level was 2003 >>>>>>>>> so i >>>>>>>>> raised it to 2008 R2. Tested with an user account and at first it >>>>>>>>> exported only des and rc4 keys. After setting the password for that >>>>>>>>> user >>>>>>>>> again (what rowland recommended in an other reply) it does now >>>>>>>>> export >>>>>>>>> aes keys for that user. For an computer account you may have to >>>>>>>>> rejoin >>>>>>>>> the computer to trigger the generation of an new password for that >>>>>>>>> account immediate. >>>>>>>>> >>>>>>>> Excellent, thanks. Indeed, it worked for me here, too, on a test >>>>>>>> domain. One final (I think/hope) question: How might I deal with >>>>>>>> password resets of the DC computer accounts themselves, to trigger >>>>>>>> the creation of their AES keys? >>>>>>>> >>>>>>> The password is changed every 30 days by default if you did not >>>>>>> disable it via gpo. >>>>>>> >>>>>>> https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/ >>>>>>> >>>>>>> See here how to reset the computer account passwords manualy. >>>>>>> >>>>>> For the samba dc's you can use >>>>>> >>>>>> samba-tool user setpassword hostname$ >>>>> >>>>> Heh, sheesh, embarrassing ... as easy as that. >>>>> >>>>> Thanks for your guidance! Rowland, thank you for chiming in as well! >>>> Hmm, can be this does mess up replication. >>>> >>> Yes it does mess up replication! Do not use setpassword for the samba host >>> !!! >>> Glad I made an snapshot of my test vm before i tried it. >>> It worked for an windows 7 client hosever the LDAP and cifs tickets where >>> using aes256 >> >> Reading https://wiki.samba.org/index.php/Keytab_Extraction >> ----- snip ---------------- >> Offline Keytab Creation from Secrets.tdb >> >> If the net command fails (after all, that could be the reason for us to >> start sniffing...), you can still generate a keytab without domain admin >> credentials, if you can get a hold on the server's secrets.tdb. This method >> can also be done offline on a different machine. >> >> tdbdump secrets.tdb >> >> Now look for the key SECRETS/MACHINE_PASSWORD/<domain> - the password is the >> value without the trailing zero. Use the *ktutil* utility to construct the >> keytab: >> ------ snap ------------- >> >> We do not use ktutil but use the password mentioned here for the "samba-tool >> user setpassword hostname$" command. >> >> This does not break replication and the aes keys are exported. > Ah, okay, I think I've got it, for my production domain: > - step 1: use the above tdbdump trick to identify the existing password > - step 2: use samba-tool to "reset" the password to the same value > > I already reset the password of the single DC in my test domain. > Without other DCs in the picture there's effectively no harm done, > right? I do have a fairly recent samba_backup dump to use, if > necessary. >I tried to set the hosts password to something random and afterwards to the content in secrets.tdb again. Afterwards replication was broken again. The keyfile used for replication seems to be /var/lib/samba/private/secrets.keytab. It can be recreated after the password change with: samba-tool domain exportkeytab secrets.keytab --principal=HOST/server samba-tool domain exportkeytab secrets.keytab --principal=HOST/server.domain.tld samba-tool domain exportkeytab secrets.keytab --principal=SERVER$ With this new secrets.keytab replications started working on my first dc again. But it is broken on the second one. It's abit tricky. :-)
Am 17.09.2016 um 04:53 schrieb Achim Gottinger via samba:> > > Am 17.09.2016 um 03:24 schrieb r moulton via samba: >> On Fri, Sep 16, 2016 at 6:08 PM, Achim Gottinger via samba >> <samba at lists.samba.org> wrote: >>> >>> Am 17.09.2016 um 02:36 schrieb Achim Gottinger via samba: >>>> >>>> >>>> Am 17.09.2016 um 02:19 schrieb Achim Gottinger via samba: >>>>> >>>>> >>>>> Am 17.09.2016 um 01:23 schrieb Robert Moulton: >>>>>> Achim Gottinger via samba wrote on 9/16/16 4:14 PM: >>>>>>> >>>>>>> >>>>>>> Am 17.09.2016 um 00:54 schrieb Achim Gottinger via samba: >>>>>>>> >>>>>>>> >>>>>>>> Am 17.09.2016 um 00:29 schrieb Robert Moulton via samba: >>>>>>>>> Achim Gottinger via samba wrote on 9/16/16 3:05 PM: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am 16.09.2016 um 23:00 schrieb Robert Moulton via samba: >>>>>>>>>>> Rowland Penny via samba wrote on 9/16/16 1:43 PM: >>>>>>>>>>>> On Fri, 16 Sep 2016 13:00:52 -0700 >>>>>>>>>>>> Robert Moulton via samba <samba at lists.samba.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Achim Gottinger via samba wrote on 9/15/16 1:20 AM: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 15.09.2016 um 09:35 schrieb Rowland Penny via samba: >>>>>>>>>>>>>>> On Wed, 14 Sep 2016 16:23:27 -0500 >>>>>>>>>>>>>>> Michael A Weber via samba <samba at lists.samba.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 14, 2016, at 2:00 PM, Achim Gottinger >>>>>>>>>>>>>>>>> <achim at ag-web.biz> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Am 14.09.2016 um 20:33 schrieb Michael A Weber: >>>>>>>>>>>>>>>>>>> On Sep 14, 2016, at 1:10 PM, Achim Gottinger >>>>>>>>>>>>>>>>>>> <achim at ag-web.biz >>>>>>>>>>>>>>>>>>> <mailto:achim at ag-web.biz>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Am 14.09.2016 um 19:53 schrieb Michael A Weber: >>>>>>>>>>>>>>>>>>>>> On Sep 14, 2016, at 12:23 PM, Achim Gottinger via >>>>>>>>>>>>>>>>>>>>> samba >>>>>>>>>>>>>>>>>>>>> <samba at lists.samba.org >>>>>>>>>>>>>>>>>>>>> <mailto:samba at lists.samba.org>> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Am 14.09.2016 um 18:23 schrieb Michael A Weber: >>>>>>>>>>>>>>>>>>>>>> Question though, just for my curiosity: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The encryption algorithms specified after each >>>>>>>>>>>>>>>>>>>>>> SPN: I >>>>>>>>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>>>>>>>> that aes-256 is listed when I export the user, >>>>>>>>>>>>>>>>>>>>>> but not >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> SPN. Are those expected, or have I done >>>>>>>>>>>>>>>>>>>>>> something wrong >>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> used incorrect algorithms somewhere? I recall >>>>>>>>>>>>>>>>>>>>>> reading >>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>> DES is not secure enough and that AES-256 (I think I >>>>>>>>>>>>>>>>>>>>>> read >>>>>>>>>>>>>>>>>>>>>> this during TLS enablement) is what should be used. >>>>>>>>>>>>>>>>>>>>> I get the same behaviour here. If i do nout use >>>>>>>>>>>>>>>>>>>>> the FQDN >>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> only the hostname without the domain part the aes >>>>>>>>>>>>>>>>>>>>> keys >>>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>> included. In your case --principal HTTP/intranet. >>>>>>>>>>>>>>>>>>>> So, now I’m a little more confused. I’ve added the >>>>>>>>>>>>>>>>>>>> SPN to >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> user without the realm part, which succeeds. I >>>>>>>>>>>>>>>>>>>> listed it >>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> verify, and it’s there (sanitized here): >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> samba-tool spn list web-intranet-macmini >>>>>>>>>>>>>>>>>>>> web-intranet-macmini >>>>>>>>>>>>>>>>>>>> User >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> CN=web-intranet-macmini,CN=Users,DC=domain2,DC=domain1,DC=tld >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> has the following servicePrincipalName: >>>>>>>>>>>>>>>>>>>> HTTP/intranet.domain2.domain1.tld >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Then, if I go to export the keytab as you have >>>>>>>>>>>>>>>>>>>> indicated >>>>>>>>>>>>>>>>>>>> above >>>>>>>>>>>>>>>>>>>> with —principal=HTTP/intranet it errors: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> samba-tool domain exportkeytab >>>>>>>>>>>>>>>>>>>> ~/intranet-macmini.keytab >>>>>>>>>>>>>>>>>>>> --principal=HTTP/intranet ERROR(runtime): uncaught >>>>>>>>>>>>>>>>>>>> exception - >>>>>>>>>>>>>>>>>>>> Key table entry not found File >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> "/usr/lib64/python2.6/site-packages/samba/netcmd/__init__.py", >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> line 175, in _run return self.run(*args, **kwargs) >>>>>>>>>>>>>>>>>>>> File >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> "/usr/lib64/python2.6/site-packages/samba/netcmd/domain.py", >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> line 129, in run net.export_keytab(keytab=keytab, >>>>>>>>>>>>>>>>>>>> principal=principal) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Should that command work? Or, was that for >>>>>>>>>>>>>>>>>>>> demonstration/explanation purposes only? I’m >>>>>>>>>>>>>>>>>>>> assuming it >>>>>>>>>>>>>>>>>>>> worked for you since you referenced my specific case. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I feel I’m missing something. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The encryption methods used can be controlled with >>>>>>>>>>>>>>>>>>>>> net >>>>>>>>>>>>>>>>>>>>> ads >>>>>>>>>>>>>>>>>>>>> enctypes. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If i run (after kinit Administrator) >>>>>>>>>>>>>>>>>>>>> net ads enctypes list dc1$ >>>>>>>>>>>>>>>>>>>>> i get >>>>>>>>>>>>>>>>>>>>> 'dc1$' uses "msDS-SupportedEncryptionTypes": 31 >>>>>>>>>>>>>>>>>>>>> (0x0000001f) >>>>>>>>>>>>>>>>>>>>> [X] 0x00000001 DES-CBC-CRC >>>>>>>>>>>>>>>>>>>>> [X] 0x00000002 DES-CBC-MD5 >>>>>>>>>>>>>>>>>>>>> [X] 0x00000004 RC4-HMAC >>>>>>>>>>>>>>>>>>>>> [X] 0x00000008 AES128-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>>>>>>>> [X] 0x00000010 AES256-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I get this as well. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If i use >>>>>>>>>>>>>>>>>>>>> net ads enctypes list dc1.domain.local$ >>>>>>>>>>>>>>>>>>>>> i get >>>>>>>>>>>>>>>>>>>>> no account found with filter: >>>>>>>>>>>>>>>>>>>>> (&(objectclass=user)(sAMAccountName=dc1.domain.local$)) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Again, I get this as well. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Seems "samba-tool domain exportkeytab" uses an >>>>>>>>>>>>>>>>>>>>> similar >>>>>>>>>>>>>>>>>>>>> algorythm and therefore does not find the account and >>>>>>>>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>>>>>>> des and arcfour keys per default. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> To unsubscribe from this list go to the following >>>>>>>>>>>>>>>>>>>>> URL and >>>>>>>>>>>>>>>>>>>>> read the instructions: >>>>>>>>>>>>>>>>>>>>> https://lists.samba.org/mailman/options/samba >>>>>>>>>>>>>>>>>>>>> <https://lists.samba.org/mailman/options/samba> >>>>>>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>>>>> Try this >>>>>>>>>>>>>>>>>>> net ads enctypes set web-intranet-macmini 31 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Afterwards "domain export" will export also aes keys >>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> SPN's. >>>>>>>>>>>>>>>>>> And, this is why I addressed you as “experts” earlier. >>>>>>>>>>>>>>>>>> Indeed, >>>>>>>>>>>>>>>>>> it did! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Now, I’m going to use ktutil to pull these into my >>>>>>>>>>>>>>>>>> existing >>>>>>>>>>>>>>>>>> keytab on the destination machine and begin my testing. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thank you tremendously (although I think we may have >>>>>>>>>>>>>>>>>> created >>>>>>>>>>>>>>>>>> hell for Rowland with the wiki documentation)! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>>> I was wondering about the missing aes keys for an >>>>>>>>>>>>>>>>> while. So >>>>>>>>>>>>>>>>> thanks for bringing it up on the list. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If an user gets created the attribute >>>>>>>>>>>>>>>>> msDS-SupportedEncryptionTypes remains undefined and in >>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>>> only des and rc4 keys are exported. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> net ads enctypes set [hostname] [key value] can be >>>>>>>>>>>>>>>>> used to >>>>>>>>>>>>>>>>> define >>>>>>>>>>>>>>>>> the valid keys for an accound (and it's spn's). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The key value is repesented as >>>>>>>>>>>>>>>>> 0x00000001 DES-CBC-CRC >>>>>>>>>>>>>>>>> 0x00000002 DES-CBC-MD5 >>>>>>>>>>>>>>>>> 0x00000004 RC4-HMAC >>>>>>>>>>>>>>>>> 0x00000008 AES128-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>>>> 0x00000010 AES256-CTS-HMAC-SHA1-96 >>>>>>>>>>>>>>>> (you mean, 0x00000016, for the last entry) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So using 31 enables all of them. samba-tool domain >>>>>>>>>>>>>>>>> exportkeytab >>>>>>>>>>>>>>>>> does always export des and rc4 keys but honours 0x8 for >>>>>>>>>>>>>>>>> aes128 >>>>>>>>>>>>>>>>> and 0x10 for aes256. I assume if enctypes are set to >>>>>>>>>>>>>>>>> 24 for >>>>>>>>>>>>>>>>> example (only aes128/256) the server will honour this and >>>>>>>>>>>>>>>>> decline des and rc4 attempts. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That’s interesting, indeed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Rowland— >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This whole thing seems to me like we are duplicating the >>>>>>>>>>>>>>>> functionality of the ktpass command on a Windows AD. >>>>>>>>>>>>>>>> With that >>>>>>>>>>>>>>>> command, one would need to include an encoding type, >>>>>>>>>>>>>>>> and I’m >>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>> wondering if it should be included in the wiki pages as >>>>>>>>>>>>>>>> well >>>>>>>>>>>>>>>> rather than trying to add it back manually after the >>>>>>>>>>>>>>>> export. >>>>>>>>>>>>>>>> Also, something tells me that the ktpass command, when >>>>>>>>>>>>>>>> creating >>>>>>>>>>>>>>>> the SPN for a user, also sets the required encoding type. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>> The problem is the command 'samba-tool spn add' does >>>>>>>>>>>>>>> just that, >>>>>>>>>>>>>>> it >>>>>>>>>>>>>>> only adds the 'servicePrincipalName', no enctypes are >>>>>>>>>>>>>>> mentioned. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Exporting the keytab is the same, there is no mention of >>>>>>>>>>>>>>> enctypes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, until this changes, the wiki can only document what >>>>>>>>>>>>>>> actually >>>>>>>>>>>>>>> happens. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Rowland >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello Rowland, >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I wrote before you can use the command >>>>>>>>>>>>>> >>>>>>>>>>>>>> net ads enctypes set [username] 31 >>>>>>>>>>>>>> >>>>>>>>>>>>>> to convince domain export to export also the aes keys for >>>>>>>>>>>>>> the >>>>>>>>>>>>>> SPN's >>>>>>>>>>>>>> assigned to [username] like it is done for [username]. >>>>>>>>>>>>>> If only aes keys are wanted in the keytab file unwanted >>>>>>>>>>>>>> keys can >>>>>>>>>>>>>> be >>>>>>>>>>>>>> removed from the keytab file with ktutil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> See here for more info about "net ads enctypes" >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.mail-archive.com/cifs-protocol at lists.samba.org/msg00062.html. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It controls which encryption types are used for ticket >>>>>>>>>>>>>> generation >>>>>>>>>>>>>> on the server. >>>>>>>>>>>>>> >>>>>>>>>>>>>> achim~ >>>>>>>>>>>>> >>>>>>>>>>>>> I've been trying to follow this thread but admit I'm still >>>>>>>>>>>>> missing >>>>>>>>>>>>> something. Given the example below, what needs to be done >>>>>>>>>>>>> to get >>>>>>>>>>>>> the >>>>>>>>>>>>> aes keys in the keytab, exactly? >>>>>>>>>>>>> >>>>>>>>>>>>> # net ads enctypes list hostname$ >>>>>>>>>>>>> 'hostname$' uses "msDS-SupportedEncryptionTypes": 31 >>>>>>>>>>>>> (0x0000001f) >>>>>>>>>>>>> [X] 0x00000001 DES-CBC-CRC >>>>>>>>>>>>> [X] 0x00000002 DES-CBC-MD5 >>>>>>>>>>>>> [X] 0x00000004 RC4-HMAC >>>>>>>>>>>>> [X] 0x00000008 AES128-CTS-HMAC-SHA1-96 >>>>>>>>>>>>> [X] 0x00000010 AES256-CTS-HMAC-SHA1-96 >>>>>>>>>>>>> >>>>>>>>>>>>> # samba-tool domain exportkeytab test --principal=hostname$ >>>>>>>>>>>>> >>>>>>>>>>>>> # klist -ke test >>>>>>>>>>>>> Keytab name: FILE:test >>>>>>>>>>>>> KVNO Principal >>>>>>>>>>>>> ---- >>>>>>>>>>>>> >>>>>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1 hostname$@EXAMPLE.COM (des-cbc-crc) >>>>>>>>>>>>> 1 hostname$@EXAMPLE.COM (des-cbc-md5) >>>>>>>>>>>>> 1 hostname$@EXAMPLE.COM (arcfour-hmac) >>>>>>>>>>>>> >>>>>>>>>>>> If I 'kinit Administrator' before running your commands as >>>>>>>>>>>> root on >>>>>>>>>>>> a >>>>>>>>>>>> DC, I get this: >>>>>>>>>>>> >>>>>>>>>>>> klist -ke devstation.keytab >>>>>>>>>>>> Keytab name: FILE:devstation.keytab >>>>>>>>>>>> KVNO Principal >>>>>>>>>>>> ---- >>>>>>>>>>>> >>>>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (arcfour-hmac) >>>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (aes256-cts-hmac-sha1-96) >>>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (aes128-cts-hmac-sha1-96) >>>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (des-cbc-md5) >>>>>>>>>>>> 1 devstation$@SAMDOM.EXAMPLE.COM (des-cbc-crc) >>>>>>>>>>>> >>>>>>>>>>>> Rowland >>>>>>>>>>> >>>>>>>>>>> Yeah, sorry, I should have specified that I did exactly that -- >>>>>>>>>>> 'kinit >>>>>>>>>>> Administrator' as root, on a DC -- followed by the sequence of >>>>>>>>>>> commands I listed. >>>>>>>>>>> >>>>>>>>>>> Hm ... would domain/forest functional level matter? we've never >>>>>>>>>>> bothered to raise ours from the default. >>>>>>>>>>> >>>>>>>>>> That's it. On my 4.2.10 server the domain and forest level >>>>>>>>>> was 2003 >>>>>>>>>> so i >>>>>>>>>> raised it to 2008 R2. Tested with an user account and at >>>>>>>>>> first it >>>>>>>>>> exported only des and rc4 keys. After setting the password >>>>>>>>>> for that >>>>>>>>>> user >>>>>>>>>> again (what rowland recommended in an other reply) it does now >>>>>>>>>> export >>>>>>>>>> aes keys for that user. For an computer account you may have to >>>>>>>>>> rejoin >>>>>>>>>> the computer to trigger the generation of an new password for >>>>>>>>>> that >>>>>>>>>> account immediate. >>>>>>>>>> >>>>>>>>> Excellent, thanks. Indeed, it worked for me here, too, on a test >>>>>>>>> domain. One final (I think/hope) question: How might I deal with >>>>>>>>> password resets of the DC computer accounts themselves, to >>>>>>>>> trigger >>>>>>>>> the creation of their AES keys? >>>>>>>>> >>>>>>>> The password is changed every 30 days by default if you did not >>>>>>>> disable it via gpo. >>>>>>>> >>>>>>>> https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/ >>>>>>>> >>>>>>>> >>>>>>>> See here how to reset the computer account passwords manualy. >>>>>>>> >>>>>>> For the samba dc's you can use >>>>>>> >>>>>>> samba-tool user setpassword hostname$ >>>>>> >>>>>> Heh, sheesh, embarrassing ... as easy as that. >>>>>> >>>>>> Thanks for your guidance! Rowland, thank you for chiming in as well! >>>>> Hmm, can be this does mess up replication. >>>>> >>>> Yes it does mess up replication! Do not use setpassword for the >>>> samba host >>>> !!! >>>> Glad I made an snapshot of my test vm before i tried it. >>>> It worked for an windows 7 client hosever the LDAP and cifs tickets >>>> where >>>> using aes256 >>> >>> Reading https://wiki.samba.org/index.php/Keytab_Extraction >>> ----- snip ---------------- >>> Offline Keytab Creation from Secrets.tdb >>> >>> If the net command fails (after all, that could be the reason for us to >>> start sniffing...), you can still generate a keytab without domain >>> admin >>> credentials, if you can get a hold on the server's secrets.tdb. This >>> method >>> can also be done offline on a different machine. >>> >>> tdbdump secrets.tdb >>> >>> Now look for the key SECRETS/MACHINE_PASSWORD/<domain> - the >>> password is the >>> value without the trailing zero. Use the *ktutil* utility to >>> construct the >>> keytab: >>> ------ snap ------------- >>> >>> We do not use ktutil but use the password mentioned here for the >>> "samba-tool >>> user setpassword hostname$" command. >>> >>> This does not break replication and the aes keys are exported. >> Ah, okay, I think I've got it, for my production domain: >> - step 1: use the above tdbdump trick to identify the existing >> password >> - step 2: use samba-tool to "reset" the password to the same value >> >> I already reset the password of the single DC in my test domain. >> Without other DCs in the picture there's effectively no harm done, >> right? I do have a fairly recent samba_backup dump to use, if >> necessary. >> > I tried to set the hosts password to something random and afterwards > to the content in secrets.tdb again. Afterwards replication was broken > again. > > The keyfile used for replication seems to be > /var/lib/samba/private/secrets.keytab. > > It can be recreated after the password change with: > > samba-tool domain exportkeytab secrets.keytab --principal=HOST/server > samba-tool domain exportkeytab secrets.keytab > --principal=HOST/server.domain.tld > samba-tool domain exportkeytab secrets.keytab --principal=SERVER$ > > With this new secrets.keytab replications started working on my first > dc again. But it is broken on the second one. > It's abit tricky. :-) >Been having a few other network issues in my test environment. Tried step1/2 on both dc's and things just keep running. After the samba-tool password reset there is usually an WERR_NETNAME-DELETE or similar error which disapers with the next replication. There was no need to recreate the secrets.keytab.