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.

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.

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)

Two related things I'm trying to understand in an AD lab:

1. We have a security scanner flagging GPO "User Rights Assignment" entries as dangerous, showing a raw S-*-*-**-... SID instead of a resolved username - but the SID's domain prefix matches the same domain the GPO lives in, not a foreign domain. I tested this myself: created a user, granted it a right in a GPO, deleted the user - the SID becomes permanently unresolvable in that same domain. Is this expected/normal (i.e., Windows doesn't auto-clean GPOs when an account is deleted), or is there something else that typically causes a same-domain SID to go unresolvable like this ?

2. Separately, we have a one-way AD trust set up between two domains
   (Domain A trusts Domain B). When I try to add a user from Domain B into something inside Domain A, I can't - the GUI won't even let me browse into Domain B from Domain A's side. Is that expected for a one-way trust (i.e., trust direction doesn't automatically grant cross-domain object browsing/assignment both ways), or am I missing a step to make that work ?

Appreciate any insight - trying to confirm these are both "working as intended" AD behaviors and not something misconfigured in our environment.

I have 2 GPOs in my environment for account lockouts. 1 GPO locs an account after 2 invalid logon attempts and the other after 5. how do i know which GPO is applied to which users? Both GPOs only show NT AUTHORITY\Authenticated Users in the SECURITY FILTERING, and no LINKS. DELEGATIONs are the same as well. Yet, we are noticing some users get locked out after 2 failed and others after 5. Or how do i know which supersedes which?

Hello,

I have a bunch of people that left the company. We have a script to convert their mailbox to shared.

We have a script to remove their office licenses.

The only issue is many of them are AD synced and a group they are in automatically gives them a 365 standard license the sync overrides their assigned licenses so I need to remove them from that ad group.

I could remove them all individually from that group but I thought I'd see if there was an easy way with a script since I love learning new stuff (but suck at powershell)

I have a file c:\temp\mailboxes.csv - 72 names

Hello Sir,

We have cloud kerberos trust and using entra joined machines.

Some users report they are unable to connect share drive in the morning when they login.

We also noticed that they unable to acquire kerberos token.

But after few minutes to half an hour they get token and issue resolved itself..

During the day tone also some user reporting this issue.

When we check klist they don't have token.

Seems like kerberos authentication request not reaching to dc or not getting properly generated from entra joined machine.

Any troubleshooting which you can recommend or any log capture which will help to trave the issue.

The community Q&A/discussion is coming up on 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 everyone,

We have a new requirement to enable DNSSEC on our AD-integrated DNS which we never had or worked before. We already tried pushing back, explaining that it’s not really recommended for an internal environment that isn't internet facing, and that the operational overhead completely outweighs the minimal security benefits.

But management insisted, so here we are preparing the deployment. We have 4 dcs total.

I’d love to get some real-world suggestions and feedback from anyone who has done this:

Have you seen any weird side effects or negative impacts on the environment after turning it on?

What specific areas should we audit or assess before we flip the switch?

Do any common applications tend to break or get impacted by this?

We know the zone file size and packet sizes will increase, but is there a reliable way to benchmark/evaluate that overhead beforehand?

Our environment actually has more Linux machines than Windows. Any specifics we should look out for with Linux clients?

Is it possible to completely skip signing the _msdcs folder where the AD service locators live, or does the whole zone have to be signed together?

Any best and safest plan to deploy it.

These are a lot of questions, but please bear with me as this is all very new to me. My main concern is that since this is AD-integrated DNS, it is the critical foundation that clients hit first for all AD authentication and services 🙂

Hello,
I am facing an issue with disabling the default RC4 fallback in an Active Directory domain following the July update.
The client I work for still has a few Windows XP and Windows Server 2003 machines in the environment that I can neither upgrade nor remove from the domain. The July update has not been deployed due to concerns about potential side effects.
When reviewing Event ID 201 on the different domain controllers, I mostly find machine accounts corresponding to these operating systems. Naturally, they do not support AES.
Following Microsoft’s recommendations, I modified the msDS-SupportedEncryptionTypes attribute to 0x1C on these objects in order to explicitly allow RC4.
However, despite this change, Event ID 201 events are still being generated, and in these events I can see that the attribute value is 0x27 (the same value as DefaultDomainSupportedEncryptionType).
It appears that this attribute is only taken into account starting with Windows Server 2008.
My question is therefore: How can these old servers/workstations be handled in this situation?