[Samba] Does anyone know how to completely remove the Computer SID of a Demoted DC?

[Zombie Ryushu]

On 1/5/23 08:10, Rowland Penny via samba wrote:
>
>
> On 05/01/2023 12:19, Zombie Ryushu via samba wrote:
>> On 1/5/23 06:22, Rowland Penny via samba wrote:
>>>
>>>
>>> On 05/01/2023 10:20, Zombie Ryushu via samba wrote:
>>>> Does anyone know how to completely remove the Computer SID of a 
>>>> Demoted DC? As in, another DC has taken it's place, the system is 
>>>> down and offline, but if it rejoins, it will not get the SID entry 
>>>> it had before?
>>>>
>>>
>>>
>>> Samba-tool domain demote --remove-other-dead-server=DEAD_SERVER
>>>
>>> Rowland
>>>
>> tdb> open /var/lib/samba/private/secrets.tdb
>> tdb> list
>> hash=31
>> rec: hash=31 offset=0x0000ccc8 next=0x00000000 rec_len=116 key_len=20 
>> data_len=68 full_hash=0x6344070e magic=0x26011999
>> hash=40
>> rec: hash=40 offset=0x0000cc48 next=0x00000000 rec_len=104 key_len=12 
>> data_len=68 full_hash=0x2a4c7c2e magic=0x26011999
>> hash=81
>> rec: hash=81 offset=0x0000cb48 next=0x00000000 rec_len=48 key_len=28 
>> data_len=5 full_hash=0x04693e9d magic=0x26011999
>> hash=91
>> rec: hash=91 offset=0x0000cb90 next=0x00000000 rec_len=56 key_len=24 
>> data_len=16 full_hash=0xeeca574e magic=0x26011999
>> hash=102
>> rec: hash=102 offset=0x0000cdfc next=0x00000000 rec_len=492 
>> key_len=33 data_len=355 full_hash=0xde81724e magic=0x26011999
>> hash=117
>> rec: hash=117 offset=0x0000cbe0 next=0x0000cda8 rec_len=80 key_len=35 
>> data_len=25 full_hash=0xab4cc893 magic=0x26011999
>> rec: hash=117 offset=0x0000cda8 next=0x00000000 rec_len=60 key_len=41 
>> data_len=4 full_hash=0xd7d62837 magic=0x26011999
>> hash=126
>> rec: hash=126 offset=0x0000cd54 next=0x00000000 rec_len=60 key_len=41 
>> data_len=4 full_hash=0x4ff35197 magic=0x26011999
>> freelist:
>> hash=-1
>> rec: hash=-1 offset=0x000002b8 next=0x00000000 rec_len=51320 
>> key_len=0 data_len=0 full_hash=0x00000000 magic=0xd9fee666
>> tdb> quit
>>
>> One of these entries appears to be a duplicate. Is it the case that 
>> hash=117 is a duplicate?
>
> What has any of that got to do with your original question ??
>
> Why are you even looking in secrets.ldb ??
>
> Why can you not open your own thread for each question ??
>
> I knew it was a mistake answering you.
>
> Rowland
>
I'm sorry I did not provide enough context.

I have demoted and re-promoted a particular DC on several occasions to 
deal with a SID Corruption issue. (this is an issue from months ago, and 
I largely worked around the problem, but now, its being an issue again. 
Each time I demote and re-promote the DC it gets the same SID, and in 
turn, I get the same corruption issue.

I was pouring  though older posts on the mailing list, and found someone 
who was in a similar situation. He said that in his repeated demotion 
and re-promotion of his DC to fix the problem, he found that secrets.tdb 
contained multiple entries for his affected DC,

Here is a copy paste:

Hi Rowland,

after we solved the puzzle today here is what we found:
The Samba PDC with tdbsam backend was installed a loooooong time ago.
Many updates and distributions later, the Samba PDC was still running
with with the same databases and the same smb.conf. The only thing that
someone sometime changed was the hostname and the NetBIOS-Name in
smb.conf. BUT in secrets.tdb was still the old name. Then they used the
iso-8859-15 codepage and  there were som "fullname"-entries wit "ä" "ö"
and "ü". Then there were some local users in passwd-file with the same
ID an name as AD-BUILDIN-Accounts. So with all these funny things it was
hard to get things running. After we saw the errormessage from
"samba-tool dbcheck" I try to let samba-tool fix the problem, but it
didn't worked. Then I try to rebuild the index-dbs and that was the
point where we found the users with "ä" "ö" and"ü". Because of the
character translation there was a lot of garbage inside the AD-database.
So we had set up a new samba-PDC with the original name, so we got a new
clean secrets.tdb. Then we copied the backup from all *.tdb-files to the
new PDC. So that we had an clean running PDC. Then we changed the
"fullname"-entries with "pdbedit" copied alle files to the first AD and
did the classicupgrade. The we found out, that the sysvol-share had the
wrong group set. I went to all the Objects and I found out, that the
group "BUILDIN\administrators" had a ObjectClass PosixAccount and a
GidNumber. With ldbedit I removed the ObjectClass and the GidNumber. Did
a "net chache flush" reseted the permissions and everything was fine.
Now we had a nice running first ADDC, then we installed and joined the
second ADDC, and replication is working and we are happy.
And YES we are using Louis 4.7 packages.
HELLLLOOOOOOOO LOOOUUUIIISSSS thanks for the work :-)

Stefan

This sounded similar to my situation.