[Samba] Exporting keytab for SPN failure

Fri Sep 16 22:29:28 UTC 2016

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?