Sep 19 2025

Active Directory Security Tip #7: The Tombstone Lifetime

The Tombstone lifetime (TSL) in Active Directory is the limit as to how long a deleted object can remain in AD. The original value was 60 (days). Windows versions since Windows 2003 SP2 have this set to 180 (days). Note that this also affects backups, how long a backup is valid and replication – if a DC doesn’t replicate with its partner(s) within the TSL, the other DCs will ignore it. https://adsecurity.org/?p=81

If you have an environment with it still set to 60, I recommend you update it to 180 days. This may slightly bloat AD since deleted objects will linger longer, but it does provide a fail-safe of sorts if you need to recover going back >60 days.


PowerShell code using the AD PowerShell module to determine the Tombstone lifetime: 

$ADRootDSE = Get-ADRootDSE
$ADConfigurationNamingContext = $ADRootDSE.configurationNamingContext
    
$TombstoneObjectInfo = Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$ADConfigurationNamingContext" -Partition "$ADConfigurationNamingContext" -Properties * 
[int]$TombstoneLifetime = $TombstoneObjectInfo.tombstoneLifetime

IF ($TombstoneLifetime -eq 0) 
 { $TombstoneLifetime = 60 }

Write-Host "The AD Forest Tombstone lifetime is set to $TombstoneLifetime days."

Sep 18 2025

Active Directory Security Tip #6: Domain Controller Operating System Versions

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.

Hold off on deploying Windows Server 2025 DCs for now due to the dMSA issue (https://akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory).


Active Directory PowerShell code for Domain Controller operating system versions & site location for the current domain:

$Domain = $env:userdnsdomain
$DomainDC = (Get-ADDomainController -Discover -DomainName $Domain).Name
$DomainDCs = Get-ADDomainController -Filter * -Server $DomainDC
$DomainDCs | Select HostName,IPv4Address,OperatingSystem,Site | Sort HostName | Format-Table -AutoSize

Sep 17 2025

Active Directory Security Tip #5: The Default Domain Administrator Account

In every Active Directory domain, there’s the default domain Administrator account.
Here are some key items to check:

  • Do you know when the last time the Administrator account was used (logged into)?
  • The last time its password was changed? Is it current?
  • How the password is managed and stored?
  • Does it have an associated Kerberos Service Principal Name (SPN)? (it shouldn’t)
  • Is it enabled? (it’s probably fine if it is)


PowerShell for current domain using the AD PowerShell cmdlets: 

$Domain = $env:userdnsdomain
$DomainDC = (Get-ADDomainController -Discover -DomainName $Domain).Name
Get-ADUser "$((Get-ADDomain).DomainSID)-500" -Properties Name,Enabled,Created,PasswordLastSet,LastLogonDate,ServicePrincipalName,SID -Server $DomainDC


Sep 16 2025

Active Directory Security Tip #4: Default/Built-In Active Directory Groups

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.

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups


PowerShell Script leveraging the Active Directory PowerShell module:
https://github.com/PyroTek3/Misc/blob/main/Get-ADBuiltInAdmins.ps1

Sep 16 2025

Active Directory Lab Build Script

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.

Continue reading

Sep 16 2025

Detecting Active Directory Password Spraying Article

I recently published an article on the TrustedSec blog site called “Detecting Active Directory Password-Spraying with a Honeypot Account“. This article describes how to use an Active Directory honeypot account in order to detect Password Spraying.

Read the article here:
https://trustedsec.com/blog/detecting-password-spraying-with-a-honeypot-account

Sep 15 2025

Active Directory Security Tip #3: Computer Accounts

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): 

$Domain = $env:userdnsdomain
$DomainDC = (Get-ADDomainController -Discover -DomainName $Domain).Name
Get-ADComputer -filter * -Prop name,OperatingSystem,LastLogonDate,PasswordLastSet -Server $DomainDC | sort OperatingSystem | select name,OperatingSystem,LastLogonDate,PasswordLastSet

Sep 15 2025

Active Directory Forest & Domain Level Capabilities

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.
You can easily check the domain & Forest functional levels using the Active Directory PowerShell module using the cmdlets Get-ADForest & Get-ADDomain.

Get-ADForest


Get-ADDomain

Continue reading

Sep 14 2025

Active Directory Security Tip #2: Active Directory User Accounts

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.


PowerShell code (using Active Directory PowerShell module):
https://github.com/PyroTek3/Misc/blob/main/Get-VulnerableUserAccounts.ps1

Sep 12 2025

Active Directory Security Tip #1: Active Directory Admins

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.


PowerShell code (using Active Directory PowerShell modules):
https://github.com/PyroTek3/Misc/blob/main/Get-ADAdmins.ps1

Load more