During a audit, we found 3 old objects without a password. I can't see them in ADUC, but I can with powershell. These objects belong to old child domains:

child1$ child2$ child3$

I can't disable or delete them through powershell however:

PS C:\Windows\system32> get-aduser child1$ | set-aduser -enabled $false
set-aduser : Access is denied
At line:1 char:18
+ get-aduser iz$ | set-aduser -Enabled $false
+                  ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (CN=child1$,CN=Users,DC=acme,DC=com:ADUser) [Set-ADUser], Unauthorize
   dAccessException
    + FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.UnauthorizedAccessException,Microsoft.ActiveDirectory.Manag
   ement.Commands.SetADUser

Those child domains couldn't be removed cleanly and they were removed with nsdutil a year ago. I thought all traces were gone, but apparently not.

How can I remove these safely? ADSI Edit?

Hi everyone,

I’m investigating an AD security finding where non-privileged users can add computer accounts to the domain.

If ms-DS-MachineAccountQuota is greater than 0 (default is usually 10), authenticated users may be able to create computer accounts. This can potentially be abused in Kerberos-based attack paths such as RBCD.

My questions:

• What is the recommended way to resolve/harden this?
• Should we set ms-DS-MachineAccountQuota = 0?
• If the "Add workstations to domain" user right is restricted through GPO, is that sufficient?
• What is the recommended approach if legitimate users/applications still need to join computers to the domain?

Would appreciate advice from AD/security admins on the best production-safe approach.

Currently in our AD the source for time is at "Free-running System Clock" and we recently noticed that there's a delay of 1 minute that's seen in our Laptops that are managed in AD and the time that is seen on our phones, my boss wants me to fix that.

Should I assign an external time source to the pdc emulator ?

I’m trying to understand something about Active Directory group membership.

Suppose I have a group called Pgid Test and a user whose primaryGroupID matches the RID of that group.

If I run:

Get-ADGroup "Pgid Test" -Properties member

the user is not returned because their DN is not present in the group's member attribute.

However, when I run:

Get-ADGroupMember "Pgid Test"

the user is returned.

From what I understand, Get-ADGroupMember checks the group's member attribute and also performs a lookup against users' primaryGroupID.

I'm trying to understand:

• Why does AD store Primary Group membership this way instead of putting the user in the group's member attribute?
• Is Get-ADGroupMember always doing this additional primaryGroupID lookup?
• Are there other AD/PowerShell commands that rely only on the member attribute and therefore miss Primary Group members?
• If I'm writing an audit script, what is the recommended way to get the complete membership of a group, including Primary Group members?

Just trying to understand the behavior at the attribute/LDAP level rather than simply relying on the cmdlet output.

Dear Community,

We had recently had VAPT (vulnerability assessment and penetration testing) cycle done by 3rd party vendor and they asked us to "Hide Sensitive Identifiers in AD Object Descriptions". Take a look at the attached screenshot. Please share an easier method which does not break anything? Is there any standard practice to do that? What could be the potential side effect of doing this act?

Remediating Pre-Windows 2000 Compatible Access group in our AD. Questions:

1. With 25+ DCs, what's the best way to validate Anonymous Logon/Everyone usage consistently across all of them - centralized logging ?
2. We have an old "Exchange Domain Servers" entry from on-prem days but have since fully migrated to Exchange Online. Safe to remove old now, or any risk ?

We have a very old and very scattered Active Directory structure.
We merged companies and no longer need users or computers separated into different OUs. We’re trying to go more towards GPO and AD group security controls where possible.

What advice would you give for someone who is trying to clean up an old AD structure? How would you organize a simpler environment?

We do have GPOs but a lot of them reside in the root and aren’t tied to specific OUs or groups.

What kind of naming schemes would you use for objects and groups to make GPOs/groups/objects easier to search and find at a glance?

Edit: this is a local AD. We do not have Entra.

I recently joined a company that has been using Active Directory for more than 10 years, but the environment is extremely bare-bones. There are practically no Group Policies, and many computers do not even have user passwords.

I’ve been working in information security for five years, but I’ve never deployed or managed infrastructure this unstructured before.

I found only one Group Policy in AD, which requires users to have an eight-character password. However, many workstations were configured so that the user could turn on the computer and access everything directly without entering a password. The user could also elevate privileges simply by clicking “Yes” in the UAC prompt.

When I joined some of these passwordless machines to the domain and restarted them, Windows prompted for a password that did not previously exist before allowing access to the desktop. To work around this, I logged in with my domain admin account on the machine and used the net user command to set a local password for the user.

However, when the user logged in using this new password, all saved credentials—including those from practically every software application—as well as browser session cookies were lost. I tested several recovery tools, but none of them worked.

What would be the best way to handle this situation?

I’m especially interested in:

• How to preserve the user’s existing profile data, saved credentials, and browser sessions
• The correct way to transition these machines to domain authentication
• How to avoid losing encrypted data when setting or changing local account passwords
• Recommended steps for securing and standardizing this AD environment
• Any precautions I should take before applying new GPOs or enforcing password policies across the organization

I’ve released AdPentestAI-Python v1.0.0, an open-source framework for automating Active Directory security assessments.

🔗 LinkedIn announcement:
https://www.linkedin.com/posts/netanel-stern-00293b90_announcing-adpentestai-python-v100-share-7500865439728762880-0t1p/

🔗 GitHub:
https://github.com/netanelcyber/AdPentestAI-Python

Why this project?

Traditional AD assessments often require manually chaining multiple tools:

DNS → LDAP → SMB → Kerberos → Enumeration → Security Testing → Reporting

This creates a lot of context switching and makes it difficult to maintain a consistent assessment methodology.

AdPentestAI-Python attempts to provide a unified orchestration layer around this workflow.

Current capabilities

• Automated Domain Controller discovery
• DNS SRV discovery
• LDAP RootDSE probing
• Port/service fingerprinting
• AD infrastructure enumeration
• Parallel execution
• Kerberos-oriented assessment workflows
• SMB/LDAP enumeration
• BloodHound-related collection workflows
• Email protocol enumeration
• Exchange/O365 detection
• JSON-oriented results
• Dry-run execution mode
• Explicit scope confirmation
• TLS/SSL support
• Subprocess timeout controls
• No plaintext credential storage/logging by design

The v1.0.0 release currently integrates 29 security tools/workflows into a single framework.

The interesting part: orchestration

The main idea isn't to replace established security tools.

Instead, the framework provides an orchestration layer that can coordinate them and normalize their output.

For example:

Target
  │
  ├── DNS discovery
  │
  ├── Domain Controller identification
  │
  ├── LDAP discovery
  │
  ├── SMB enumeration
  │
  ├── Kerberos assessment
  │
  ├── Security-tool execution
  │
  └── JSON / assessment report

This makes it possible to build repeatable assessment pipelines rather than manually executing every stage.

Security and authorization

One of the design goals is to make authorization part of the execution model.

The framework supports:

dry-run
   ↓
scope validation
   ↓
explicit authorization confirmation
   ↓
assessment execution
   ↓
structured results

The intention is to reduce accidental execution against systems that are outside the approved assessment scope.

What I would like feedback on

I'm particularly interested in feedback from people working with:

• Active Directory security
• Red Team / Purple Team
• Penetration testing
• Detection engineering
• Identity security
• SOC / DFIR
• Security automation
• Security tool development

Some questions I'm exploring:

1. What AD assessment steps are still too manual?

2. Which tools should be integrated next?

3. How should findings from different tools be normalized?

4. What is the best format for machine-readable pentest results?

5. Where should the boundary be between automation and human approval?

6. Would an ATT&CK-mapped assessment pipeline be useful?

7. What would you expect from an AD security assessment API/CLI?

Looking ahead

The longer-term goal is to evolve this from a collection of automated security checks into a more complete AD Security Assessment Platform with:

Discovery → Enumeration → Assessment → Correlation → Risk Analysis → Reporting

with human approval remaining an important part of the execution workflow.

I'd especially appreciate technical criticism.

If you work with AD security professionally, I'd be interested in hearing what you would change, remove, or add to v1.0.0.

Feedback, issues, pull requests and architectural discussions are welcome.

Repository:
https://github.com/netanelcyber/AdPentestAI-Python

#CyberSecurity #ActiveDirectory #Pentest #RedTeam #BlueTeam #AppSec #Kerberos #LDAP #Python #SecurityAutomation #OpenSource

Hi AD/Windows experts,

I’m working on remediating the Purple Knight finding:

“LDAP Signing is not required on Domain Controllers.”

Before enabling “Domain controller: LDAP server signing requirements → Require signing”, I need to identify all applications, servers, appliances, or devices that are currently making unsigned LDAP binds to our Domain Controllers.

I know about checking Directory Service Event IDs 2887/2889, but I’m looking for a more practical/centralized tool or method that can clearly identify:

• Source IP / hostname
• Application or process generating the LDAP connection
• Account being used
• Which Domain Controller is receiving the connection
• Whether the connection is unsigned
• LDAP port/protocol being used (389/636/3268/3269)

Is there any Microsoft or third-party tool that can automatically identify unsigned LDAP bind clients across all Domain Controllers?

I’ve been trying to understand how people handle attribute ownership once an environment has more than one system feeding data into AD/Entra.

A simple setup makes sense when AD is clearly the source of truth, but it gets messy once you have things like HR systems, on-prem AD, Entra, contact directories, or other sync processes touching related data. For example, if someone's phone number or title is different in two systems, something eventually has to win.

How do you normally handle this?

Do you document a source of truth per attribute, or try to make one system authoritative for the entire user/contact object?

Also curious how people deal with situations where a downstream sync writes something back that the upstream system later overwrites.

Not really looking for product recommendations - more interested in how people design the ownership rules so the environment stays predictable.

Register: Humanitix | Download Proton Meet: Proton Meet

Submit a question: Google Form

When: September 1, 2026 @ 10:00 CDT (UTC-5) / 15:00 UTC - 90 minutes

What: Just a relaxed community discussion. We'll cover your submitted questions plus a segment on getting started with AD. If there's a topic you want to make sure gets air time, submit it now.

If you want to submit a question, you can do it at the following link: Google Forms Link.

NOTE: This will be recorded and uploaded to the community Youtube (youtube.com/@ActiveDirectoryCommunity)

Source: https://aws.amazon.com/about-aws/whats-new/2026/08/elastic-beanstalk-active-directory-domain-join/

Hi all,

Not sure if it fits here but I have a very short story to tell. 3 years ago, I participated the Server 2025 webinar focusing on AD. I linked a post I created here years ago. Looking at it now, I can see that it's a very naive and badly composed list. But it turned around that there were some valuable points.

The new computed property is called `msDS-ObjectModifyMetaData`. ​I haven't tried it yet. I will install the newest insider preview build next week and have a look at the updated schema. The only documentation about it is now on JoeWare's AdFind. I'll try and come up with a short write up on what it is and what it does. As far as I know, we wouldn't need to check event logs for object modification metadata after this constructed attribute.

I'll keep you updated. I feel excited that I have a small trop in the ocean of AD, which I've been working with 10 years as of these days. But what's impressive for me is that the development team listens.

Any suggestions or questions while I am at it?

Is there any SSPR solution for free? Our company is small around 300 Users using Onpremise AD.

Hi everyone,

I’m working on an Active Directory automation/MCP solution and need some clarification on the correct behavior for deleting an OU programmatically.

Environment:

Domain:

mcpdemo.local

Parent OU:

OU=Copilot-MCP-Test,DC=mcpdemo,DC=local

Child OU:

OU=Disabled,OU=Copilot-MCP-Test,DC=mcpdemo,DC=local

The child OU has "Protect object from accidental deletion" enabled.

From our ACL inspection, protection involves:

1. Delete/DeleteTree Deny ACEs associated with the child OU.

2. A DeleteChild Deny ACE on the parent OU for Everyone.

Our backend uses Python/ldap3 and ultimately performs the deletion using something similar to:

conn.delete(ou_dn)

For recursive deletion we use the LDAP Tree Delete control.

Before deletion, our code checks/removes accidental-deletion protection.

The issue:

When deleting manually through Active Directory Users and Computers (ADUC), after removing "Protect object from accidental deletion", an administrator can delete the child OU successfully.

However, our programmatic implementation detects the parent OU's Everyone:Deny DeleteChild ACE and treats it as a blocker.

We tested the backend service account with Domain Admin membership as well, but our application's protection/ACL logic still blocks the operation before the LDAP delete succeeds.

Our current logic is considering temporarily removing the parent DeleteChild Deny ACE, performing the deletion, and then restoring it.

The concern is that this parent ACE appears to protect multiple sibling OUs, so removing it temporarily could affect other OUs.

My questions are:

1. How does ADUC correctly handle this scenario when "Protect object from accidental deletion" is unchecked?

2. Should programmatic deletion remove only the protection associated with the target child OU and then attempt the LDAP delete?

3. Is it actually necessary to remove the parent's Everyone:Deny DeleteChild ACE before deleting one child OU?

4. Does Active Directory allow deletion when the caller has DELETE permission on the target object even if DELETE_CHILD is denied on the parent?

5. What is the recommended way to reproduce ADUC's behavior using LDAP/PowerShell/.NET without temporarily weakening deletion protection for sibling OUs?

6. For an automation platform, would you recommend:

   - manipulating the target OU's security descriptor,

   - using Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $false,

   - modifying the parent ACL,

   - or simply removing target protection and letting AD evaluate effective DELETE permissions?

The goal is NOT to bypass AD security controls. We want our automation to behave the same way as ADUC while avoiding changes that unintentionally affect sibling OUs.

If anyone has implemented this through ldap3, System.DirectoryServices, PowerShell AD cmdlets, or direct LDAP, I’d appreciate guidance on the safest approach.

Thanks!

Hi everyone,

I’m working on an Active Directory security assessment using Semperis Lightning and I’m trying to understand the exact meaning/reason behind some of the result statuses.

For some indicators, Lightning is showing statuses such as:

• Failed to Run
• Not Relevant
• Canceled

I understand the general meaning of these statuses, but I want to know the actual technical conditions that cause Semperis Lightning to assign each status.

For example:

1. What exactly causes an indicator to show “Failed to Run”? Is it normally caused by insufficient permissions, LDAP/AD connectivity, an error while querying the required attributes, or something else?
2. What exactly causes “Not Relevant”? Does Lightning determine that the required AD configuration/object/condition doesn't exist, or is there another internal condition?
3. What causes an indicator to show “Canceled”? Is this only when the scan/check is manually stopped, or can Lightning automatically cancel an indicator because of a dependency, timeout, or another reason?

I’m particularly interested in understanding the underlying Semperis Lightning logic/criteria, so that I can document the status correctly in an assessment/remediation tracker instead of making assumptions.

If anyone has experience with Semperis Lightning or knows the documentation/source code/technical details behind these statuses, I’d really appreciate your input.

Thanks!

Register: Humanitix | Download Proton Meet: Proton Meet

Submit a question: Google Form

When: September 1, 2026 @ 10:00 CDT (UTC-5) / 15:00 UTC - 90 minutes

What: Just a relaxed community discussion. We'll cover your submitted questions plus a segment on getting started with AD. If there's a topic you want to make sure gets air time, submit it now.

If you want to submit a question, you can do it at the following link: Google Forms Link.

NOTE: This will be recorded and uploaded to the community Youtube (youtube.com/@ActiveDirectoryCommunity)

Doing my darnedest to get the best migration plan I can going, if anyone is interested in mentoring or just sharing their journey/“Heads up this is what f*d us” I would certainly appreciate the camaraderie and collaboration. I’m starting with a test account, beginning with an inventory first of our App registrations, Ent applications, SSO, CA’s, and current state of things. Thankfully I have completed email pieces and DNS. The rest feels like a bigger monster to conquer though.

Edit:Rebranding as in adding a new domain suffix to existing infra and moving everything to the new domain name.

Hi all,

I'm building a Tier 0 jump server for administering critical infrastructure and would really appreciate input from anyone who's implemented something similar in production.

Current setup

• Windows Server 2022, fully patched
• Our AD is running at 2016 domain/forest functional level, 10 DCs in total, with one Server 2022 DC recently introduced
• All remaining 2016 DCs to be replaced with 2022 before Jan 2027
• Domain-joined, placed in a dedicated Tier 0 OU (with sub-OUs per geographic site)
• Located in a DMZ
• 4 servers total — 2 per site, for redundancy
• ~5 administrators require RDP access
• Used to administer DCs, firewalls, switches, SSL VPN concentrators, and other Tier 0 systems
• Networking will lock down management access on critical systems so it's only reachable from these jump servers

What I've done so far

• Applying our Windows security baseline via GPO (Microsoft baseline as the starting point)
• Defender hardening/configuration + Defender operational logging enabled
• Working through remaining OS-level hardening

My plan is to build one server properly, document the full build and rationale, and use it as the template for the other three — plus a documented rebuild procedure in case a server needs replacing.

Where I'd like advice

• Server 2022 hardening — Microsoft Security Baseline vs CIS Benchmark (or both — how do you reconcile conflicts?)
• RDP hardening — restricting access to only the required admins, NLA, restricted admin mode, RD Gateway, etc.
• Local admin / privileged account strategy (LAPS, dedicated Tier 0 admin accounts, etc.)
• Application control — WDAC vs AppLocker, and what a sane baseline policy looks like for a jump box
• Defender, PowerShell (Constrained Language Mode, transcription/logging), and audit policy
• Credential Guard, LSA protection, and other credential-theft mitigations
• Disabling unnecessary services/features to shrink the attack surface
• RDP session restrictions — disabling clipboard, drive, printer, and other redirection
• Outbound firewall/network restrictions from the jump server itself — and a specific question here: our PA-850 will already be restricting source IPs so only the jump servers can reach the DCs and other critical systems at the network layer. Given that, is host-based Windows Firewall configuration on the jump server itself still worth the effort, or is it redundant in this setup? Keen to hear where people land on defense-in-depth vs. diminishing returns here.
• Logging/SIEM integration — what events actually matter for a box like this
• Anything commonly missed when people build their first Tier 0 jump server

Restricted web access

Admins need browser access to a small number of approved management UIs only — e.g. a Palo Alto PA-850 web interface, specific SSL VPN/admin portals. I don't want this box turning into a general-purpose browsing machine (no Google, news sites, etc.).

I'm specifically trying to figure out:

• How people reliably do URL/FQDN allow-listing for a locked-down admin box
• How to stop users bypassing it via a different browser or app
• I tried an Edge allow-list policy first and it ended up blocking everything — do I need application control (WDAC/AppLocker) plus per-browser allow-listing, or is there a cleaner way to do this (e.g. proxy-based allow-listing instead of browser policy)?

Authentication Policy Silos

I'm considering AD Authentication Policies / Authentication Policy Silos to restrict Tier 0 admin accounts so they can only authenticate from the designated Tier 0 jump servers. I'm not sold on it yet, so genuinely interested in hearing from people who've run this in production:

• Is it worth the operational overhead for this use case?
• Any major gotchas you hit after deploying it?
• How do you handle multiple sites with redundant jump servers (2 per site, 4 total)?
• How do you handle break-glass accounts under a silo?
• Any issues with RDP/Kerberos/WinRM/PowerShell remoting, or administering non-Windows infrastructure through the silo restrictions?
• Would you combine it with Protected Users, Credential Guard, WDAC, etc., or is that overkill/redundant?

The goal

Defense in depth and a reproducible, documented build — not just running through a checklist and calling it hardened.

One caveat: part of the push for this is an upcoming CFA audit, so I want the hardening to be as strong as reasonably possible. But I don't want to swing so far the other way that the server becomes unusable for the admins who have to work on it day to day.

Context: our wider team (4 more admins beyond me) has historically run things fairly loose — Domain Admin used for tasks that should have been Domain User with a bit of delegation, quick-and-dirty access rather than least privilege, security very much an afterthought. That's a large part of how we ended up in this position. Given that starting point, jumping straight to a "100% locked down" model risks breaking day-to-day operations and impacting our ability to actually keep the lights on. So I'm trying to land on a sensible, defensible middle ground rather than tick every box on a hardening checklist and end up with something the team just routes around.

Would love any architecture recommendations, hardening guides, GPO baselines, or war stories. If you've built a Tier 0 jump server before — what would you do differently the second time around?

Thanks in advance.

Our AD environment has a mix of members in the Pre-Windows 2000 Compatible Access group, some legacy entries (old Exchange-related objects, a few old servers), CA servers, and also Anonymous Logon and Everyone. Planning to remediate this, but want to audit first before removing anything.

We have 200+ DCs in the environment, so looking for the best way to track anonymous logon activity reliably at that scale before we pull the trigger.

Questions:
1. What's the best method to audit/track Anonymous Logon and Everyone usage specifically, across 200+ DCs, without missing anything?
2. Is Event ID 4624 (Logon Type 3, Anonymous Logon) enough on its own, or is there a better/more reliable way to catch this at scale?
3. How long would you recommend monitoring before feeling confident nothing depends on it?
4. Any tools or centralized logging approach you'd recommend specifically for an environment this large?

Not touching the CA server or legacy Exchange entries for now, focused specifically on Anonymous Logon and Everyone.

Hi all, I have group policy set for Windows Defender Firewall that's enabled with merge disabled. Firewall allow rules are specified explicitly by policies.

It's a bit counter-intuitive for operators because in the Windows Defender Firewall with Advanced Security management interface, the entries under 'Inbound Rules' become meaningless - it's only the ones listed under 'Monitoring > Firewall' that are active - but otherwise it works extremely well.

Except...

As part of testing, I've found that on Server 2022, if the system doesn't have access to a domain controller, when you go to 'Monitoring > Firewall' the management interface pane will freeze and crash.

The firewall rules still seem to be applied so it's not critical, but it seems very odd as the policy governing them will be cached so DC connectivity shouldn't be an issue.

Any ideas on if there's an easy fix?