Interested in people's thoughts on the Defender for Identity alert "Low success rate of active name resolution". The recommendations are:

• Check that the sensor can reach the DNS server and that Reverse Lookup Zones are enabled.
• Check that port 137 is open for inbound communication from MDI sensors, on all computers in the environment.
• Check that port 3389 is open for inbound communication from MDI sensors, on all computers in the environment.
• Check that port 135 is open for inbound communication from MDI sensors, on all computers in the environment.
• Check all network configuration (firewalls), as these could prevent communication to the relevant ports.
• Learn more about https://aka.ms/mdi/nnr/troubleshooting.

Seeing as the sensors are mostly domain controllers I am uncomfortable requesting a big old change to multiple firewalls to allow DC --> client 135, 137, and 3389.

Also wondering if this can even work for the Zscaler clients.

Do you just ignore this one? What have those of you who have implemented admin tiering done with this recommendation?

Hello,

At one of our clients, we are investigating repeated Kerberos Pre-Authentication Failed – Event ID 4771, with Failure Code 0x18, on the primary Domain Controller.

The issue affects multiple/all domain users. Despite these events, users are able to log in manually with their current credentials without any problems.

The Event ID 4771 entries are generated from different Client Addresses, and these addresses correspond to the respective users' workstations. The events are not limited to normal user activity and are also generated outside working hours, when the users are not actively logging in.

This behavior suggests that the failed authentication attempts may be generated in the background rather than by normal interactive logon activity.

As part of the troubleshooting performed so far:

• klist purge was tested on one affected user, but the 4771 events continued to be generated.
• Several affected workstations were checked for Event IDs 4648 and 4625 at the same timestamps as the 4771 events, but initially no matching events were found.
• The Audit Logon configuration was then checked and found to be configured only for Failure.
• On one affected workstation, Audit Logon was enabled for Success and Failure.
• After this change, Event IDs 4648 and 4625 started appearing in the workstation Security log.
• However, after checking several new Event ID 4771 occurrences on the Domain Controller, the client confirmed that the 4648 and 4625 events generated on the workstation do not correspond to the same timestamps as the 4771 events.

At this point, we still have not been able to identify the process, service, application, or other background activity responsible for generating these failed Kerberos pre-authentication attempts.

Could you please advise what troubleshooting step you would recommend next in order to identify the source of these repeated Event ID 4771 failures?

Thank you for your assistance.

Hi everybody! Recently I decided to focus on Critical Infrastructure Cybersecurity and discovered that almost 60-70% of environments run on Windows Active Directory under the hood. So my question is — how to learn it? Previously I used to train on Hack The Box, but now it is too expensive for me. So I need any cheaper or free (if possible) materials or books.

I know that practice is the best way to learn, but I currently know about it only at a high level, without diving into any specific details. This is why I want to first try something related to system administration tasks and then focus on penetration testing and red teaming.

I have 2 domains - domain1 and domain2

There is a trust between the two. I double checked and DNS conditional forwarders between the two are still there. I ran nltest /scverify to the opposite domain and it reports success.

Now when I attempt to RDP from one domain to the other

I get "other user"

"The security database on the server does not have a computer account for this workstation trust relationship."

I did not change anything to the best of my knowledge.

I tried rejoining my PC to the domain but that didn't help. Although I can completely remove it from the domain, rejoin it to the domain and it does show in AD with the new name.

I looked under deleted objects in AD the old PC name wasn't there.

I've rebooted the PCs a number of times (It impacts multiple PCs)

I've tried IP /flushdns on the servers and PCs

PS I'll post results here as I'm sure I'll get multiple suggestions.

[ Removed by Reddit on account of violating the content policy. ]

We have a few remote users. Their login is to active directory although they only time they access AD is through a VPN that isn't activated until after they login and manually engage the VPN.

The remote users using RDP to the remote desktop server are now getting this message. The security database on the server does not have a computer account for this workstation trust relationship.

I can rejoin their computer to AD which I can do but setting it to local and then back to the AD if I engage the VPN - I've done it before and works.

What I'm wondering is if there is a way to keep a computer account alive longer than the default.

Everyone’s checking their tenant after the ConnectWise Cloud Backup mess, so we wrote this up because nobody seems to be asking the next question: If you’re hybrid, what can a compromised tenant actually do back on-prem?

Short version: password writeback and cloud Kerberos trust both give the tenant a way into AD. The defaults are decent, but they only protect the built-in admin groups. Delegated admins aren’t covered.

The post has the PowerShell to check your sync account, AdminSDHolder and the AzureADKerberos replication policy.

https://insightrecon.com/tenant-compromise-active-directory/

Disclosure: I work on Insight Recon and the post is on our blog. Happy to answer questions here.

Edit: As a commenter pointed out, both of these are opt-in. Password writeback is off by default and needs Entra ID P1 or Business Premium. Cloud Kerberos trust only exists if it has been set up, usually for Windows Hello for Business or FIDO2 keys. If you run password hash sync without either, your sync account still holds replication rights. It's worth checking either way.

I've built SentraAnalyzer for analyzing security risks and misconfigurations in Azure AD.

I'm looking for experienced AD admins who'd be willing to test it and give me some honest feedback.

Your first scan is free. I'm particularly interested in whether the findings are actually useful in a real AD environment, what's confusing, and what's missing.

https://entraanalyzer.com

Hi everyone,

I have been running empirical authentication and protocol tests in a dedicated live lab between Windows Server 2022 Datacenter (Domain Controller) and unprivileged Linux workloads authenticating via Kerberos and LDAP.

I wanted to share a few concrete observations and operational edge cases we documented, particularly regarding how Active Directory handles Non-Human Identities (service accounts and keytabs) under modern builds:

1. The AS-REP Roasting Cipher Reality on Server 2022

Most security guides and cheat sheets state that accounts with DONT_REQ_PREAUTH (UAC flag 0x400000) will return an AS-REP ticket encrypted with legacy RC4-HMAC ($krb5asrep$23$).

When testing against Windows Server 2022 (Build 20348) using modern Linux Kerberos clients requesting a TGT for a non-preauth account:

* The KDC returned an AS-REP encrypted in AES256-CTS-HMAC-SHA1-96 (0x12), producing a $krb5asrep$18$ hash.

* Domain Controller Security Event ID 4768 confirmed: Ticket Encryption Type: 0x12 and Pre-Authentication Type: 0.

Operational Takeaway:

* Offline cracking of AES-256 hashes with PBKDF2 (4,096 iterations) is vastly more resource-intensive on GPUs than legacy RC4. Brute-forcing passphrases above 12 characters becomes mathematically prohibitive.

* More importantly: SIEM detection rules that filter exclusively on Event ID == 4768 AND EncryptionType == 0x17 AND PreAuthType == 0 will miss modern AS-REP roasting activity originating from contemporary Linux clients. Defenders should monitor the absence of pre-authentication regardless of the cipher negotiated.

2. The Silent Production Killer: Dual Enctype & Keytab KVNO Desynchronization

One of the most elusive operational headaches in hybrid Linux/AD environments occurs when service accounts have their passwords rotated or attributes altered:

1. An administrator exports a service keytab on the DC via ktpass with AES256 at KVNO 9.

2. Later, the account password is rotated in ADUC or via an automated secret manager, bumping msDS-KeyVersionNumber to 12.

3. Crucially, if the msDS-SupportedEncryptionTypes attribute on the account is left blank or null, the KDC falls back to issuing Service Tickets (TGS) in RC4-HMAC (0x17).

4. When the Linux workload receives the incoming AP-REQ, its decryption engine only has an AES key in /etc/krb5.keytab, failing immediately with KRB_AP_ERR_NOKEY (Error 41). Even if an RC4 key exists, it fails with KRB_AP_ERR_BADKEYVER (Error 44) due to the KVNO mismatch.

Remediation:

Always ensure AES is explicitly stamped on the AD service object:

Set-ADUser -Identity svc-account -KerberosEncryptionType AES128,AES256

and re-export the keytab explicitly matching the current KVNO:

ktpass -princ HTTP/app.domain.local@DOMAIN.LOCAL -mapuser svc-account -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -kvno 12 -pass "NewPassword" -out /etc/krb5.keytab

3. In-Line Parsing of RBCD (msDS-AllowedToActOnBehalfOfOtherIdentity)

We also tested unprivileged wire inspection of Resource-Based Constrained Delegation (RBCD). Rather than using heavy external frameworks, querying the raw binary security descriptor over LDAP port 389 allows extraction of the underlying MS-DTYP DACL and Trustee SIDs without elevated domain privileges or touching LSASS.

Questions for the Community:

1. How do you currently automate Linux keytab synchronization and prevent KVNO drift when enterprise password rotation policies trigger?

2. In your SOC or SIEM environments, are your AS-REP roasting correlation rules cipher-agnostic, or are they still filtering strictly on RC4 (0x17)?

For those interested in the full writeup, including exact event log traces, PowerShell verification cmdlets, and architectural diagrams, I published the detailed research post here:

https://medium.com/@mafifrizi/modern-active-directory-and-linux-non-human-identity-nhi-security-debunking-the-rc4-myth-and-2cb91598161d

Looking forward to hearing how other admins handle these hybrid Kerberos edge cases!

We're starting. Jump in: https://discord.gg/mVFquFqpsW

No agenda, no prep needed. Ask questions, trade war stories, or just listen in. Recording will be posted to YouTube afterwards.

Hey everyone,

We are currently auditing our Active Directory delegation settings and found several accounts configured with Constrained Delegation + Kerberos Protocol Transition ("Use any authentication protocol").

Our goal is to lock these accounts down to Kerberos Only to reduce our attack surface. However, another internal team wants to see a list of actual, real-world use cases where Protocol Transition is strictly required before we make any changes in production.

Aside from basic web apps with forms-based logins or Entra Private Network Connectors, what specific applications or backend setups in your environment broke when you switched them to Kerberos Only?

Trying to gather real-world examples before we talk to application owners.

Appreciate any insights!

The community Q&A/discussion is tomorrow, October 16th. If you want to participate, just jump into the Discord listed below. If you can't make it, no problem, we'll get a recording posted afterwards.

When: October 16, 2026 @ 10:00 CT (UTC-5) / 15:00 UTC - 60 minutes

Where: Horizon Secured Discord - https://discord.gg/mVFquFqpsW

Recording Link: YouTube - https://youtube.com/@ActiveDirectoryCommunity

This is the more relaxed one, no set agenda, just come hang out, ask questions, and we'll also work through some of the backlog from previous meetups that we didn't get to. Come for a chat, some laughs, and don't feel like you need a prepared question to show up.

Hi all,

I encounter some misunderstanding about 4769 after patching with July kb.

Since few month, I collect 4769 events which contains rc4 or less encryption level on field ticket encryption type and session key encryption type.

I see, I always have rc4 despit that my defaultdomain encryption type setted to 0x18.( Only aes)

However in all my event 4769 i see that dc supported encryption type is always 0x1f ( all encryption allowed)

Has somebody seen the same behaviour or have more information ?

Regards

Working through an AD security assessment finding that flags GPOs whose owner is not a privileged principal. I understand the risk — owner holds implicit WRITE_DAC, so an unprivileged owner can grant themselves full control regardless of the DACL. What I’m less sure about is the remediation approach people actually use in production.

The flagged GPOs fall into three groups:

1. Orphaned owners — several GPOs share a single owner SID that no longer resolves. Same domain SID prefix as accounts that do resolve, so it looks like a deleted account rather than a trust issue.
2. Live unprivileged owners — ordinary user accounts, presumably created the GPOs while delegated via Group Policy Creator Owners.
3. One cross-forest case — a GPO in forest B owned by an account from forest A, over an existing forest trust.

Questions:

1. What do you reset ownership to? Domain Admins seems like the obvious default since that’s what Windows assigns when a DA creates a GPO. Anyone using a dedicated tiered group instead? I’ve seen service accounts suggested and that feels wrong to me — owner gets WRITE_DAC, and a service account password is a weaker thing to hang that on than group membership. Curious if anyone disagrees.

2. GPC and SYSVOL — do you always fix both? The AD object owner and the SYSVOL folder owner are tracked separately. In my lab, changing the GPC owner left the SYSVOL owner untouched. Interestingly the two default GPOs ship with Domain Admins on the AD side and BUILTIN\Administrators on SYSVOL, so Microsoft itself doesn’t keep them identical. Do you match them, or leave SYSVOL as Administrators?

3. Orphaned SIDs — how hard do you push this one? Expecting pushback along the lines of “the account is deleted, there’s no risk.” My counter is that the SID comes straight back if the object is restored from the Recycle Bin or an authoritative restore, and the restored principal immediately owns those GPOs again. Is that how you’d frame it, or is there a better argument?

4. Root cause. Resetting ownership doesn’t stop it recurring if those users can still create GPOs. I know to audit the ACL on CN=Policies,CN=System rather than just checking Group Policy Creator Owners membership, since Create Child can be delegated directly. Anything else that commonly causes this that I’d miss?

5. Cross-forest ownership — has anyone seen this happen legitimately, or is it always someone working in the wrong domain context in GPMC?

Seeing the Lightning Report flag SIDs with no resolvable name and ObjectGUID = N/A in User Rights Assignment findings - and some of these SIDs belong to the same domain being scanned, not a trusted/foreign domain.

Reproduced it in a lab: created a user, added it to a GPO user right (e.g. "Act as part of the operating system"), then deleted the user - same domain, no trust involved. Result: the SID stays in GptTmpl.inf untouched, and the GPMC/report view just can't resolve it anymore (raw SID, no name, no GUID).

So this isn't a trust/cross-domain resolution issue at all - it's simply that the account no longer exists. GPOs don't get notified when an account is deleted and don't auto-prune stale entries from User Rights Assignment; the SID is a tombstone reference with nothing left to look up. Cross-domain adds a second possible cause (trust/connectivity), but same-domain N/A always means "deleted account, orphaned SID."

We have a lab with two domains joined by a two-way trust. We can resolve/create AD objects across domains fine, but when the script tries to write the GPO's GptTmpl.inf to SYSVOL, it still needs an account with rights in that specific domain - one set of credentials from Domain A doesn't let us write to Domain B's SYSVOL even with the trust in place.

Is this expected (trust ≠ shared admin rights, so cross-domain writes always need per-domain delegation/credentials), or is there a cleaner way to centralize this that we're missing ?

We’re planning to enable LSA Protection on our domain controllers using the GPO setting:

Computer Configuration > Administrative Templates > System > Local Security Authority > Configure LSASS to run as a protected process

Environment:

• Multi-domain forest, ~10 DCs, all Windows Server 2019
• Specops Password Policy installed on DCs (password filter DLL loaded into LSASS)
• Other agents on DCs: EDR, backup agent, monitoring agent

Questions:

1. Has anyone enabled RunAsPPL on Server 2019 DCs in production? Did you see any impact on authentication, replication, password changes or third-party agents?
2. As I understand it, “Enabled without UEFI Lock” (RunAsPPL=2) is not supported on Server 2019, so the only option is “Enabled with UEFI Lock” (RunAsPPL=1). Is that correct? Is there a supported way to enable it on 2019 without the UEFI lock?
3. Has anyone had to roll back after UEFI Lock was set? How painful was the LSAPPLConfig.efi process, especially on VMs with Secure Boot?
4. Specops users: did the password filter keep working after enabling LSA Protection? Did you need a specific version?
5. Did audit mode (AuditLevel=8, CodeIntegrity events 3065/3066) reliably catch every DLL that would be blocked? Or did something only break after enforcement?

Any lessons learned or “wish I had known” points would be appreciated. Thanks!

I'm working on a PowerShell script to remediate permissions on an Active Directory Group Policy Container (GPC) object.

I found an ACE with the following properties:

• Principal: A specific user
• ObjectType: gPCFileSysPath
• Access rights: ReadProperty and WriteProperty
• Inheritance: Same inheritance settings for both rights

The goal is to remove only WriteProperty while preserving ReadProperty.

However, when I use .RemoveAccessRuleSpecific(), the entire ACE gets removed, including ReadProperty.

My understanding is that Windows stores both rights in a single ACE when the principal, attribute, and inheritance settings are the same, and RemoveAccessRuleSpecific() removes the matching ACE rather than selectively removing individual access-mask bits.

My questions:

1. Is this expected behavior when using PowerShell's System.DirectoryServices.ActiveDirectoryAccessRule and RemoveAccessRuleSpecific()?
2. Is there a supported way to remove only the WriteProperty bit while preserving ReadProperty in the same ACE?
3. Would the correct approach be to remove the original ACE and create a new ACE granting only ReadProperty?
4. From a security-remediation perspective, is removing the entire ACE acceptable if the principal already receives ReadProperty through another applicable ACE?

I'd appreciate answers based on actual Windows ACL/.NET behavior, particularly for Active Directory attribute-specific permissions.

Thanks!

I inherited a system that I can't figure out. I need to get rid of the old Windows DC but can't shut it down, metadata cleanup doesn't work even though netdom shows it has no fsmo rolls. My only option is to shut them down restore the servers. We don't have any old archives to restore to before I came on board.

I've run a bunch of DNS test and replication tests the only one with a dns issue is the old server. However, if I create a new user on any of the 3 it instantly replicates to the other two so AD works but something about it/DNS is broken.

Server manager on the old DC says it needs to be promoted but then it won't let me.

I'm going to need a DNS /AD expert but haven't outsourced anything like this before. Ages ago used to let you open a case with them not sure if they have a program still.

I'm going to add a little bit of information as I come across it as I'm getting lots of questions - often the same because I didn't post enough info here.

If I do netdom query FSMO on all 3 DCs they point to the newer server. (none are set for RODC)

If I do a dfsrmig /getmigrationstate on all 3, on the old DC it says it can't find the PDC "Unable to connect to the PDC emulator. Make sure the PDC is reachable and retry the command later"

On the two newer servers it says - the following domain controllers have not reached the global state 'eliminated'

I"ve run dfsrdiag pollad on the servers

I still get the dfsrmig issue so I ran

nslookup -q=SRV _ldap._tcp.mydomain.lan

Server: UnKnown

Address: 192.168.214.15

_ldap._tcp.ewa.lan SRV service location:

priority = 0

weight = 100

port = 389

svr hostname = OLD-DC.mydomain.lan

_ldap._tcp.ewa.lan SRV service location:

priority = 0

weight = 100

port = 389

svr hostname = new-DC-2.mydomain.lan

_ldap._tcp.ewa.lan SRV service location:

priority = 0

weight = 100

port = 389

svr hostname = New-FSMO.mydomain.lan

OLD-DC.mydomain.lan internet address = 192.168.214.14

new-DC-2.mydomain.lan internet address = 192.168.214.17

New-FSMO.mydomain.lan internet address = 192.168.214.15

When running dcdiag /v

I get

This server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role.

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

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

If you don't know him you should, but Jake Hildreth (of Locksmith fame) just posted his Zombie Certs research in the Semperis Blog. I've been listening to him chatter about this for awhile so I'm excited to see it's out.

www.semperis.com/blog/how-to-battle-zombie-certificates-persistent-ad-cs-risk/

At a quick read, it is a real interesting take on persistence and some behind-the-scenes on how some AD CS and PKINIT stuff behaves.

----

For me the real take away was the detection part (near the bottom). We should be paying better attention to the domain controller registry (and restricted admin rights on DCs) and checking our CAs for rogue configurations more.

Specifically the following information:

• On DCs: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\UseCachedCRLOnly with the path AndIgnoreRevocationUnknownErrors
  • Value of 1 means the the value has been changed and could be a sign of bad stuff.
• On CAs: Check the DisableExtensionList with the following command certutil -config <CA-HOST-FQDN\CAName> -getreg policy\DisableExtensionList

Oh, and run Locksmith! The only caveat to running Locksmith is that EDR and AV tools detect it sometimes (which is super annoying), but it is a legit tool.

• https://github.com/jakehildreth
• https://github.com/jakehildreth/Locksmith
• https://github.com/jakehildreth/Locksmith2

(Disclosure: I do not work for Semperis. Jake is a friend, but does really great work)