Do Not Require Preauthentication is an account setting that lets a Kerberos request be made without the user first proving knowledge of the password. It is associated with AS-REP roasting exposure because the account can return encrypted data before preauthentication, making weak or service accounts easier to target offline.
How the setting weakens Kerberos preauthentication
“Do Not Require Preauthentication” changes the first trust check in Kerberos. Instead of proving knowledge of the password before the Key Distribution Center returns data, the account can receive a response that an attacker can capture and work on offline. That turns a normal authentication step into an exposure point, especially when the account password is weak or reused.
This matters because preauthentication is meant to stop unauthenticated requests from generating useful response material. When that control is removed, the account becomes more visible to password-guessing attacks without repeatedly touching the live service.
Why AS-REP roasting becomes possible
AS-REP roasting is the practical abuse path associated with this setting. An attacker can request an AS-REP for a vulnerable account, obtain encrypted data, and then attempt password cracking offline. That offline nature is what makes the issue attractive: it avoids account lockout pressure and lets the attacker scale attempts quietly against many targets.
The setting is especially dangerous when service accounts, legacy accounts, or poorly managed user accounts are involved. Those accounts often have longer-lived passwords, inconsistent ownership, or lower visibility, which increases the chance that one exposed account will remain exploitable for a long time.
For deeper context on the attack pattern and the defensive focus around service accounts, the Kerberoasting and AS-REP Roasting Defence Guide covers the related detection and hardening themes.
How organisations check exposure and reduce the attack surface
Exposure checking starts with inventory: identify which accounts have preauthentication disabled, where those accounts live, and whether they are still needed. In practice, teams also check whether the account is privileged, service-related, or tied to an application that may be overlooked during normal access reviews.
Mitigation is usually straightforward in principle, but messy in execution. The safest path is to re-enable preauthentication wherever possible, replace weak or human-managed service credentials with stronger account patterns, and make sure account owners understand why the setting exists before leaving it in place.
If your organisation is modernising sign-in for sensitive accounts, the Passwordless and Passkeys Guide is a useful adjacent resource for understanding stronger authentication choices and recovery design.
Detection and post-compromise review
Detection often relies on directory and Kerberos telemetry, not on the endpoint of the attacker. Repeated AS-REQ activity against the same account, unusual preauthentication failure patterns, and requests that result in encrypted data for an account that should not be exposed are all worth review. Event correlation matters because a single request can look harmless on its own.
After remediation, organisations should still review for compromise. If the account was crackable, assume the password may already have been recovered and assess whether that account was used to reach other systems, service dependencies, or higher-privilege paths.
That post-patch review should include any credentials or sessions tied to the affected account, because an exposed Kerberos response is often only the first step in a broader identity compromise chain.
Risk and Threat Considerations
This setting creates a direct offline attack opportunity, so the risk is not just weak password hygiene, it is the removal of the normal proof-of-knowledge gate before useful response material is issued. The most serious cases involve service or legacy accounts that are rarely reviewed but remain valid for long periods.
Failure mechanism: An attacker requests a Kerberos response for an account that skips preauthentication, captures the encrypted blob, and cracks it offline until the password is recovered.
Impact: The attacker can impersonate the account, reuse its access, and pivot to other systems if the account has lateral movement potential or elevated permissions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1558.004 — Kerberos AS-REP Roasting | This term directly enables AS-REP roasting against Kerberos accounts. |
| Recommendation — Hunt for AS-REQ/AS-REP abuse and correlate offline cracking indicators to exposed accounts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Disabled preauthentication is an account lifecycle exception that must be inventoried and removed. |
| Recommendation — Inventory affected accounts and remove unnecessary authentication exceptions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The setting weakens authenticator handling by allowing usable Kerberos responses without prior proof. |
| IA-2 — Identification and Authentication (Organizational Users) | Kerberos preauthentication is part of user authentication assurance for organizational accounts. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Telemetry review is needed to detect abnormal Kerberos requests and post-compromise activity. | |
| Recommendation — Review authenticator handling and eliminate weak or unnecessary account exceptions. Enforce stronger user authentication paths for accounts that should not skip preauthentication. Review Kerberos-related audit data for abnormal request patterns and account misuse. | ||
Practitioner Guidance
What to watch for: Treat this setting as a deliberate exception, not a normal configuration. If it exists for compatibility, document the business reason, the owner, and the review date so it does not become an orphaned exposure.
Governance implication: Remove the setting wherever practical, and pair that change with password strength review and account rationalisation. The main judgement is whether the account still needs to exist in its current form, because the safest Kerberos posture is usually to eliminate the exception rather than accept it indefinitely.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org