AS-REP Roasting Mitigation: Enable Kerberos Pre-Authentication on AD Accounts

The Nessus finding “AD Starter Scan – Kerberos Pre-authentication Validation” means an Active Directory account has “Do not require Kerberos preauthentication” set, so anyone who knows its name can request data encrypted with a key derived from its password and crack it offline. The AS-REP roasting mitigation: clear the flag with Set-ADAccountControl -DoesNotRequirePreAuth $false.

The flag is rarely set on purpose today. It usually survives from an old UNIX or appliance integration, a migration, or a test. Below: what each scanner reports, how to find the affected accounts and whether anything still depends on them, the fix for users and computers, and how to prove it on rescan.

What the scanner is actually detecting

Every tool reads the userAccountControl attribute and reports accounts where the DONT_REQ_PREAUTH bit (0x400000, decimal 4194304) is set. Microsoft’s UserAccountControl flag reference describes it as an account that does not require Kerberos pre-authentication for logging on.

The Nessus plugin runs from the Active Directory Starter Scan template, which Tenable documents as needing Domain Admin credentials, LDAPS, and a domain controller as the scan target. Tenable also states results are accurate for deployments up to 5,000 users, groups or machines and incomplete above that.

Real-world risk, stated honestly

Normally a client proves it knows the password (an encrypted timestamp) before the domain controller issues a ticket. With the flag set, the KDC answers an AS-REQ for that account without any proof, and part of the reply is encrypted with a key derived from the account’s password. The attacker takes it offline and guesses at whatever speed their hardware allows. MITRE ATT&CK tracks this as T1558.004 (AS-REP Roasting).

What makes it worth fixing: the attacker needs only network access to a domain controller and the account name. MITRE notes a valid domain account is needed to enumerate flagged accounts over LDAP, but individual names can simply be tried. No wrong password is ever submitted, so there are no failed logons or lockouts, only a successful event 4768 with Pre-Authentication Type 0 on the DC if auditing is on.

What limits it: success depends entirely on the password. A random password of 25 or more characters is not a practical cracking target; a human-chosen password set years ago may be. Computer accounts normally have machine-generated passwords, so a flagged computer is low risk, although the flag has no purpose there. The dangerous case is S-NoPreAuthAdmin: one cracked privileged password can mean the domain. Remember too that clearing the flag stops new requests but does not undo a password that was already cracked.

How to confirm it in your domain

Run this from a machine with the RSAT ActiveDirectory module. It is the same LDAP filter PingCastle documents, covers users and computers, and saves a before snapshot you will need for rollback:

Import-Module ActiveDirectory
$f = '(userAccountControl:1.2.840.113556.1.4.803:=4194304)'

$users     = Get-ADUser -LDAPFilter $f -Properties userAccountControl, adminCount, PasswordLastSet, LastLogonDate
$computers = Get-ADComputer -LDAPFilter $f -Properties userAccountControl, PasswordLastSet, LastLogonDate

@($users) + @($computers) |
    Select-Object SamAccountName, ObjectClass, Enabled, userAccountControl, adminCount, PasswordLastSet, LastLogonDate, DistinguishedName |
    Export-Csv .nopreauth_before.csv -NoTypeInformation

For a quick count, Get-ADUser -Filter ‘DoesNotRequirePreAuth -eq $true’ reads the same bit. An adminCount of 1 hints that an account is or was privileged; PingCastle’s S-NoPreAuthAdmin list is the accurate split.

Before changing anything, find out whether something still logs on without pre-authentication. Check that Kerberos authentication auditing is on, then search each domain controller’s Security log:

auditpol /get /subcategory:"Kerberos Authentication Service"

Get-WinEvent -LogName Security -MaxEvents 200 `
    -FilterXPath "*[System[EventID=4768] and EventData[Data[@Name='PreAuthType']='0']]" |
    ForEach-Object {
        $d = @{}
        ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        [pscustomobject]@{ Time = $_.TimeCreated; Account = $d.TargetUserName; Client = $d.IpAddress }
    }

Microsoft’s event 4768 reference defines type 0 as a logon without pre-authentication and says all accounts should use it. A flagged account that never shows up here has no live dependency. “No events were found” is a good result, provided auditing was enabled.

How to fix it

User accounts, PowerShell

Test one account, then apply it. Set-ADAccountControl sets the ADS_UF_DONT_REQUIRE_PREAUTH flag directly and accepts accounts from the pipeline:

Set-ADAccountControl -Identity svc-legacy -DoesNotRequirePreAuth $false -WhatIf
Set-ADAccountControl -Identity svc-legacy -DoesNotRequirePreAuth $false

# all flagged users at once
Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=4194304)' |
    Set-ADAccountControl -DoesNotRequirePreAuth $false

Point it at a writable domain controller (add -Server if needed); Microsoft notes the cmdlet does not work against a read-only DC or the global catalog port.

User accounts, GUI

In Active Directory Users and Computers, open the account, go to the Account tab, and under Account options untick Do not require Kerberos preauthentication.

Computer accounts

Computers have no Account tab. The same cmdlet works on computer objects:

Get-ADComputer -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=4194304)' |
    Set-ADAccountControl -DoesNotRequirePreAuth $false

Or, as PingCastle suggests, enable View > Advanced Features, open the Attribute Editor tab and subtract 4194304 from userAccountControl. A workstation at 4198400 goes back to 4096; a normal user at 4194816 goes back to 512.

Accounts that were exposed for a long time

If a flagged account’s PasswordLastSet is old, or the password was chosen by a person, reset it after clearing the flag. You cannot tell whether an AS-REP was already captured.

When a legacy client genuinely needs it

Microsoft notes that some MIT Kerberos clients do not answer the domain controller’s pre-authentication request. If a client like that cannot be upgraded, keep the exception narrow:

• A random password of 25 characters or more, in line with MITRE’s guidance for service account passwords.
• No membership in any privileged group, and only the rights the application needs.
• AES only (Set-ADUser svc-legacy -KerberosEncryptionType AES128,AES256) if the client supports it. MITRE lists AES over RC4 as a mitigation; it slows cracking, it does not prevent it.
• An alert on event 4768 with Pre-Authentication Type 0 for this account from any address other than the known client.

Catch the flag coming back

Anyone with write access to an account’s userAccountControl can turn the flag on again. Enable Audit User Account Management on domain controllers: event 4738 records ‘Don’t Require Preauth’ – Enabled, which Microsoft says should not be enabled for user accounts.

How to verify the fix and rescan

1. Re-run the inventory against the domain controller your scanner targets (-Server dc01.example.com) so replication lag does not mislead you. It should return nothing, or only documented exceptions.
2. Spot-check one account: Get-ADUser svc-legacy -Properties DoesNotRequirePreAuth should show False.
3. Rerun the Active Directory Starter Scan against the same DC with the same credentials and confirm plugin 150482 no longer lists the accounts. Check that the scan actually bound over LDAPS; a scan that could not read the directory reports nothing either.
4. Run a new PingCastle healthcheck (PingCastle.exe –healthcheck –server corp.example.com) and confirm S-NoPreAuth and S-NoPreAuthAdmin are gone.

What can break and how to roll back

• Windows clients: nothing. They already pre-authenticate; type 2 (PA-ENC-TIMESTAMP) is the normal value in event 4768.
• Legacy non-Windows clients that never send pre-authentication data fail to obtain a ticket, and the application using that account stops authenticating. A client that still holds a valid ticket may not fail until that ticket expires, so watch for a day.
• Nothing else changes: no password reset (unless you choose one), no reboot, no service restart.

To roll back one account, take its entry from the before snapshot and run Set-ADAccountControl -Identity svc-legacy -DoesNotRequirePreAuth $true, then apply the exception rules above. A password reset cannot be rolled back, so update every system that stores the account’s password before you reset it.

Common false positive reasons

• Disabled accounts. Nessus lists them only with thorough tests enabled, and PingCastle ignores them. A disabled account cannot get a ticket, but re-enabling it restores the exposure, so clear the flag anyway.
• Honeypot accounts. Some teams set the flag deliberately on a decoy account to catch roasting attempts. PingCastle skips accounts registered as honeypots; Nessus does not, so record it as an accepted finding.
• Scanners disagree. PingCastle splits admins and non-admins into two rules and skips disabled accounts; above 5,000 objects Nessus results are incomplete. Different lists are expected.
• Identity Exposure still open. C-KERBEROS-CONFIG-ACCOUNT also covers DES and reversible encryption, so it can stay open after the preauth flag is gone.
• Not a false positive: “the password is strong”. That lowers the risk, it does not remove the flag. Document it as an exception.

FAQ

Does AS-REP roasting need a domain account?

Not if the attacker already knows the username. A domain account only makes it easier to find which accounts carry the flag.

Is this the same as Kerberoasting?

No. Kerberoasting requests a service ticket for an account with an SPN and requires an authenticated user. AS-REP roasting targets the initial logon reply of accounts without pre-authentication. Both end in offline password cracking, and both are defeated by long random passwords.

Will clearing the flag lock anyone out?

No. It changes no password and affects only clients that cannot pre-authenticate, which the event 4768 check reveals in advance.

Should computer accounts ever have this flag?

There is no normal reason. Clear it; PingCastle reports computers under the same rule. Kerberos hardening often happens alongside legacy authentication cleanup, and our guide on how to disable NTLM safely follows the same audit-first approach.

Tracking this finding across many hosts

If you track results in SITEY, import the .nessus export from the AD Starter Scan (Nessus results are uploaded, not pulled automatically), let AI triage suggest false positives with evidence for a human to decide, and re-test the individual Nessus finding once the flag is cleared. Duplicates are merged per scanner, not across scanners, so an account reported by two tools appears once for each.

Sources

• Tenable: Nessus plugin 150482, AD Starter Scan – Kerberos Pre-authentication Validation
• PingCastle: rule descriptions, including S-NoPreAuth and S-NoPreAuthAdmin
• Microsoft Learn: Set-ADAccountControl
• Microsoft Learn: Event 4768, A Kerberos authentication ticket (TGT) was requested
• MITRE ATT&CK: T1558.004, AS-REP Roasting