AS-REP Roasting in Active Directory – Secure Active Directory

AS-REP Roasting is an Active Directory attack technique that targets user accounts configured with Kerberos preauthentication disabled. When preauthentication is not required, an attacker can request Kerberos authentication data for the account and attempt to crack it offline to recover the user’s password.

AS-REP Roasting is dangerous because it does not require administrative privileges. In many cases, an attacker only needs network access to a domain controller and the name of a vulnerable account. If the targeted account has a weak password, old password, or excessive privileges, the result can be serious.

What is Kerberos preauthentication?

Kerberos preauthentication is a security feature that helps prove a user knows their password before the domain controller returns certain Kerberos authentication data.

In a normal Kerberos authentication flow, the user does not simply receive a Ticket Granting Ticket without first proving knowledge of the account secret. Preauthentication helps prevent attackers from requesting encrypted authentication material for arbitrary users and then cracking it offline.

In Active Directory, the relevant account option is: Do not require Kerberos preauthentication

When this option is enabled on a user account, Kerberos preauthentication is disabled for that account. Microsoft documents the related UserAccountControl flag as DONT_REQUIRE_PREAUTH, which means the account does not require Kerberos preauthentication for logging on.

What is AS-REP Roasting?

AS-REP Roasting abuses accounts that do not require Kerberos preauthentication.

The attack flow looks like this:

The attacker identifies a user account with Kerberos preauthentication disabled.
The attacker sends a Kerberos authentication request for that account.
The domain controller returns authentication data encrypted with key material derived from the user’s password.
The attacker captures that response.
The attacker attempts to crack it offline.
If successful, the attacker recovers the plaintext password for the account.

MITRE ATT&CK tracks AS-REP Roasting as T1558.004, under Steal or Forge Kerberos Tickets.

The important part is that the cracking happens offline. Once the attacker has the AS-REP response, they can attempt password cracking without repeatedly contacting the domain controller.

Why AS-REP Roasting matters

AS-REP Roasting matters because it can expose user passwords without requiring the attacker to authenticate as that user.

The risk is highest when vulnerable accounts have:

Weak passwords
Old passwords
Passwords reused across systems
Privileged group membership
Access to servers, applications, or sensitive data
No clear ownership
No normal password rotation process

A low-privilege account with preauthentication disabled is still a risk. A privileged account with preauthentication disabled is much more serious.

If an attacker cracks the password, they may be able to use the account for lateral movement, data access, privilege escalation, or further credential attacks.

Why would preauthentication be disabled?

In modern Active Directory environments, Kerberos preauthentication should normally be enabled. However, it may be disabled for legacy compatibility or because of old application requirements.

Common reasons include:

Legacy applications
Old Unix or Linux integrations
Misconfigured service accounts
Historical troubleshooting changes
Unsupported authentication workflows
Accounts migrated from older environments
Administrators enabling the setting without understanding the risk

In many environments, accounts with preauthentication disabled are not intentionally maintained. They are simply forgotten.

AS-REP Roasting vs Kerberoasting

AS-REP Roasting and Kerberoasting are related because both can lead to offline password cracking, but they target different account conditions.

Attack	Target	Main condition	Requires valid domain credentials?	Offline cracking?
AS-REP Roasting	User accounts	Kerberos preauthentication disabled	Not always	Yes
Kerberoasting	Service accounts with SPNs	Account has a Service Principal Name	Usually yes	Yes

Kerberoasting targets accounts with SPNs. AS-REP Roasting targets accounts that do not require Kerberos preauthentication. Both attacks become much more dangerous when the targeted account has a weak password or excessive privileges.

How attackers identify vulnerable accounts

Attackers look for accounts where the DONT_REQUIRE_PREAUTH flag is set. In Active Directory Users and Computers, this appears as: Do not require Kerberos preauthentication. In PowerShell, it is commonly shown as DoesNotRequirePreAuth.

The presence of this setting does not mean the account is compromised. It means the account is roastable and should be reviewed.

PowerShell: Find accounts without Kerberos preauthentication

Use this PowerShell command to identify enabled users that do not require Kerberos preauthentication:

Get-ADUser -Filter { DoesNotRequirePreAuth -eq $true -and Enabled -eq $true } `
    -Properties DoesNotRequirePreAuth, PasswordLastSet, LastLogonDate |
    Select-Object SamAccountName, Enabled, DoesNotRequirePreAuth, PasswordLastSet, LastLogonDate

This gives you a practical starting point for review.

PowerShell: Find vulnerable accounts with old passwords

Accounts with old passwords should usually receive higher priority.

$Cutoff = (Get-Date).AddDays(-365)

Get-ADUser -Filter { DoesNotRequirePreAuth -eq $true -and Enabled -eq $true } `
    -Properties DoesNotRequirePreAuth, PasswordLastSet, LastLogonDate |
    Where-Object { $_.PasswordLastSet -lt $Cutoff } |
    Select-Object SamAccountName, PasswordLastSet, LastLogonDate, DoesNotRequirePreAuth

This helps identify enabled accounts with preauthentication disabled and passwords older than one year.

PowerShell: Check privileged exposure

To determine whether any vulnerable accounts are members of privileged groups, you can start by reviewing common administrative groups.

$PrivilegedGroups = @(
    "Domain Admins",
    "Enterprise Admins",
    "Schema Admins",
    "Administrators",
    "Account Operators",
    "Server Operators",
    "Backup Operators"
)

$VulnerableUsers = Get-ADUser -Filter { DoesNotRequirePreAuth -eq $true -and Enabled -eq $true } `
    -Properties MemberOf, DoesNotRequirePreAuth, PasswordLastSet

foreach ($User in $VulnerableUsers) {
    foreach ($GroupDn in $User.MemberOf) {
        $Group = Get-ADGroup $GroupDn
        if ($PrivilegedGroups -contains $Group.Name) {
            [PSCustomObject]@{
                SamAccountName = $User.SamAccountName
                PrivilegedGroup = $Group.Name
                PasswordLastSet = $User.PasswordLastSet
                DoesNotRequirePreAuth = $User.DoesNotRequirePreAuth
            }
        }
    }
}

This is not a complete privilege analysis, but it can quickly identify obvious high-risk accounts.

GUI: How to check the setting

You can also review the setting manually in Active Directory Users and Computers.

Open Active Directory Users and Computers.
Enable Advanced Features from the View menu.
Find the user account.
Open the account properties.
Go to the Account tab.
Review the account options.
Look for Do not require Kerberos preauthentication.

If the checkbox is selected, the account does not require Kerberos preauthentication.

How to remediate AS-REP Roasting exposure

The primary remediation is enable Kerberos preauthentication for the account.

In Active Directory Users and Computers, clear the checkbox:

Do not require Kerberos preauthentication

In PowerShell, you can update a specific account:

Set-ADAccountControl -Identity "username" -DoesNotRequirePreAuth $false

For multiple vulnerable users:

Get-ADUser -Filter { DoesNotRequirePreAuth -eq $true -and Enabled -eq $true } |
    Set-ADAccountControl -DoesNotRequirePreAuth $false

Be careful with bulk changes. If an account has this setting for a legitimate legacy compatibility reason, changing it may break authentication for that application or workflow.

Recommended remediation process

A safe remediation process usually looks like this:

Identify all accounts with preauthentication disabled.
Determine account ownership and purpose.
Check whether the account is enabled.
Review password age and password strength requirements.
Check privileged group membership and delegated access.
Confirm whether any legacy system requires the setting.
Enable Kerberos preauthentication where possible.
Rotate the account password after remediation.
Monitor authentication failures after the change.
Document any exceptions.

The goal is not only to clear the setting. The goal is to understand why the setting existed and whether the account has other risk factors.

Detection opportunities

AS-REP Roasting can be detected by monitoring Kerberos authentication behavior.

The most relevant Windows Security event is:

Event ID	Log	Purpose
4768	Security	A Kerberos authentication ticket was requested

A key detection clue is a Kerberos authentication request where preauthentication was not used.

Useful fields include:

Field	Why it matters
Account Name	The account being targeted
Client Address	Where the request came from
Pre-Authentication Type	A value of 0 may indicate no preauthentication
Ticket Encryption Type	Helps identify weaker encryption usage
Result Code	Helps interpret success or failure

A single event may not be enough to prove malicious activity. Defenders should look for patterns such as account enumeration, multiple AS-REP requests, unusual source systems, or requests for accounts that do not normally authenticate from that location.

Microsoft Defender for Identity detection

Microsoft Defender for Identity includes alerting for suspected AS-REP Roasting activity. Microsoft describes this type of alert as activity where attackers detect accounts with Kerberos preauthentication disabled and attempt to obtain Kerberos TGT data for offline password cracking.

This type of detection is useful, but it should not replace configuration hygiene. The best defense is to remove the risky setting unless there is a documented and tested business requirement.

Common mistakes

Assuming the setting is harmless

Disabling Kerberos preauthentication creates a known offline password cracking exposure. It should not be treated as a harmless compatibility setting.

Only checking privileged accounts

Privileged accounts are the highest priority, but low-privilege accounts can still be useful to attackers for persistence, lateral movement, or access to internal systems.

Forgetting disabled accounts

Disabled accounts are lower risk, but they should still be reviewed. If a disabled account is later re-enabled, the risky setting may become active again.

Enabling preauthentication without testing

Most accounts should not need this setting disabled, but legacy systems may exist. Confirm ownership and application dependencies before broad changes.

Failing to rotate the password

If an account was roastable, its password may have been exposed or cracked previously. Enabling preauthentication reduces future exposure, but password rotation helps address prior risk.

Leaving the account overprivileged

Fixing preauthentication is important, but it does not solve excessive privilege. Review group membership, delegated permissions, and application access.

Practical recommendation

A practical AS-REP Roasting reduction plan should include:

Find all enabled accounts with preauthentication disabled.
Prioritize privileged accounts first.
Review password age and account ownership.
Enable Kerberos preauthentication wherever possible.
Rotate passwords for remediated accounts.
Remove or disable stale accounts.
Document any exceptions.
Monitor Event ID 4768 for suspicious activity.
Review privileged access and delegated permissions.
Recheck regularly as part of Active Directory hygiene.

In most environments, accounts that do not require Kerberos preauthentication should be rare. If many accounts have this setting, it usually indicates a legacy configuration problem or weak account management process.

Summary

AS-REP Roasting is an Active Directory attack technique that targets accounts with Kerberos preauthentication disabled. When this setting is present, an attacker may be able to request Kerberos authentication data for the account and attempt to crack it offline.

The best defense is to enable Kerberos preauthentication, use strong passwords, rotate exposed account passwords, reduce unnecessary privileges, monitor Kerberos authentication activity, and document any legitimate exceptions.

AS-REP Roasting is usually straightforward to identify and remediate, which makes it a valuable early check in any Active Directory security review.