Object with Identity '123456' has not been found

[jku-sr]

ntds.dit and hklm/system is from is from windows 2008 server

I'm running this using v3.4 on Windows 10 1803

Get-ADDBAccount : Object with identity '35344' has not been found. At line:1 char:1

• Get-ADDBAccount -All -DBPath 'C:\temp\ntds.dit' -BootKey $key

• 
  + CategoryInfo          : NotSpecified: (:) [Get-ADDBAccount], DirectoryObjectNotFoundException
  + FullyQualifiedErrorId : DSInternals.Common.Exceptions.DirectoryObjectNotFoundException,DSInternals.PowerShell.Co
  mmands.GetADDBAccountCommand

[MichaelGrafnetter]

Hi, thanks for reporting. Could you please submit the entire exception stack trace?

$Error[0].Exception.StackTrace

Did you perform DB defragmentation on Windows 10 before opening it?

[jku-sr]

Yes I peformed a "esentutl /p .\ntds.dit /8 /o" first since ntds.dit was in a corrupted state.

$Error[0].Exception.StackTrace

at DSInternals.DataStore.DistinguishedNameResolver.Resolve(Int32 dnTag) in D:\a\1\s\Src\DSInternals.DataStore\DistinguishedNameResolver.cs:line 74 at DSInternals.DataStore.DatastoreObject.get_DistinguishedName() in D:\a\1\s\Src\DSInternals.DataStore\DatastoreObject.cs:line 25 at DSInternals.Common.Data.DSAccount.LoadAccountInfo(DirectoryObject dsObject) at DSInternals.Common.Data.DSAccount..ctor(DirectoryObject dsObject, DirectorySecretDecryptor pek) at DSInternals.DataStore.DirectoryAgent.d__9.MoveNext() in D:\a\1\s\Src\DSInternals.DataStore\DirectoryAgent.cs:line 77 at DSInternals.PowerShell.Commands.GetADDBAccountCommand.ReturnAllAccounts(Byte[] bootKey) at System.Management.Automation.CommandProcessor.ProcessRecord()

When we run this simplified command Get-ADDBAccount -All -DBPath 'ntds.dit' -BootKey $key

I also get the same "Object with Identity 'xxxxx' has not been found" after it's done listing out some hashes.

[MichaelGrafnetter]

Thanks. Well, this is strange. The Get-ADDBAccount cmdlet failed to resolve the distinguished name of one of the user accounts (identified by DN tag 35344), while it succeeded with others. This might mean:

• A bug in DSInternals
• Inconsistent database
• Corrupted index

It is hard to tell which is true without having access to the DB. Does it come from a production or a test environment? Are you able to reproduce this error on a DB originating from another DC from that same domain?

I wonder how much time you have for troubleshooting. The account causing the issue can be pinpointed using the DIT Snapshot Viewer tool. If you open the ntds.dit file in it and go to the datatable table, you should see a column called DNT_col. Row with DNT_col=35344 is causing the issue. In the first column, you should see its RDN (CN=...). And the value in the PDNT_col should be pointing to the DNT_col of its parent object (probably an organizational unit). Could you please try to resolve the entire DN chain by hand and check that it ends with the $ROOT_OBJECT$? Is that object special in any way?

[jku-sr]

the object is a computer object. what is interesting is it's PDNT_COL has a value higher than the list of available DNT_COL my DNT_COL the highest the value goes is 43810. However the PDNT_COL has a value of 48414

what's more interesting is this computer object exists twice in this table. This second value's PDNT_col value does look right as it's parent is my Domain Name.

how do i delete this 35344 value so the script doesn't error out when it reaches this object?

[MichaelGrafnetter]

Strange, thanks for the effort. That really points to a corrupted ntds.dit (e.g. power outage, inconsistent snapshot, missing transaction logs or truncated DB). How did you create the snapshot? Did you also copy the transaction logs together with ntds.dit?

The database might also have been corrupted by esentutl /p, which is a drastic operation and sometimes leads to irreversible DB truncation. Have you tried esentutl /d instead?

If that does not help, could you please double-click that object in DIT Snapshot Viewer and check to see any suspicious stuff? You should also see the OBJECT_GUID attribute. Please note its Interpreted Value. You can then try to use the Remove-ADDBObject cmdlet to delete the record. You should definitely create a backup of the DB before doing this operation. Success is not guaranteed.

[jku-sr]

i did the volume shadow copy route to get the ntds.dit file. I did not copy the log file with it. I'll give that a try again with the log files this time.

[jku-sr]

that was the key! I had to copy the transaction logs together with ntds.dit file. the esentutl /d command didn't work as the NTDS.dit file was in a corrupted state. I had to go with the repair esentutl /p command in order to commit the logs to file and now when I run the cmdlet everything works and I was able to use the Test-PasswordQualitycmdlet against HIBP ntlm hash successfully.

Thanks for your help! I now have lot's of weak passwords to address.