regenerating secrets.keytab
Matthieu Patou
mat at samba.org
Fri Sep 3 11:24:30 MDT 2010
"Aaron Solochek" <aarons-samba at aberrant.org> wrote:
>On 9/3/2010 9:25 AM, Aaron Solochek wrote:
>> On 09/03/2010 01:11 AM, Matthieu Patou wrote:
>>>
>>>
>>> "Andrew Bartlett" <abartlet at samba.org> wrote:
>>>
>>>> On Thu, 2010-09-02 at 18:17 -0400, Aaron Solochek wrote:
>>>>> On 09/02/2010 06:11 PM, Andrew Bartlett wrote:
>>>>>> On Thu, 2010-09-02 at 18:02 -0400, Aaron Solochek wrote:
>>>>>>> On 09/02/2010 05:12 PM, Andrew Bartlett wrote:
>>>>>>>> On Thu, 2010-09-02 at 16:29 -0400, Aaron Solochek wrote:
>>>>>>>>> I'm not sure how, but my secrets.keytab is messed up. My PDC running
>>>>>>>>> samba4 is named FOO, and secrets.keytab contains 4 keys for FOO with
>>>>>>>>> kvno 1. When I run samba with -d1, I was seeing this:
>>>>>>>>>
>>>>>>>>> Failed to find FOO$@BAR.COM(kvno 6) in keytab
>>>>>>>>> FILE:/usr/local/samba/private/secrets.keytab (arcfour-hmac-md5)
>>>>>>>>>
>>>>>>>>> Since I couldn't figure out how to make the keytab and ldb agree, I
>>>>>>>>> hacked the keytab to set kvno =6. Unsurprisingly that doesn't result in
>>>>>>>>> a valid keytab, so now I'm just getting decrypt integrity check errors.
>>>>>>>>>
>>>>>>>>> How can I fix this without wiping everything and starting over?
>>>>>>>>
>>>>>>>> I would run an upgradeprovision. It will reset both passwords,
>>>>>>>> hopefully getting everything right again in the process.
>>>>>>>>
>>>>>>>> We could potentially split out the password changing aspect of this into
>>>>>>>> another helper script, or put in the periodic password changing, but for
>>>>>>>> now that's the best option.
>>>>>>>>
>>>>>>>
>>>>>>> This sounds good, however, I am getting these errors:
>>>>>>>
>>>>>>> A transaction is still active in ldb context [0x2968680] on
>>>>>>> /usr/local/samba/private/sam.ldb
>>>>>>> A transaction is still active in ldb context [0x3d74120] on
>>>>>>> /usr/local/samba/private/idmap.ldb
>>>>>>> A transaction is still active in ldb context [0x3023060] on
>>>>>>> /usr/local/samba/private/secrets.ldb
>>>>>>> A transaction is still active in ldb context [0x40ce300] on
>>>>>>> /usr/local/samba/private/privilege.ldb
>>>>>>>
>>> This is sent by upgradeprovision when something really unexpected happened ... send the full output.
>>
>>
>> That was the full output. I turned on debugging and the problem was that it was:
>>
>> IOError: [Errno 2] No such file or directory:
>> '/usr/share/samba/setup/provision.smb.conf.dc'
>>
>> indeed, my setup was located at the default /usr/local/samba/share/setup
>>
>> I would suggest that the script check the default, and also that the actual
>> error get reported even if --debugall and -d2 aren't specified (I don't know
>> which actually enabled that error to show up).
>>
>> But anyway it looks like it specifying the setup directory solved my problem,
>> and I really should have checked the debugging output myself, so I apologize for
>> that.
>>
>> Thanks for the help.
>>
>> -Aaron
>
>
>Perhaps I spoke too soon. The upgradeprovision did solve the problem of
>me being unable to join a computer to the domain, and things are no
>longer _completely_ broken, but when I run samba in debug mode I am
>still seeing lots of these:
>
>GSS Update(krb5)(1) Update failed: Miscellaneous failure (see text):
>Failed to find FOO$@BAR.COM(kvno 6) in keytab
>FILE:/usr/local/samba/private/secrets.keytab (arcfour-hmac-md5)
>
>or
>
>GSS Update(krb5)(1) Update failed: Miscellaneous failure (see text):
>Failed to find FOO$@BAR.COM(kvno 1) in keytab
>FILE:/usr/local/samba/private/secrets.keytab (arcfour-hmac-md5)
>
>So it seems that somewhere something is still trying to authenticate
>with old versions of those keys. Would this be client machines with
>stale tickets or something?
Only wireshark trace will tell us capture port 88. Btw i have this kind errors and don't see any special pb.
Matthieu.
Matthieu Patou
Samba team
More information about the samba-technical
mailing list