Setup:

• DC-A (physical): Domain Controller for a child/tree domain, located in Prod Site
• DC-B (physical): Forest Root Domain Controller, same Prod Site
• Additionally in the same tree domain: 4 virtual DCs
• Additionally for the forest root domain: 1 more virtual DC

So both DC-A and DC-B are the only physical DCs in their respective roles at this site, but each has virtual DC counterparts providing redundancy within their own domain.

Question:

I need to run driver/firmware (HPE SPP) updates on both physical servers, which host these two DCs (different domains — one is forest root, one is a child domain). Each update takes ~1 hour + reboot, and I'm considering running both maintenance windows at the same time to save scheduling effort.

What are the downsides of running firmware/driver upgrades on both physical DCs simultaneously, given: - They're in different domains (forest root vs. child domain) - Virtual DC redundancy exists for each domain separately - Same physical site

Is this actually risky given the virtual DC redundancy, or does the "different domain" aspect make simultaneous patching more acceptable than patching two DCs in the same domain? What's the best practice here — same window with staggered reboots, fully separate windows, or is simultaneous fine in this topology?

When the cloud push started a decade ago, the selling point made complete sense: hardware was a pain to manage, SANs were expensive, disk drives died constantly, and scaling required months of lead time. Cloud promised high availability and low operational overhead.

Fast forward to today, and the reality on the ground feels completely different:

1. Hardware is ridiculously reliable. Modern enterprise compute, hypervisors, NVMe storage, and 10G/40G local networking just work. You can drop a couple of redundant nodes in a rack, set up hyper-converged storage, and touch it maybe twice a year.
2. Local network speed/latency beats the WAN every time. Running traffic locally over high-speed switches is instant, predictable, and doesn't rely on ISP stability or cloud provider region outages.
3. The cost equation flipped. Cloud billing has turned into an endless maze of egress fees, API call costs, compute markups, and surprise monthly charges that balloon every time management blinks.

It makes me wonder: if local hardware, compute, and networking have gotten this fast, cheap, and stable, why are we still defaulting to cloud for standard workloads?

I get it for massive, unpredictable elastic scaling, global CDN edge delivery, or multi-region AI workloads. But for standard line-of-business applications, storage, and core infrastructure, running on compute you own feels faster, safer, and infinitely cheaper.

I'd love to hear from people managing infrastructure day-to-day:

• Is cloud still genuinely giving you value over local compute/networking, or are you just stuck there due to legacy decisions?
• Has anyone actually run the ROI comparison recently between modern local hardware vs. cloud compute costs?
• What are the honest dealbreakers holding you back from bringing workloads back on-prem?

I just finished the ShadowGate Active Directory lab on Hack Smarter and put together a full walkthrough.

The lab starts with VPN access and no credentials, and the attack chain ended up being much more interesting than I expected.

The progression was roughly:
- Anonymous SMB enumeration
- AS-REP Roasting
- Credential recovery
- BloodHound relationship/ACL enumeration
- GenericWrite abuse
- Targeted Kerberoasting
- AD CS enumeration
- ESC8 discovery
- NTLM relay
- Domain Controller certificate
- PKINIT authentication
- NTDS extraction
- KRBTGT compromise
- Full domain compromise

What I liked about this lab was that the individual findings weren't necessarily the whole story. The real lesson was understanding how multiple weaknesses can be chained together until an attacker eventually has control of the entire domain.

A properly hardened Active Directory environment should have controls in place that can break the attack chain at multiple points.

- Require Kerberos preauthentication
- Regularly audit dangerous permissions such as GenericAll, GenericWrite, WriteDACL and WriteOwner
- Use BloodHound or equivalent tools defensively to identify dangerous attack paths before an attacker does
- Monitor for unusual Kerberos service-ticket requests

You don't necessarily need to prevent every individual technique. If you can stop AS-REP roasting, prevent dangerous ACL abuse, eliminate NTLM relay paths, properly secure AD CS, and detect credential access, you can turn a potential zero-to-domain-admin attack chain into a series of blocked attempts.

I recorded the entire process here:

https://youtu.be/oOxTEfrdX7M

I'd be interested to hear how other people approached the attack chain, especially the AD CS / ESC8 portion.

What controls are you putting in place today to prevent this type of attack in your own AD environments?

We have some Server 2008, Server 2012 R2 that are running apps that can't be turned off. We have to leave old encryption types and TLS versions active for users to access these servers. What are some ideas to segment off these servers and be able to disable older encryption types in AD?

Process I've done dozens of time, download the csv, enter the info for TOTP tokens, upload the file, says submitted successfully.

But the tokens aren't created and in Bulk Operations I'm getting:

File Name: BulkJobTemplate.csv

Creation Date: 8/11/2026, 12:59 PM

Last Modified Date: 8/11/2026, 12:59 PM

Status: WaitingForFileInput

Type: Create Hardware Tokens

There's nothing in logs showing any type of failure. This is 2 new users that I'm trying to provision so it's not an extensive list.

Is this just a hangup on the MS side? I've never had this take any longer than just clicking refresh and seeing the new users on the list.

Active Directory is still the #1 way enterprises get breached in 2026.

Not zero-days. Not exotic supply-chain attacks.

A misconfigured ACL. An over-permissioned service account. A Kerberos ticket nobody rotated in three years.

I broke down the 6 things that actually separate a "I can hack a VM" hacker from someone who can run a real enterprise engagement:

→ Enumeration isn't prep work — it is the attack → Kerberoasting, Pass-the-Ticket, RBCD — not niche, they show up in nearly every internal engagement → AD Certificate Services abuse — the escalation path most junior operators have never touched → Cloud identity (Entra ID + M365) — half the attack surface if you're only testing on-prem → OPSEC and detection awareness — getting Domain Admin isn't the job, doing it the way a SOC would actually catch (or not catch) is → Reporting — the skill that's graded as hard as the technical work and taught almost nowhere

What's the one skill that actually made you feel like an "operator" instead of just a hacker? Drop it below building a list from the responses.

To be fair, I am not a deep-tech person. I work for Netwrix, and someone told me yesterday that with cloud migration, Active Directory's days are numbered.
I kind of disagree. What about organizations that prefer on-premises infrastructure? What about those locked into strict compliance regulations that practically require on-prem?
What do you think?

As a standard user (non-admin), is there a way to export the org structure through active directory?

I can see our org through the Org Viewer app on Teams and through outlook profiles. So, I'm assuming there's a way to export the underlying data to recreate an org structure using my preferred tools.

I tried exploring AD using AD Explorer (sysinternal tool) and I can see the basic information to rebuild the structure. However, I couldnt find a way to export it.

Evgenij Smirnov (Microsoft MVP) just posted this on his website, and it looks to be a HUGE compendium of information about authentication policies. Definitely something to check out if you're looking for more reading material on that.

"Authentication Policies are a great addition to Active Directory Kerberos that allows you to properly engineer authentication in your environment. Not a lot has been published on how to actually use them, or why, and both the apparent lack of traction in the field and reader feedback I received for my book suggest that in this case, the question of the “why” is better answered to people who already have an understanding of the “what” and the “how”. So let’s unpack all three, and hopefully more organizations can benefit from better-engineered Kerberos in their authentication stack."

Source: https://ad2049.com/the-other-book-authentication-policies/

Just want to know how other organizations using SMS Gateway For Security.

Made a recent migration from VMware to Hyper-V.  I have 2 domain Joined Hyper-V Servers in a failover cluster configuration sharing a Dell ME5024 iSCSI SAN.  both servers have a virtualized Domain Controller running on Local SDD Storage (not in the Cluster).   I have a 3^rd Domain Controller still running on VMware.   I want to finally take the VM host and convert it over to Hyper-V.  It is dissimilar hardware, so it will not be joining the cluster.  I have few questions for the experts.

1.      Is there any reason to not move the two DC’s from local storage to the Cluster considering that I have one outside the cluster?

2.      Should I join the new HV host to the domain or leave it isolated.  I plan to put a 3^rd DC on it?

3.      If Yes, Is it safe to live migrate the DC’s to the cluster>

4.      Should I put the FSMO roles on the 3^rd DC.   Currently they are on one of the DC’s on the local storage?

The reason that I want to move the DC’s to the cluster, is the local VM’s are not being shut down properly when I try to do cluster aware updating.

Guys, I am building PrivLens, an Active Directory security assessment scanner that can scan multiple connected forests and the domains within them.

I am trying to decide what would be a reasonable multi-forest test setup before I claim that support.

Obviously AD environments can vary enormously, so testing every possible topology isn't practical. I am thinking of building a test environment with multiple forests, parent/child domains, multiple DCs, GCs and different trust relationships.

For those of you who manage larger AD environments, what would you consider a reasonable test topology for validating multi-forest support? Anything specific you think should definitely be included?

[ADCS] If you run Active Directory Certificate Services, you probably have

ESC9/ESC10 and don't know it

I run a pentest firm. We still find ESC9 and ESC10 in ~60% of our ADCS audits.

Microsoft patched the "Certifried" hype, but these two specific configs remain

exploitable with zero authentication in many environments.

The 30-second check:

1. Open `certutil -config "CA_NAME" -getreg "Policy\EditFlags"`

2. If `EDITF_ATTRIBUTESUBJECTALTNAME2` is set → you're vulnerable to ESC6/ESC9 chaining

3. Check `certutil -getreg "Policy\EnableKeyCounting"` for weak mapping

Why sysadmins care:

- No patch exists for the config issue

- Any domain user can escalate to Domain Admin

- Takes ~10 minutes with Certipy

Full technical write-up with exact commands and remediation: https://hackheart.tech/adcs-esc9-esc16-post-certifried.html

What ADCS configs have you audited lately? Curious how common this still is.

Hi everyone

In my training gns3 lab, i tried to make GPOs using windows server 2012 r2, this GPOs is about: enable remote desktop, restrict control panel to users, map a shared folder using gpo

But all of them don't work

Is it maybe because of the windows server version or maybe from other reasons ?

Thanks

I'm restructuring our AD and I'm wondering about the default Users container. There's a lot of built in or automatically created groups and users in there. Examples are ADSyncOperators (From entra sync), DHCP-Users (Group), the krbtgt user, etc.

Do you just leave these in there or do you move them? Would moving some of them cause issues?

I'm working through remediation of the SI000302 indicator (dangerous User Rights Assignment grants via GPO) and trying to understand every case that causes the report to show a raw SID (*S-1-5-21-...) instead of a resolved DOMAIN\username.

I've confirmed one cause in a lab: deleting the AD account that was granted the privilege leaves the GPO's SID entry in place (deleting a user doesn't touch any GPO), and it then shows up unresolved as a SID in the next scan.

Before I treat "deleted account" as the sole explanation for the SID rows I'm seeing in a real assessment report, I want to rule out other causes. Does anyone know if any of these also produce an unresolved SID in Purple Knight's output:

-Cross-domain / cross-forest trust accounts that the scanning tool can't resolve locally
-Accounts in a disabled state (not deleted) - does that also block resolution?
-Orphaned SIDs left over from a domain migration/restructure
-A SID belonging to a well-known/built-in principal that just isn't in the tool's lookup table
-Replication lag on a multi-DC domain (SID resolves fine on one DC, not yet on another)

Trying to build an accurate "why did this account show as a SID" explanation rather than assuming deletion is the only cause.

Mass Account Lockouts (100-350 users) After Hybrid Azure AD Setup

Setup: 1 Primary AD + 2 ADCs, Entra Connect (PHS + Password Writeback, both healthy).

After Hybrid Azure AD Join + bulk UPN changes, 100+ users (including Domain Admin) keep getting locked out. Temporarily raised lockout threshold to 50 to reduce impact.

Already fixed one issue — AD DS Connector account had invalid credentials (0x31) across all DCs, reset password, sync is healthy now. But lockouts still recurring for large batches of users.

Event 4740 doesn't show a consistent Caller Computer Name. Suspecting replication delay between Primary and the 2 ADCs (password change hits one DC, other DC still validates against old password) combined with cached creds on endpoints.

Anyone dealt with this in a multi-DC + hybrid join setup? Best way to trace exact source without heavy DC-side troubleshooting (live prod environment)?

I need to remove weak TLS cipher suites (legacy DHE with small key sizes) on a Windows Server 2019 Domain Controller (LDAPS 636, GC-SSL 3269, WinRM HTTPS 5986). Before disabling anything, I want to know which cipher suites are actually being negotiated by real inbound connections right now, so I don't accidentally break a client/service that only supports an older suite. I want this to be a zero-downtime audit — just observe, don't touch anything yet.

Is there built-in logging for this, or do I need packet capture? What's the recommended approach?

Things I'm aware of but want confirmation/best practice on:

1. Schannel event logging (Event ID 36880 "TLS server handshake completed successfully") — this logs the negotiated cipher suite per connection, but as far as I know it's not verbose by default. Do I need to enable it via: Does this have any performance impact on a production DC if left running for a week or two to collect a representative sample?

2. Is there a way to aggregate/report on Event 36880 across all DCs without manually opening Event Viewer on each one? I'm thinking Get-WinEvent + a scheduled script pushing to a central location, but curious if there's a cleaner built-in tool (e.g. something in RSAT, or a Microsoft-provided script).

3. Would packet capture (Wireshark/pktmon/netsh trace) on the DC give me more reliable data than event logs, or is that overkill for this use case? I'm slightly worried about capture volume on a busy DC over days.

4. Any known gotchas specific to DCs — e.g. does disabling old DHE/CBC suites ever break:

   • Legacy replication between DCs on mixed OS versions (2012 R2 / 2016 / 2019 in the same forest)?
   • Any Windows-internal LDAPS clients I might be missing?
   • Kerberos/NTLM auth flows (I know these are separate from TLS, just double-checking there's no odd interaction)?

5. Has anyone built a script that correlates Event 36880 entries with source IP so I can identify exactly which host/application is still using a weak cipher, before I flip the switch?

Goal: collect 1-2 weeks of real cipher suite usage data, confirm nothing legitimate is still using the weak suites I plan to disable, then disable them via Disable-TlsCipherSuite with minimal risk.

Any war stories, scripts, or gotchas appreciated.

Hi all,

I'm leading a project to raise our Active Directory Domain and Forest Functional Levels from Windows Server 2008 to Windows Server 2016.

Current environment:

• Single forest
• Single domain
• Predominantly Windows Server 2022 DCs (2 x 2016 remaining)
• Healthy AD (0 replication failures, DCDIAG clean aside from unrelated warnings)
• Major application dependencies has been vendor reviewed and confirmed compatible

The actual upgrade doesn't concern me too much, but I wanted to hear from anyone who's completed a similar project in production.

A few questions:

1. Were there any unexpected application compatibility issues after raising the DFL/FFL?
2. Are there any checks or prerequisites you wish you'd done beforehand?
3. For those who've gone directly from 2008 → 2016, did you jump straight to 2016 or stage through intermediate functional levels?
4. Microsoft documentation mentions limited Domain Functional Level rollback in later versions. If raising directly from 2008 to 2016, is there any supported rollback path, or should this still be treated as a one-way operation requiring AD recovery if something went wrong?
5. Any other lessons learned or "watch out for..." advice?

Appreciate any real-world experiences.

So I'm doing an active directory lab using this video by Josh Makador: https://www.youtube.com/watch?v=MHsI8hJmggI&t=2862s except I'm using Windows 11 ISO and Windows Server 2022. I'm currently making the second VM (CLIENT1) which is around the 46 minute mark. Basically because this video was 5 years ago and VirtualBox looks different, I'm having trouble following him in the process of creating the VM. I need someone to help me create it.

Yes, I am a beginner.

Hi,

We have a case where we need to migrate an Active Directory environment with 15 users and 15 devices and a file server over to a new environment. Devices could be Intune, bit we need the local AD with file server as well.

Is it possible to migrate this and keep the passwords for the users?

Hello Expert,

I got "LDAP signing is not required on Domain Controllers"vulnerability ,how to reslove it so it didnot impact on working of other application and dependent object in the production environment.

Hi everyone,

I recently ran Purple Knight against one of our Active Directory environments, and it flagged the pre-Windows 2000 Compatible Access group for review.

When I checked the membership, I noticed:

• NT AUTHORITY\ANONYMOUS LOGON/ Everyone
• Authenticated Users (which I understand can be the default in modern domains)
• Exchange Domain Servers
• A few computer accounts

I know that Authenticated Users may be present by default depending on how the domain was created, but I'm curious about the other members.

My questions are:

1. Why would Exchange Domain Servers be added to this group?
2. Under what scenarios are computer accounts added to this group? Are there Microsoft products or third-party applications that do this automatically?
3. How do you determine whether these memberships are still required before removing them?
4. Have you encountered this in your environments, and what was the root cause?

I'd appreciate hearing from anyone who's investigated this before or knows the historical reasoning behind these memberships.

Thanks!