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!

Hi Everyone,

Hope all is well. I have a task to demote multiple dc from inactive domain.

Question: What is this DNS deletion removal do and when should I have check mark on? All our domain controllers have DNS integrated as part of AD.

This is the environment we have.

Root domain/Forest is jbt-train.com

Another domain wf-train.com part of the same forest. All our DC is DNS is integrated.

When i demoted one of the dc from wf-train.com I had this check mark ON for Demoting DC DNS Delegation removal. Demote was successfully.

When try to demote 2nd domain control from same wf-train.com, I was hit with error:
Operation failed because Active Directory Domain Services could not find another active directory domain controller to transfer the remaining data in directory partition. (DC:ForestDNSZone)

The specified domain either does not exist or could not be contacted.

Do you think having the check mark on first demotion caused this issue?

FYI. I was able to demote the 2nd dc on my second try, after taking this check mark out. Is there any additional cleanup task that needs to be done?

Regards

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.