A while back I was asked about an issue with a migrated domain controller . The issue was that one of the migrated domaincontrollers no longer could talk to the others. My initial suspicion was that the computer account on that domain controller was changed.
When we looked in the Active Directory, all seemed fine. The date of the last password update on that AD object was the same on all server. But the issue was there. I suspect that the sending party not stop the machine but did a snapshot and send the image to us. And that the machine changed changed its secret during the migration window. The timestamp on the object was close enough that decided to call that this was the case.
Sorting it out.
nltest /SC_RESET to force the machine password to be correct against the Active Directory.
Then the machine came back and everyone was happy and I was reassigned.
BUT I really hope they looked into the possiblity of SID being reused due to going back in time.
But, we only reset it.
I would like that the next time I can actually prove what happened, instead of me doing an educated guess.
So lets dig into that.
For another blog article I was looking into the local SID.
That part was protected in the
Security part of the registry.
Doing it manually.
- First of we need to get access.
Lets use psexec64.exe to achieve
SYSTEMlevel access. The command you are looking for is
psexec64 -sid cmd.exe. Now that we are
- Lets get the time
reg query HKLM\SECURITY\Policy\Secrets\$MACHINE.ACC\OupdTime.
- Since my system is a little Endian system, we need to reverse the octets to get the value.
- After reordering the values we convert from hex to dec.
- Then just use
w32tmto convert from filetime to normal datetime.
w32tm /ntte 132782615805693462will return the date.
Automating it with Powershell
You still need to become system first. But then we can let Powershell do all the heavy lifting.
$MachinePasswordLastSet=(Get-ItemProperty -Path 'HKLM:\SECURITY\Policy\Secrets\$MACHINE.ACC\OupdTime').'(default)' $filetime=[bitconverter]::ToUInt64($MachinePasswordLastSet, 0) [System.DateTime]::FromFileTime($filetime)
So lets run the automation and then force a change of the secure channel.
You can force a change
nltest /SC_CHANGE_PWD:%USERDNSDOMAIN%, okey I know this requires that the user is in the same domain.
I made the Powershell a one liner, but I feel for readability it is better to have it on more row when sharing it.
How can we use it
We can compare to the date on the machine and the Active Directory. So next time we can prove it.
Also if you are going to migrate stuff. Make sure domain controllers are turned off. No half assing it.