May 19 2026

AD Fundamentals: Group Policy Permissions & Owner Rights

This series of posts focuses on key Active Directory (AD) components that need to be secured in order to ensure AD security is leveled up. In this post, we focus on Group Policy Objects (GPOs) and their permissions.

Group Policy provides the ability to change application settings, security settings, install and run code, and more! As such it’s a powerful tool for the administrator as well as the attacker/adversary.

Continue reading

May 13 2026

AD Fundamentals: Domain Root & AdminSDHolder Permissions

This series of posts focuses on key Active Directory (AD) components that need to be secured in order to ensure AD security is leveled up. this post focuses on permissions on two important objects in AD: the Domain root and the AdminSDHolder object.

Domain Root

Let’s start with the domain root. The domain is the container for all domain objects and on the domain object itself, there are permissions in a similar manner to any object in Active Directory. What makes the Domain root object special is that any permissions set here are inherited by default on objects below it which means that permissions here can affect all domain objects: users, computers, groups, etc. Note that permissions set at the domain level do not apply to AdminSDHolder protected objects, such as Domain Admins and DA members, but can apply to Domain Controllers and Read-Only Domain Controllers.

Continue reading

May 12 2026

AD Fundamentals: DSHeuristics

This series of posts focuses on key Active Directory (AD) components that need to be secured in order to ensure AD security is leveled up. In this post, we focus on the mostly unknown AD component called DSHeuristics

DSHeuristics is like a registry editor for changing behavior in the Active Directory forest (and AD Lightweight Directory Service, aka LDS).

This PowerShell code gets the current DSHeuristics value:

Import-Module ActiveDirectory

$ds = Get-ADObject `
    -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" `
    -Properties dsHeuristics

$ds.dsHeuristics

By default, the attribute doesn’t exist. If it is set to 0, there’s no change to behavior.

Continue reading

May 06 2026

AD Fundamentals: Pre-Windows 2000 Compatible Group

This series of posts focuses on key Active Directory (AD) components that need to be secured in order to ensure AD security is leveled up. In this post, we focus on the often-misunderstood group called “Pre-Windows Compatible”.

This domain-scoped group is created automatically in the Built-in root OU and is part of any Active Directory forest controlling anonymous access to AD. Its original intent was to provide a migration path from using a Windows NT domain to Active Directory, thus the compatible word in the name. Members of this group have read access to all users and groups in the domain.

Continue reading

May 05 2026

AD Fundamentals: Domain Controller Security

This series of posts focuses on key Active Directory (AD) components that need to be secured in order to ensure AD security is leveled up. In this post, we focus on Domain Controller configuration.

Tier 0

Domain Controllers need to be managed and maintained as Tier 0 servers since they handle authentication and authorization for the organization. Tier 0 being the highest tier that requires nothing outside of this be in the tier including users, groups, and computers. Only AD admins as Tier 0 accounts should be able to manage Domain Controllers. Any system outside of this is in violation of the Tier 0 principal whether it be management, inventory, security, or virtualization administration.

Supported Windows Version

The first key item is ensuring that all Domain Controllers (DCs) are running on supported Microsoft Windows operating system versions. At this point, DCs should be running at least Windows Server 2019, preferably Windows Server 2022 or 2025. The table below shows that Windows Server 2016 & 2019 have ended mainstream support. Windows Server 2019 has extended support until January 2029.

Continue reading

Mar 02 2026

Detecting Fake Active Directory Password Changes

In Active Directory, there has been a method that’s been around for many years which changes the password last set date but not the actual password. This is what I call a “fake password change” since the account appears to have a recent password when scanning for old passwords based on password last set, but the underlying password hasn’t actually changed.
I spoke about this in my 2015 BSides Charm talk which was my first conference talk.

Why does this happen?
There are times where service account (or admin accounts) need to have password changes, but someone doesn’t want to do the work to change them. The ability to fake a password change requires modify rights on the pwdLastSet attribute which provides the ability to check/uncheck the setting “User must change password at next logon”. This setting is enabled when you want the user to change their own password when they logon.


How does this work?

To see how this works, we’ll focus on the service account “svc-AGPM” in my lab. This account last changed its password on August 20th in 2025.

Continue reading

Jan 20 2026

Active Directory Security Tip #16: Mitigating Kerberoast Attacks

There are two main password attacks leveraged by adversaries; one is called Password Spraying and the other is called Kerberoasting.

This post focuses on identifying accounts that may be targeted for Kerberoasting and how to harden the environment against Kerberoasting.

Continue reading

Dec 02 2025

Active Directory Security Tip #15: Active Directory Domain Root Permissions

This week let’s look at Active Directory domain permissions which are configured on the domain root and apply to the domain. There are many different type of concerning permissions, but let’s look at the most egregious.

Continue reading

Nov 04 2025

Active Directory Security Tip #14: Group Managed Service Accounts (GMSAs)

Group Managed Service Accounts (GMSAs)

User accounts created to be used as service accounts rarely have their password changed. Group Managed Service Accounts (GMSAs) provide a better approach (starting in the Windows 2012 timeframe). The password is managed by AD and automatically changed. This means that the GMSA has to have security principals explicitly delegated to have access to the clear-text password. Much like with other areas where delegation controls access (LAPS), determining who should have be delegated access needs to be be carefully considered.

Key Points for Group Managed Service Accounts (GMSAs)

  • The GMSA password is managed by AD.
  • Computers hosting GMSA service account(s) request the current password from Active Directory to start the associated service.
  • Configure the GMSA to allow computer account(s) access to the GMSA password.
  • If an attacker compromises any computer hosting services using the GMSA, the GMSA is compromised.
  • If attacker compromises an account with rights to request the GMSA password, the GMSA is compromised.
Continue reading

Oct 19 2025

Improve Entra ID Security More Quickly

At BSides Northern Virginia (BSides NoVa) in October 2025, I presented a talk on how to improve Entra ID security quickly. This post captures the key information from my talk slides.

This article describes the Entra ID settings and configuration that should be set to improve security including:

  • User Default Configurations
  • Guest Defaults
  • User Applications Consent and Permissions
  • Secure Entra ID roles
  • Privileged Role Membership Protection
  • Role Assignable Group Configurations
  • Highly Privileged Applications
  • Conditional Access Policies
  • Partner Access
  • Securing Entra Connect
  • Secure Entra ID Quickly Checklist
Continue reading

Load more