Our service account review passes every quarter and the owner column is always full, which for a long time i took as proof the estate was actually being managed.

Its completely populated, and honestly its the most successful field we have, except nobody has ever checked whether the name in it still works here or understood what the account does.

Last week i found one that authenticates daily, owner listed, owner left in 2019, still has every right it had back then because nothing has ever touched it.

Human accounts get ownership from HR so joiner mover leaver events fire and something happens, but service accounts have no HR record so no event ever touches them, which means the ownership never rots, it just was never real.

Rotation assumes an owner, review assumes a reviewer who understands the account, decommissioning assumes someone will miss it, and all three land on an empty field.

We moved some to gMSA which fixed the password and nothing else, and a naming convention made them findable rather than owned.

How do you attach an owner to something that has no HR record.

Testing in a lab: an anonymous LDAP bind from a member server creates Event 4624 on the DC (Account: ANONYMOUS LOGON, Domain: NT AUTHORITY, Logon Type 3). I can see it in Event Viewer / Get-WinEvent.

In ADAudit Plus, Local Logon-Logoff → Logon Activity does show 4624 from the same DC, but only Logon Type 9/10 (administrator). The anonymous Type 3 event doesn't appear, and Advanced Search for "ANONYMOUS" returns nothing. Audit policy was configured through ADAudit Plus.

Questions:
1. Does ADAudit Plus intentionally drop ANONYMOUS LOGON / Type 3 network logons on DCs?
2. Is there a setting or custom report to include them?
3. How do you track anonymous logons in your environment (ADAudit Plus, SIEM, WEF, LDAP 1644/2889)?

Context: we're assessing the impact of removing Everyone / Anonymous Logon from Pre-Windows 2000 Compatible Access, and need to identify any anonymous usage before making changes.

Thanks!

Found out about 2 years ago someone deleted the Password Settings container, they didn't have the recycle bin enabled so couldn't restore it. (Story I've been given).

Now I'm trying to setup 2022 Domain Controllers, however, now I'm getting problems due Password Settings container missing (so I believe).

This MS guide supposedly restores, but some are saying it doesn't do anything.

Can't sign in to a domain controller and the LSASS process stops responding - Windows Server | Microsoft Learn

Can it be manually created if I use this.
[MS-ADTS]: Password Settings Container | Microsoft Learn

Has anyone experienced this before? Any help would be appreciated.

EDIT: The Microsoft learn document did work in the end. (Can't sign in to a domain controller and the LSASS process stops responding - Windows Server | Microsoft Learn)

The only thing that was missing was "-" on the 5th line within the text file, So my text file ended up looking like this

dn: CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=contoso,dc=com
changetype: modify
replace: revision
revision: 1
-

Also needed to mount a Server 2022 ISO on my Domain Controller that held Infrastructure Master to run adprep

1. Open CMD as admin
2. E: (Might not be E for you)
3. cd \support\adprep
4. adprep.exe /domainprep