[Samba] Exporting keytab for SPN failure

Robert Moulton rmoulton at uw.edu
Mon Sep 19 23:14:34 UTC 2016


Achim Gottinger via samba wrote on 9/19/16 9:39 AM:
>
>
> Am 17.09.2016 um 19:35 schrieb Achim Gottinger via samba:
>>
>>
>> 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@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.
>>
> After reading this https://adsecurity.org/?p=483 I tried to change the
> krbtgt passwort using "samba-tool user setpassword krbtgt".
> After that the remianing tickets using rc4 now also use aes256. Also
> running "kinit Administrator; klist -e" show aes256 is used for ticket
> and session encryption now.
>
> Above article mentiones the krbtgt password is changed if the domain
> level is raised from 2003 to 2008 (R2). Seems this is not the case on a
> samba dc otherwise the aes encrypted keys would exist.

I resumed testing today, and I'm sort of lost again. In my test domain, 
if you recall, I had done 'samba-tool user setpassword hostname$' to 
reset the DC password to a new randomly-specified value. Today, I 
noticed that I could no longer log on to a Win 2012 member server in 
that test domain. After trying a few things and reviewing samba logs I 
ended up reverting to a Samba snapshot from a time prior to the date on 
which I started this exercise. All is working now, but I'm back at the 
default Win 2003 functional level. Am I understanding correctly that I 
should adjust the prescribed steps as follows?

  - step 1: raise functional levels to 2008_R2
  - step 2: use the tdbdump trick to identify the existing DC password
  - step 3: use samba-tool to "reset" the DC password to that same value
  - step 4: use samba-tool to reset the krbtgt password to a *new* value



More information about the samba mailing list