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.
Am 17.09.2016 um 06:14 schrieb Achim Gottinger via samba:> > > 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. >There is still one difference when comparing an upgrade domain with an fresh installed domain. On the upgraded domain (raised function level, regenerated dc keys) when in run klist on an connected windows client (password reset was done with the netdom command) there are still two tickets using rc4 encryption. #0 krbtgt/DOMAIN.TLD at DOMAIN.TLD - ticket and session encryption RC4 #1 krbtgt/DOMAIN.TLD at DOMAIN.TLD - ticket encryption RC4 and session encryption AES256 These keys use only AES256 on my 4.4.5 test environment which ran on 2008 R2 level all the time. So there must be an domain account whoms keys must also be regenerated. I have no idea how to reset that.
Am 17.09.2016 um 17:07 schrieb Achim Gottinger via samba:> > > Am 17.09.2016 um 06:14 schrieb Achim Gottinger via samba: >> >> >> 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. >> > There is still one difference when comparing an upgrade domain with an > fresh installed domain. > On the upgraded domain (raised function level, regenerated dc keys) > when in run klist on an connected windows client (password reset was > done with the netdom command) there are still two tickets using rc4 > encryption. > #0 krbtgt/DOMAIN.TLD at DOMAIN.TLD - ticket and session encryption RC4 > #1 krbtgt/DOMAIN.TLD at DOMAIN.TLD - ticket encryption RC4 and session > encryption AES256 > These keys use only AES256 on my 4.4.5 test environment which ran on > 2008 R2 level all the time. > So there must be an domain account whoms keys must also be > regenerated. I have no idea how to reset that.Just to be sure i added an third dc (different site and subnet) and reset this dc's password using the one storde on that dc in secrets.tdb. This also worked. Here is the error message which appears once during replication afterwards. DC=DomainDnsZones,DC=domain,DC=tld MUC\DC3 via RPC DSA object GUID: [GUID] Last attempt @ Sat Sep 17 19:26:59 2016 CEST failed, result 64 (WERR_NETNAME_DELETED) 1 consecutive failure(s). Last success @ Sat Sep 17 19:25:44 2016 CEST This error propagates from dc2 to dc1 to dc3 back to dc1 and back to dc3 then it is gone.