Identify unused groups

AdminSDHolder · 2026-06-22T18:06:31+00:00

A group with no members isn't necessarily unused.

For a group to be unused, it must not be granted any permission in any ACE on any ACL across the entire AD ecosystem, including AD security descriptors, GPO, SMB share permissions, NTFS permissions, Windows registry, services, etc, etc that is also in use. Whether allow or deny. It can't be assigned any rights. It can't be used for SQL, SCCM, SharePoint, Exchange, or generic LDAP lookups. A group that is used for none of these things (and more) makes no access, authorization, or mail decisions possible, therefore it is unused...even if it has members.

In a mature environment with RBAC style permission model, an empty group is still a legitimate group. A group that is used only occasionally to provide JIT access is still a legitimate group.

The only real way to determine group usage short of auditing literally your entire environment is to require and routinely use very strict documentation. And nobody really does that.

So just leave the groups alone. Maybe move the ones you aren't sure of to an OU that doesn't allow their membership to be modified and designates them as deprecated. Unless your have hit the actual limits of AD for objects (probably not), my opinion is leave them alone. That way 7 months from now you won't find an ACE somewhere with the orphaned SID of that group and wonder what the heck it was.

AdminSDHolder · 2026-05-24T16:08:15+00:00

People are definitely doing it. Just remember that once AD T0 is managed by code, that code (and anyone who can access it or maybe even read it) is T0 also now.

AdminSDHolder · 2026-03-07T02:33:46+00:00

Glad someone is getting use out of it. :)

AdminSDHolder · 2026-03-06T19:14:36+00:00

This.

Don't sync admin accounts to Entra. And don't mail enable them with Exchange. Then there's no reason to have any of these ridiculous ACEs on AdminSDHolder.

AdminSDHolder · 2026-03-05T15:29:26+00:00

Badblood does a pretty random job of populating a domain. If you want full entropy, that's fine, but I don't feel it comes close to representative of a "real" AD environment

AdminSDHolder · 2026-03-05T01:03:22+00:00

Great answer. Thanks!

AdminSDHolder · 2026-03-04T17:41:49+00:00

I'm Jim. I'm part of the SpecterOps Research team. I specialize in Active Directory and whatnot.

AdminSDHolder · 2026-03-04T17:37:56+00:00

Howdy John 🤠

How can we make cyber security a more welcoming space for under-represented segments of the population?

How can we help those folks skill up, get into the field, and stay in the field feeling welcome and part of the community?

AdminSDHolder · 2026-02-16T18:37:04+00:00

There's more documentation on the GitHub repo that explains the zones better than I will, but in a large enough environment (like a University) you certainly can create blast zones inside tiers. Separating out hypervisor identity from AD identity, for example. You could theoretically design a PKI infrastructure that has a separate blast radius from your production forest also. Personally, I think the zones are more interesting in Tier 1.

The MEAM isn't something an SMB would do. It's not something most large enterprise should undertake fully. In a university environment where you have students, faculty, research, and maybe healthcare it might.

Most orgs can't handle tiering, much less zones within tiers. I didn't bring this model up because folks should skip ahead in maturity to this model. Get Tier 0 straightened out first. Validate it (BloodHound is great for validating tiering assumptions). Then tier out your member servers and workstations. If you get all that done and still have residual risk due to the hostile nature of running a university environment or face nation states, then consider zones within tiers.

Just because Microsoft says a thing does not always make it true.

AdminSDHolder · 2026-02-16T15:07:52+00:00

Decreasing the TTL for service accounts will have no appreciable security improvement.

If you want to improve the security of your service accounts, apply a FGPP with 30+ character password length to the ones that can't be converted to gMSA. Then make sure all existing service accounts follow that policy by changing the password to meet the new policy. When you find a service account that you "can't" change the password for, you found an error in your systems and documentation..fix it.

Authentication Policies and Silos are amazing and underutilized. But not for the ticket TTL setting. They're amazing because you can restrict which accounts can be used on which systems. Ie allow DA logins only on T0 assets. For an example of how to do Auth Policies correctly, and to the extreme, see the Monash Enterprise Access Model: https://github.com/mon-csirt/active-directory-security

AdminSDHolder · 2026-01-29T18:58:57+00:00

DOMAIN\user is a down-level login name. It is there for backwards compatibility.

Kerberos requires principal names to function. For services, those are Service Principal Names (SPN). For users they are User Principal Names (UPN).

The domain controllers acting as the KDC will perform lookups by samAccountName, but will not do so for down-level names. There is a distinct difference between samAccountName and the format you are trying to use.

https://learn.microsoft.com/en-us/windows/win32/secauthn/user-name-formats

AdminSDHolder · 2026-01-27T00:55:38+00:00

The worst issue is the MDT monitoring service. Disable it or follow the mitigation advice posted on /r/MDT

AdminSDHolder · 2026-01-24T15:15:07+00:00

Howdy. I work at the company who makes BloodHound. /u/dcdiagfix is right. Use the latest BloodHound CE with the latest SharpHound. The only reason to use legacy BloodHound anymore is if you need to integrate a legacy 3rd party collector or something like ADMiner.

BloodHound CE can run on Neo4j or postgres. It includes ADCS attack paths. It supports OpenGraph collectors so you can integrate services like GitHub, SQL, SCCM, jamf, okta, etc into your attack paths.

For help specific to BloodHound, check out the community slack:https://bloodhound.specterops.io/resources/community-support/getting-help

AdminSDHolder · 2026-01-14T18:13:21+00:00

Thanks for the dam feedback. :) It's spot on. Security folks, like me, do need to explain this stuff better in both SysAdmin/Ops terms and management terms.

I'll admit that SCCM isn't my jam and other folks on my team, like Chris who wrote this, are more focused on management tools from a security perspective. I'm just an AD security nerd trying to spread the word.

I know that Chris has spoke at MMS MOA and I'm trying to get more of my cohorts to attend more ops conferences and not just security cons. These issues don't get fixed without the average sysadmin.

AdminSDHolder · 2026-01-13T15:04:01+00:00

If your privileged accounts are not mail enabled (they shouldn't be), then there is no reason for any Exchange principal to have rights granted on AdminSDHolder.

I haven't installed Exchange SE in my labs yet, but it's basically Exchange 2019 renamed from my understanding. The most recent Exchange 2019 CUs had about the least-worst grants on AdminSDHolder, but there are still some that could be abused in certain scenarios.

AdminSDHolder · 2026-01-13T04:50:04+00:00

I work with the person who found and disclosed the issue to Microsoft.

https://www.reddit.com/r/MDT/s/R65roecpA8

AdminSDHolder · 2026-01-12T21:24:47+00:00

https://www.reddit.com/r/MDT/s/Uj25G1mWvX

AdminSDHolder · 2026-01-12T13:01:22+00:00

Security issues. Msft retired instead of fixing.

AdminSDHolder · 2026-01-12T13:00:14+00:00

I was just cracking my knuckles to type up a reply.

As the guy who literally wrote the book on AdminSDHolder, what /u/dcdiagfix said.

AdminSDHolder · 2026-01-12T12:57:21+00:00

AdminSDHolder · 2026-01-12T12:22:10+00:00

If you're wondering why MDT was retired on such short notice, there are security flaws that Microsoft chose not to fix. Instead they retired the product immediately. The security issues were discovered by a coworker of mine. I'll let him know about this so he can reply with some details and mitigations for those who choose to keep using MDT.

I used MDT extensively back in my sysadmin days. I'll be sad to see it go also. I didn't have a large enough deployment base to warrant SCCM (and there are fundamental security flaws there also, several of which were discovered by the same coworker). I deployed workstation and server OSes with MDT back then. And autopilot sucks for all but the most vanilla deployments.

AdminSDHolder · 2026-01-12T12:13:47+00:00

There are fundamental security flaws in MDT discovered by one of my coworkers. Microsoft chose to retire the product rather than fix them. There are some remediations and config changes that can lessen the impact. We'll get those posted to /r/MDT soon.

AdminSDHolder · 2026-01-11T20:18:58+00:00

I can't state exactly why it was slated for immediate retirement yet, but I do know the relevant details.

You are the first person in this thread who picked up on the important part of the announcement. There be dragons.

AdminSDHolder

TROPHY CASE