Checking the security of your Active Directory

The checks that matter most in an Active Directory domain (privileged accounts, krbtgt, delegation, Kerberos, LAPS, NTLMv1, LDAP signing), how to verify them yourself, then how to follow them over time

An attacker who gets into a Windows network goes for Active Directory first: whoever controls it controls every machine in the domain. This guide lists the points to check, in order of weight, with the PowerShell commands that give you the answer.

You need the ActiveDirectory module (RSAT tools) and an account that can read the directory. The commands in this guide only read.

1. Privileged accounts

Start by counting the people who can do everything. The groups to examine are Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators and Server Operators. Their names change with the language of the domain; their security identifier (SID) does not.

Members of Domain Admins (SID ending in -512), nested groups included

$sid = "$((Get-ADDomain).DomainSID)-512"
Get-ADGroupMember -Identity $sid -Recursive | Select-Object Name, SamAccountName

What to look at:

the number: beyond about ten active administrators, most of them do not need the rights day to day;
service accounts that belong to a privileged group, whose password is often old and shared between colleagues;
named accounts that are also used to read email and browse the web: an administrator has a separate account for administration;
administrators outside the Protected Users group and without the "Account is sensitive and cannot be delegated" option.

An account that has been a member of a protected group keeps adminCount = 1 after it leaves. These accounts stay apart in the directory and deserve a check.

Accounts flagged with adminCount

Get-ADUser -Filter 'adminCount -eq 1' -Properties adminCount | Select-Object SamAccountName, Enabled

2. The krbtgt account

The krbtgt password is used to sign every Kerberos ticket in the domain. Whoever knows it can forge a valid ticket for any account (a "golden ticket"). In many domains, it has not changed since the domain was created.

Date of the last krbtgt password change

Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object PasswordLastSet

Change it at regular intervals, and after any incident in which a domain controller may have been compromised. The procedure takes two changes: a single one leaves the old password valid. Between the two, let replication reach every domain controller and wait at least the maximum lifetime of a ticket (10 hours by default). Two changes too close together break sessions in progress.

3. Delegation and Kerberos attacks

Unconstrained delegation. A machine that has it keeps in memory the tickets of the accounts that connect to it. Outside domain controllers, it has no place.
Accounts without Kerberos pre-authentication. Anyone can request a ticket for them and try to crack the password offline (AS-REP roasting).
User accounts with an SPN. Their service tickets can be requested freely and cracked offline (Kerberoasting). A long, renewed password, or a group managed service account (gMSA), settles the matter.

Unconstrained delegation, accounts without pre-authentication, accounts with an SPN

Get-ADComputer -Filter 'TrustedForDelegation -eq $true' | Select-Object Name
Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' | Select-Object SamAccountName
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties PasswordLastSet | Select-Object SamAccountName, PasswordLastSet

The first command also lists the domain controllers. For them, unconstrained delegation is normal.

4. LAPS, NTLMv1 and LDAP signing

LAPS. Without LAPS or Windows LAPS, the local administrator account often has the same password on every workstation: one compromised workstation opens all the others. Measure the share of machines whose local password is managed. With Windows LAPS, the msLAPS-PasswordExpirationTime attribute is set on the computer object.

NTLMv1. This protocol is obsolete, and a single captured exchange is enough to recover the account's secret. Domain controllers record the NTLM version in every 4624 logon event.

Latest NTLMv1 logons, on a domain controller

$xpath = "*[System[EventID=4624] and EventData[Data[@Name='LmPackageName']='NTLM V1']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 200 | Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}}

Once the applications involved are fixed, set LmCompatibilityLevel to 5 on the domain controllers: only NTLMv2 is then accepted.

LDAP signing. Without required signing, an LDAP connection can be relayed or altered on the way. The LDAPServerIntegrity value set to 2, under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, requires it. Before enforcing it, look at event 2887 in the Directory Service log: it counts unsigned binds every day, and so the clients that still need fixing.

5. Forgotten accounts

Enabled accounts with no logon for months, passwords that never expire, machines gone from the network, systems past end of support: each one is a door nobody watches.

Enabled user accounts with no logon for 90 days

Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly | Where-Object Enabled | Select-Object SamAccountName, LastLogonDate

LastLogonDate is replicated with a delay of up to 14 days. An account shown as inactive for 80 days may therefore have signed in last week.

6. A one-off check is not enough

An audit takes a snapshot. Between two audits, the gaps come back: a contractor added to Domain Admins for one job and then forgotten, a delegation set up for a test. Two habits change the picture:

review the members of sensitive groups every quarter, with a written decision for each one;
be told as soon as a privileged group changes, instead of finding out at the next audit.

Public tools draw up a one-off assessment, for example ORADAD, published by ANSSI (the French national cybersecurity agency), or PingCastle.

What FirstSI follows

Open SI-Tracer → Active Directory (#/sitracer/ad). The points of this guide make up the Posture score, a mark out of 100 recalculated every day and charted over 180 days.

Point in this guide	FirstSI check
Privileged accounts	10 active administrators at most, administrators outside "Protected Users", orphaned adminCount
krbtgt	password changed less than 180 days ago
Delegation and Kerberos	unconstrained delegation outside domain controllers, accounts without pre-authentication, service accounts with an old password
LAPS, NTLMv1, LDAP	LAPS coverage of at least 90 %, 0 NTLMv1 authentications over 7 days, LDAP signing required, level 5
Forgotten accounts	accounts inactive for 90 days, passwords that never expire, end-of-life systems

Items to address ranks the gaps by severity, and Show the … items lists the accounts or machines involved.

Dangerous actions are reported in real time: addition to a privileged group, delegation added, Kerberoasting, DCSync, group policy changed, security log cleared. The 14 rules are on by default and open their incidents in the SIEM.

The Access review tab prepares the quarterly review and exports it to CSV, with the author and date of each decision. FirstSI changes nothing in the directory: each fix is up to your administrators.

The agent must run on every domain controller, with the SI-Tracer module. You still need to turn on the Directory Service Access audit yourself; without it, DCSync detection stays silent. See Active Directory: security and health.

#1. Privileged accounts

#2. The krbtgt account

#3. Delegation and Kerberos attacks

#4. LAPS, NTLMv1 and LDAP signing

#5. Forgotten accounts

#6. A one-off check is not enough

#What FirstSI follows

#Further reading