My BSides NoVA talk on Saturday, October 11, 2025 was titled “10 Ways to Improve Entra ID Security Quickly“. I focused on the areas that tend to be missed in Entra ID.Talk slides are now …
Review the membership of groups for accounts and groups from another Active Directory forest (technically another domain, but using forest here). These are called “Foreign Security Principals” (FSPs) like the ones highlighted in the image. …
I have mentioned in several presentations that Kerberos delegation is impersonation. Kerberos delegation is used when a service (ex. web server) needs to impersonate a user when connecting to a resource (ex. database). There are …
During the Summer of 2024, I had a talk at Troopers called “A Decade of Active Directory Attacks:What We’ve Learned & What’s Next” (Slides & Video) where I focused on the key milestones of Active …
Ensuring proper Domain Controller configuration is key for Active Directory security.
Part of this is making sure they are running supported versions of Windows. At this point, DCs should be running at least Windows Server 2016, preferably Windows Server 2019 or 2022.
There are several default/built-in privileged groups that should be reviewed:
Account Operators – should be empty per Microsoft due to highly privileged access in AD.
Backup operators – should only contain backup service accounts to backup and restore Active Directory.
Cert Publishers – should only contain PKI related accounts (CAs & related service accounts) since it can publish certificates for AD users.
DNSAdmins – typically only used when admins other than ADAs perform DNS administration. Use sparingly. * Enterprise Key Admins – have admin rights on key objects in AD.
Event Log Readers – should only include accounts that require access to Domain Controller event logs.
Group Policy Creator Owners – can modify Group Policies in the domain. Membership should be empty and rights delegated instead.
Print Operators – used only when a Domain Controller is used as a print server (which shouldn’t happen). Group has the ability to logon to Domain Controllers and install drivers which makes this group highly privileged. Group should be empty.
Server Operators – effectively local admin on Domain Controllers. Use sparingly.
Schema Admins – should be empty except when updating the AD schema.
Over the summer, I rebuilt my Active Directory lab environment with multiple regional domains. Instead of manually configuring common issues, I decided to create a PowerShell script to do this for me.
Active Directory computers should be reviewed about once a year. Old operating systems can hold back security progress like keeping SMBv1 and NTLMv1 active. Inactive computers should be discovered and disabled when no longer in use (and eventually removed).
The OperatingSystem & PasswordLastSet attributes are self-explanatory, though we can use the LastLogonDate which represents the last reboot of the computer. The computer password should change every ~30 days by default. We can correlate the PasswordLastSet & LastLogonDate attribute values to determine if a computer is active or not. A blank LastLogonDate value means the computer object is just that and not associated with an actual system. Computer Password Information
PowerShell code (using the Active Directory PowerShell module):
An important Active Directory setting determines what security capabilities are available which relates to the level of the forest and/or domain. This post collects the relevant capabilities of Windows domain and forest functional levels.
There are several different types of user accounts – at least how they are used. There are standard user accounts, service accounts, and admin accounts.
There are numerous user account settings that can make them vulnerable. These configurations include:
Inactive – account has not logged on or changed the password in over 180 days which may flag this account as inactive/stale – Accounts known to be inactive should be disabled.
Reversible encryption – effectively clear-text on DCs – there’s no reason for this to be set.
Password not required – account may not have an associated password – possibly set by provisioning system – There’s no reason for this to be set. * Password never expires – password very likely to be old – should not be set on standard user accounts.
Kerberos DES encryption enabled – DES is a weaker encryption method which enables faster password brute-forcing. There’s no reason for this to be set.
Account does not require Kerberos pre-authentication – enables a trivial attack method for discovering the account’s password (AS-REProasting). May have been set for a compatibility issue with an application. Kerberos pre-authentication should always be required.
Account cannot change password – password may not change. Standard user accounts should not have this set. Attackers will look for these configurations, so best to review and adjust regularly. Admin accounts and service accounts require additional protection above and beyond standard user accounts.
A critical part of Active Directory security is regularly reviewing your AD admins. The simplest way to do this is to recursively enumerate the membership of the domain Administrators group (that group’s members and all member group members).
Check the AD Admins output for the following:
Are all the admin accounts associated with people expected?
Are there service accounts that shouldn’t require AD admin rights (VMware, Exchange, LDAP, VPN, Sharepoint, etc.)?
Are the associated passwords current?
Are they as expected with no outliers (all within 2 years but one has a password that’s 10 years old)?
Has the default domain Administrator account logged on recently?
Is that expected/known?
Are all accounts enabled?
Disabled accounts should be removed from being an AD Admin.
Do all accounts require Kerberos preauthentication?
They must if they are AD admins.
Do any use Kerberos DES?
If so fix that.
Are any set to never expire their password?
Is that expected?
Accounts with this set rarely change their password.
Are there any passwords in Active Directory user attributes (commonly description notes/info, Exchange custom attributes, etc.)?
Practically all of the attributes are visible to users.
This article was originally posted on the Trimarc Content Hub on August 6, 2020. Updated here with authentication PowerShell code on August 18, 2025. ADSecurity.org is the new home for this article and all updates will occur here.
I have had the idea for a post describing how to best create a honeypot (or honeytoken) account for many years and only recently gained enough clarity around how to format and structure such an article for it to be useful. Shout-out to Carlos Perez (@Carlos_Perez) for a recent chat about Kerberoasting and the Detecting Kerberoast article I posted a while back which got me thinking enough about this to start writing.
This article covers how to create accounts used as honeypots (or honeytokens) that look like they provide something an attacker wants (access), but ultimately provides something the defender wants (detection). The focus is making honeypot accounts look normal and “real” in Active Directory and this premise should be somewhat portable to other systems.
AD Recon 101 I have previously covered AD recon in presentations (DEF CON 2016: Beyond the MCSE, Red-Teaming Active Directory), but provide expanded detail here focused on privileged AD account recon. When an attacker is performing reconnaissance of Active Directory, there are a few key items to review:
Identify Privileged Accounts
Identify Privileged Accounts with Old Passwords
Identify Privileged Accounts with Kerberos Service Principal Names (SPNs)
Identify Privileged Accounts with Network Sessions on Regular Workstations
In most Active Directory environments, we can scan the AD forest for all of these as a regular AD user (and in some cases without valid AD credentials).
1. Identify Privileged Accounts
Let’s start with #1. We can either recursively enumerate the Administrators group in every domain in the AD forest or we can scan all AD user accounts in each domain that have the user attribute “AdminCount” set to 1. I presented about how useful the AdminCount attribute can be in 2015 (DerbyCon – “Red vs Blue Active Directory Attack & Defense”).
The AdminCount attribute is automatically set to 1 on any AD accounts that are added to privileged AD groups such as Administrators, Domain Admins, Enterprise Admins, etc. The limiting factor in the usefulness of this technique is that we may also find accounts that used to be in a privileged AD group but no longer a member. This means that scanning for AD accounts with AdminCount=1 provides a quick list of potentially privileged accounts (without group enumeration).
Recent Comments