DONT_REQ_PREAUTH is an account setting that allows authentication without Kerberos pre-authentication. In Active Directory, it marks an account so a KDC will issue a ticket request without first proving knowledge of the long-term secret, which makes the account easier to attack through offline password guessing.
What this setting changes in Kerberos authentication
DONT_REQ_PREAUTH changes the normal Kerberos flow by allowing a ticket request before the user proves knowledge of the long-term secret. That matters because pre-authentication is one of the first checks that stops unauthorised requesters from turning account names into offline password-guessing targets.
In practice, the setting weakens an account’s front door rather than Kerberos itself. The KDC will still issue tickets according to policy, but the account no longer forces the requester to demonstrate knowledge of the secret at the start of the exchange, which is why the account becomes materially easier to probe.
Why it is dangerous
The main danger is that attackers can request data that supports offline cracking without repeatedly interacting with the KDC. That shifts the problem from online authentication controls to password-strength and secret-entropy failure, which is much easier for adversaries to scale against weak or reused passwords.
Where the account is privileged, service-linked, or long-lived, the exposure is broader than a single password guess. A successful crack can unlock lateral movement, impersonation, and access to downstream systems that trust the account.
How organisations identify exposure
Exposure checks usually start with directory review and asset inventory, because the setting lives on the account object itself. Security teams should look for accounts flagged to skip pre-authentication, especially those that are internet-reachable through remote access paths, legacy integrations, or service workflows.
Vendor and platform guidance is also important, because remediation details depend on directory design and account usage. In parallel, hunters should review whether the affected account has unusual ticket requests, repeated failures, or request patterns that suggest password-guessing activity.
Remediation and defensive hardening
The preferred fix is to remove the setting where it is not operationally required. If the account must remain exempt for a compatibility reason, reduce the blast radius by tightening password policy, reducing privilege, limiting network exposure, and isolating the account from high-value administration paths.
Authentication hardening matters because the setting removes an early proof step, so the remaining control strength comes from the secret itself and from surrounding access controls. Stronger passwords, tighter privilege boundaries, and fewer pathways to the account all reduce the value of the exemption to an attacker.
Detection and compromise review
Monitoring should focus on both the account and the systems that rely on it. Repeated ticket requests, abnormal request timing, and subsequent logons from unexpected hosts can indicate that offline guessing has moved into active use after a password compromise.
After remediation, organisations should review whether the account secret, any cached session material, and any dependent service credentials were exposed. If exploitation is suspected, rotate the credential and reassess the access paths that the account could reach before the change.
Risk and Threat Considerations
Accounts with this setting become attractive targets because they reduce the defender’s first line of resistance and can enable offline password guessing at scale. The risk is highest when the account has weak password hygiene, broad privileges, or is tied to critical services.
Failure mechanism: An attacker can request Kerberos material without proving knowledge of the secret first, then crack the returned data offline until the password is recovered.
Impact: A cracked account can be used for authenticated access, privilege escalation, service abuse, and follow-on lateral movement across Active Directory.
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 NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Kerberos pre-auth exemptions affect authenticator strength and lifecycle. |
| IA-2 — Identification and Authentication (Organizational Users) | The setting weakens user authentication assurance for directory accounts. | |
| Recommendation — Remove unnecessary pre-auth exemptions and enforce stronger authenticator management for exposed accounts. Require stronger authentication assurance for directory accounts that would otherwise skip pre-authentication. | ||
| CIS Controls v8 | CIS-5 — Account Management | This is an account-level exception that changes authentication exposure and review needs. |
| Recommendation — Inventory and review accounts with pre-auth disabled, then remove the exception where it is not required. | ||
| MITRE ATT&CK | T1110 — Brute Force | Skipping pre-auth supports offline password guessing against the account. |
| Recommendation — Hunt for brute-force preparation and offline password guessing activity tied to vulnerable accounts. | ||
| OWASP ASVS | V6 — Authentication | The term describes an authentication control weakening that affects login assurance. |
| Recommendation — Apply stronger authentication requirements and avoid exemptions that reduce assurance on sensitive accounts. | ||
Practitioner Guidance
What to watch for: Treat the setting as a deliberate exception, not a normal account state. If it exists, document the business reason, validate that the account is not overprivileged, and confirm that the secret is strong enough to resist offline attack.
Governance implication: Ownership should sit with the identity or directory team, because this is an account-level authentication exemption that needs review, exception handling, and periodic revalidation.
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