[Samba] Exporting keytab for SPN failure
Robert Moulton
rmoulton at uw.edu
Mon Sep 19 23:55:49 UTC 2016
Achim Gottinger via samba wrote on 9/19/16 4:42 PM:
>
>
> Am 20.09.2016 um 01:14 schrieb Robert Moulton via samba:
>> 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
>>
> Yes these where the steps I used here. Using an random password (not the
> one from secrets.tdb) also resulted in an broken dc for me. Make sure
> you do not include the trailing \00 used in the password field in
> secrets.tdb!
>
Okay, thanks. And you read my mind; I'd been meaning to ask for
clarification on those samba wiki instructions: "the password is the
value without the trailing zero" (singular, with no mention of the
preceding '\').
More information about the samba
mailing list