Getting Microsoft supported backups of Domain Controllers is an important part of recovery strategy. A best practice is to locate all Flexible Master Single Operator (FSMO) roles on a single DC in the domain. That …
Microsoft supported backups of Active Directory are very important to have. For backing up Domain Controllers, this is typically a System State backup. Why a Microsoft supported backup? If you are using a backup solution …
The domain Kerberos service account, KRBTGT (https://adsecurity.org/?p=483), is an important account since it is used to sign & encrypt Kerberos tickets. The account is disabled and the password doesn’t change except when moving from Windows …
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 …
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 …
Getting Microsoft supported backups of Domain Controllers is an important part of recovery strategy.
A best practice is to locate all Flexible Master Single Operator (FSMO) roles on a single DC in the domain. That way you can more easily target the DC that hosts the FSMOs for backup.
PowerShell code to check for FSMO role holders for the forest & current domain:
Microsoft supported backups of Active Directory are very important to have. For backing up Domain Controllers, this is typically a System State backup.
Why a Microsoft supported backup? If you are using a backup solution that isn’t fully AD aware, performing a restore may involve getting Microsoft involved and that costs $$.
I know companies that have used ####### (redacted) to backup their AD and there was no System State and the backup wasn’t a full AD aware backup so they ended up paying ###### $$$ and Microsoft $$$. Just get a System State backup of the DCs that host your FSMO roles about every month and be prepared for a scenario where you may have to restore AD.
Determining if a recent supported backup has been performed is easy since these backups update a bit in each partition.
PowerShell code to check the current domain for the last Microsoft supported AD backup:
$ContextType = [System.DirectoryServices.ActiveDirectory.DirectoryContextType]::Domain
$Context = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext($ContextType,(Get-ADDomain).DNSRoot)
$DomainController = [System.DirectoryServices.ActiveDirectory.DomainController]::findOne($Context)
[string[]]$Partitions = (Get-ADRootDSE).namingContexts
foreach ($Partition in $Partitions)
{
$dsaSignature = $DomainController.GetReplicationMetadata($Partition).Item("dsaSignature")
Write-Host "$Partition was backed up $($dsaSignature.LastOriginatingChangeTime.DateTime)"
}
The domain Kerberos service account, KRBTGT (https://adsecurity.org/?p=483), is an important account since it is used to sign & encrypt Kerberos tickets. The account is disabled and the password doesn’t change except when moving from Windows 2000/2003 to Windows Server 2008 (or newer).
This is a highly privileged account and if an attacker can gain knowledge of the account’s password hash (or password), they can create forged Kerberos tickets (aka Golden Tickets: https://adsecurity.org/?p=1640).
Most AD forests have this account lingering with old passwords. The KRBTGT account stores two passwords, the current one and the previous one and checks them both to validate Kerberos tickets. This means that to ensure that the KRBTGT passwords are fully changed, the password must be changed twice. If an attacker can capture a DC backup that is as old as one of the KRBTGT account passwords (say 15 years), then they can compromise the environment even if the backup is 15 years old!
We can use the “msds-keyversionnumber” attribute to determine how many times the KRBTGT password has changed. The formula n – 2 works to calculate how many times the password has changed. If this value is 2 it hasn’t changed since it was originally set when the domain was created. If the value is 9, then it has changed 7 times (9 – 2 = 7). Sometimes this value is very large, like 100003. In that case we just use the last digit (3) to calculate the number of times it has changed: n – 2 = 1, so it has changed 1x.
We recommend changing the password once, then waiting at least a week, and then changing the password again. When you set the password, a process on the DC actually changes the KRBTGT password to a fully random password.
PowerShell code to report on the KRBTGT account for the current domain:
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."
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.
Recent Comments