[Samba] Exporting keytab for SPN failure

Sat Sep 17 02:53:08 UTC 2016

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. :-)