Pre-authentication, session keys, and encryption types: Who proves what?

1. Core mechanism

The client (WS01) in the AS exchange, the domain controller (DC01) in the KDC role, and the directory/database that holds the client's long-term key. Pre-authentication data is carried in the padata field of AS-REQ, not TGS-REQ. Decisions are LSA/Kerberos SSP on the client, KDC service on the DC. The boundary of this lesson is the proof and key logic of the AS phase: the TGS and AP flow are at 06.02, the SPN→key relationship is at 06.03, the PAC carried by the ticket is at 06.05.

Interfaces and specifications

• RFC 4120 §5.2.7 PA-DATA ::= SEQUENCE { padata-type [1] Int32, padata-value [2] OCTET STRING }; §5.2.7.2 PA-ENC-TIMESTAMP (padata-type 2), PA-ENC-TS-ENC (timestamp) encrypted with the client's key.
• RFC 4120 §5.4.2: AS-REP enc-part is encrypted with the client's long-term key (reply key) and carries the session key; ticket [5] and enc-part [6] are sister fields in the same SEQUENCE.
• RFC 4120 §7.5.1 key usage: 1 (AS-REQ PA-ENC-TIMESTAMP), 3 (AS-REP enc-part, client/reply key), 2 (ticket enc-part, service/krbtgt key).
• RFC 4120 §7.5.9: KDC_ERR_PREAUTH_REQUIRED (25), KDC_ERR_PREAUTH_FAILED (24), KDC_ERR_ETYPE_NOSUPP (14).
• RFC 4120 §5.4.1 and §3.1.3: The req-body etype list declares the client's enctype capabilities; KDC selects a matching client long-term/reply key for AS-REP reply encryption and a separate enctype for the session key, and these two enctypes may be different. §5.2.7.5 PA-ETYPE-INFO2 is the padata by which the KDC reports the enctype, salt, and s2kparams for the long-term/reply key to the client.
• RFC 3961 §3-§4: encryption type profiles; string-to-key and random-to-key are enctype specific, and each protocol key is tied to a single enctype (typed key). RFC 3962: etype 18 AES256-CTS-HMAC-SHA1-96, 17 AES128-CTS-HMAC-SHA1-96; RFC 4757: etype 23 RC4-HMAC.
• Windows Security channel: 4771 / PreAuthType (2 = PA-ENC-TIMESTAMP), Status (Failure Code, 0x18 = KDC_ERR_PREAUTH_FAILED); generated only on domain controllers, and not generated for an account with Kerberos preauthentication disabled.

What does pre-authentication prove?

When Tunahan logs in to WS01, the client prepares an AS-REQ. In an environment where pre-authentication is desired (default on Windows), the client carries a PA-ENC-TIMESTAMP in padata next to the req-body: it encrypts the current timestamp with its own long-term key (RFC 4120 §5.2.7.2, key usage 1).

This is proof of the client's "I know the password" claim. If the KDC can decipher this timestamp with the client's key in the directory and the time fits within the tolerance, it will be convinced that the client actually has that key. The password or key never goes clear on the network; What goes out is just a ciphertext generated by the key.

If there is no pre-authentication, the client sends the initial request without proof and the KDC responds with KDC_ERR_PREAUTH_REQUIRED (25); This response usually carries ETYPE-INFO2, telling the client which etype and salt it should encrypt with. The client repeats the request with PA-ENC-TIMESTAMP.

Reply key and session key are not the same

This section illustrates the ordinary password-based PA-ENC-TIMESTAMP path. The client long-term key protects the AS-REP reply enc-part under key usage 3. It contains the new session key Kc,tgs for subsequent TGS exchanges.

Reply key names the role of the key protecting the reply, not a password key in every method. RFC 4120 permits a key selected through another pre-authentication mechanism; FAST can strengthen it for some methods. The session key is a separate KDC-generated key placed in both the TGT and client-facing reply part.

In AS-REP, ticket [5] and enc-part [6] are sister fields; The client opens [6] with the reply key and receives the session key, but cannot open [5] (TGT) because it is protected by the krbtgt key. In other words, the "key that opens AS-REP" is the reply key, and the "key carried by AS-REP" is the session key.

-- Password-based PA-ENC-TIMESTAMP example; AS-REP msg-type 11
KDC-REP ::= SEQUENCE {
        ...
        ticket    [5] Ticket,          -- krbtgt key, usage 2
        enc-part  [6] EncryptedData    -- client reply key, usage 3
}
-- Other pre-auth mechanisms can select or strengthen the reply key.
-- Kc,tgs inside the reply is a distinct, newly generated session key.

Encryption type changes cost, not proof

The client lists the enctypes it supports in the etype field in the AS-REQ's req-body, in order of preference (RFC 4120 §5.4.1, §3.1.3). This list is a negotiation entry that declares the client's capabilities; It is not a single 'reply/session key enctype'. The KDC makes two distinct choices from this list and its policy: To encrypt the AS-REP response, it determines a reply key (the client's long-term key) that matches one of the enctypes the client actually has; It chooses its own enctype for the session key it produces for the protocol. Both choices take client capabilities/policy into account, but the enctype of the reply key does not have to be the same as the enctype of the session key. If no enctype supported by the client is met, KDC_ERR_ETYPE_NOSUPP (14) is returned. The long-term reply-key choice here is scoped to the password-based example, not imposed on other pre-authentication mechanisms.

PA-ENC-TIMESTAMP, like AS-REP enc-part, is encrypted with the reply key, that is, the client's long-term key; In this flow, they share the same enctype because they use the same key (this concerns the client's long-term key, not the session key), but their key usage numbers are different (1 vs. 3). To enable the client to derive the correct key, the KDC declares the enctype, salt, and s2kparams values ​​for the long-term/reply key with PA-ETYPE-INFO2 (RFC 4120 §5.2.7.5); The client generates the key of that enctype with string-to-key. TGT's enc-part is independent of these choices: it is protected by the krbtgt key and krbtgt's own enctype, and is not affected by the client's req-body etype list.

etype numbers are profiles within the framework of RFC 3961 (RFC 3962: 17/18 AES, RFC 4757: 23 RC4-HMAC) and determine the type of a key: a key is bound to a single enctype (typed key), the same key cannot be represented by more than one enctype. A principal may hold a separate long-term key per enctype, but a single reply key, session key, or krbtgt key is a unique type. What changes between enctypes is not the identity of the key, but the cost of working offline against the ciphertext generated by that key: RC4 (23) makes string-to-key much cheaper than AES (17/18). So etype is not a proof but a cost parameter; Who owns the key (reply key, session key, krbtgt) is an ownership question independent of the enctype.

What question does the Preauth error answer?

If the Preauth timestamp cannot be resolved with the client's key, KDC returns KDC_ERR_PREAUTH_FAILED (24); In Windows, this is typically caused by an incorrect password. This error states that "the evidence presented was invalid"; It does not say that the account does not exist or is unauthorized.

If the timestamp is encrypted with the correct key but the clock is out of tolerance, the error family is different; This ties into the clock/skew topic covered in 04.03. Preauth failure and clock error cannot be put in the same box.

This distinction is important for the defense: error 4771 is an identity proof error. However, if preauth is disabled on the account, the first request does not require proof anyway and 4771 is not generated; This space is the subject of the Red layer.

A changed default still requires observation

Record OS name, installed update/build, domain functional level, explicit policy and available account keys separately. An OS label does not supply those values. Under applicable DC updates, KB5073381 describes the April 14, 2026 transition of the default for accounts without msDS-SupportedEncryptionTypes toward AES-SHA1 0x18. That is not a claim that every explicitly configured account changes or RC4 disappears from every path.

The July 2026 update phase removes support for the temporary RC4DefaultDisablementPhase control within that scope. Available keys, a service ticket’s EncryptedData etype and its session key remain separate facts. 0x18 is a support bitmask, not one ticket etype number. The comparison shows dated profiles without measuring the installed build or actual issuance. 11.04 uses its own certificate-mapping update boundary; 14.04 addresses compatibility validation after changes.

State and data flow

1. In the password-based example, the client encrypts PA-ENC-TIMESTAMP with its long-term key and sends it in AS-REQ.
2. If Preauth is not offered, KDC returns KDC_ERR_PREAUTH_REQUIRED (25) and declares etype/salt, usually with ETYPE-INFO2; the client tries again with PA-ENC-TIMESTAMP.
3. KDC decrypts the preauth timestamp with the client's key; If not resolved KDC_ERR_PREAUTH_FAILED (24), 4771 is generated on DC.
4. If the proof is valid, the KDC makes two separate choices: As the reply key with which to encrypt the AS-REP, it determines the long-term key that matches one of the client's supported enctypes, and for the session key, it determines an enctype that is compatible with the protocol usage and does not have to be the same; KDC_ERR_ETYPE_NOSUPP (14) if no enctype of the client can be satisfied. This choice is scoped to PA-ENC-TIMESTAMP; another pre-authentication mechanism can select or strengthen a different reply key.
5. KDC generates a new session key; It encrypts the AS-REP enc-part with the reply key (key usage 3). TGT's enc-part is protected independently by the krbtgt key and krbtgt's own enctype (key usage 2); A key is a single type, the same partition cannot be encrypted with multiple enctypes.
6. The client opens the AS-REP enc-part with the reply key and receives the session key; It does not open TGT, it carries it.
7. The client executes the TGS exchange with this session key and TGT on subsequent accesses (06.02).

2. Exploitation

Broken trust assumption

Broken assumption: "AS exchange always requires proof first; KDC will not give password derived ciphertext to anyone without proof of identity." In fact, pre-authentication is an attribute that can be turned off on an account-by-account basis (userAccountControl DONT_REQ_PREAUTH). For a Preauth closed account, the client can receive AS-REP without providing proof; The enc-part of this response is encrypted with the account's long-term key (reply key). Thus, any requester receives a ciphertext generated with the key of that account and can try the password offline. This is known as AS-REP roasting.

Technical prerequisites

• Pre-authentication is disabled on the target account (DONT_REQ_PREAUTH). If this condition is not present, the requester cannot pass preauth without knowing the key anyway.
• This lesson evaluates KDC reachability through the configured Kerberos transport. The protocol supports UDP and TCP; client preference, policy and response size affect the actual path. TCP/88 is not a universal requirement for every Kerberos request.
• The target account's key is based on a guessable password; Otherwise, testing on the resulting ciphertext will not yield meaningful results.
• It cheapens the attempt if the target is willing to respond with a weak etype like RC4; A configuration that only accepts AES makes the job significantly more difficult.

Exploitation mechanism

The mechanism is not a vulnerability of the protocol but the result of preauth being turned off. With Preauth off, KDC encrypts the enc-part of AS-REP with the target account's long-term key and under key usage 3; The requester receives it without providing evidence. Ciphertext can be obtained from the network, and the attacker tries password candidates offline: for each candidate, he derives a key with a string-to-key and checks whether this key satisfies the integrity check of the enc-part. When the right candidate is found, the key to the account is obtained. The difference from Kerberoasting is that the target is not a service SPN, but any account with preauth disabled, and the ciphertext comes from AS-REP rather than a service ticket.

Why can it remain silent on telemetry

Microsoft's documentation clearly states: 4771 is not generated if the "Do not require Kerberos preauthentication" option is set. Because AS-REP roasting targets exactly these accounts, the initial request of the attack does not produce a 4771 error.

Instead, the observation is sought in the 4768 record as an AS request without preauth (PreAuthType 0) or directly in control of the account configuration. So the signal is not an error event, but a pattern of configuration and unusual requests.

Again, the impact is limited by password strength and account scope. Hacking an account with closed Preauth is as important as the membership and rights of that account; It is not a domain compromise alone.

Why is disabling Preauth done and why is it risky?

Preauth is sometimes turned off for applications that are legacy or require interoperability; because some clients cannot generate PA-ENC-TIMESTAMP. This can be left as a short-term compliance solution and forgotten.

Every forgotten DONT_REQ_PREAUTH account is a silent offline target if its password is weak. Therefore, preauth status should be inventoried regularly.

Turning Preauth back on is seamless for most modern clients; The real obstacle is that if there is an old client, it should be handled separately.

The risk boundary of this example

Do not infer closure of every legacy path from a date or OS label. Effective-control claims require explicit configuration, available keys and actual wire observations.

3. Defense & Detection

Telemetry scope

• Audit Kerberos Authentication Service subcategory: 4768 (AS success) and 4771 (pre-auth error). This category is opened to monitor the AS phase.
• 4771 and 4768 occur only on the domain controller; no object SACL required, these are KDC transaction records.
• Critical limit: 4771, not generated if preauth is disabled on the account. That's why AS-REP roastable accounts do not appear with 4771; they are found by configuration control.
• The account configuration is a separate data source: the DONT_REQ_PREAUTH flag in the userAccountControl is read from the directory and evaluated along with the event data.
• 4771 volume increases in cases of incorrect password and expired password; This volume is a meaningful signal in password spray attacks.

Events and relevant fields

• 4771 / TargetUserName: Name of the account whose TGT is requested. The machine account ends with $.
• 4771 / TargetSid: SID of the account.
• 4771 / ServiceName: The destination to which the AS request is sent, typically krbtgt/DOMAIN. This is a TGT request, not a service ticket.
• 4771 / PreAuthType: code of the pre-authentication type used. 2 = PA-ENC-TIMESTAMP (standard password authentication), 0 = no preauth, 15/16/17 = smart card, 138 = Kerberos armoring (FAST).
• 4771 / Status: hexadecimal failure code ('Failure Code' in Event Viewer). 0x18 = KDC_ERR_PREAUTH_FAILED (invalid pre-authentication information; an incorrect password is a common cause), 0x17 = KDC_ERR_KEY_EXPIRED (password expired). The code alone does not establish the cause or intent.
• 4771 / TicketOptions: requested ticket flags; hexadecimal
• 4771 / IpAddress and IpPort: client address and port from which the request originated; these fields help correlate a password-spray pattern with its source.
• 4771 / CertIssuerName, CertSerialNumber, CertThumbprint: only relevant for smart card scenarios; The Microsoft documentation for 4771 states that these are always empty.

Read PreAuthType and Status together

4771 The PreAuthType field tells what type of evidence was attempted, and the Status field tells why the result failed. PreAuthType 2 is standard password authentication; Status 0x18 indicates that the provided proof (password) is invalid.

Reading these two fields separately separates a password error from a configuration or version issue. For example, in the smart card scenario, an error with PreAuthType 15/16/17 indicates a certificate problem, not a password, and may appear with different codes such as 0x10 (PADATA_TYPE_NOSUPP).

If PreAuthType is 0, the request came without preauth; This could be the normal behavior of an account with closed preauth, or it could be the trace of a discovery attempt. The comment is made along with the configuration of the account.

Validation after the change

Verify profiles against applicable updates, effective policy and account keys. Measure legitimate services in a canary scope first; absent audit events do not guarantee interoperability.

Detection logic · XPath

<!-- DC uzerindeki Security gunlugunde: yanlis parola nedeniyle pre-auth hatasi (Status 0x18),
     PA-ENC-TIMESTAMP (PreAuthType 2). Tek hostta secim yapar; cok-host korelasyonu yapmaz. -->
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4771)] and EventData[Data[@Name='Status']='0x18'] and EventData[Data[@Name='PreAuthType']='2']]</Select>
  </Query>
</QueryList>

Query assumptions

• This XPath is a native Windows Event Log query (wevtutil / Event Viewer Custom View). It only selects the Security log of the DC on which it is run; does not associate multiple DCs in the time axis.
• Field names and value formats (Status '0x18', PreAuthType '2') reflect the EventData names and instance format in the Microsoft 4771 document. The text comparison depends on the format in which the event is stored.
• This query alone does not make a password spray decision; A large number of 0x18 errors concentrated on one account or one resource should be evaluated with threshold and time window on the backend.
• Critical scope limit: accounts with preauth disabled do not generate 4771; This query cannot see AS-REP roastable accounts. They require a separate configuration check.
• This XPath was not run on an actual Windows event log in this session; only domain names and event semantics have been verified against the primary source.

False positives

• Automatic attempts made by the user who has just changed his password with the old registered credentials produce a temporary 0x18.
• Misconfigured service or scheduled task may produce regular 0x18 by trying repeatedly with old password.
• An ordinary mistyped password can produce 0x18. Locked/revoked credentials use 0x12 and an expired key uses 0x17; these are separate results, not automatically included by this query’s 0x18 filter.
• Negative example: Accounts without preauth with AS-REP roasting targets never generate 0x18; this query is expected not to see them, absence of evidence is not evidence of security.

Hardening

• Inventory: orderly list accounts with DONT_REQ_PREAUTH flag in userAccountControl; These are AS-REP roasting candidates.
• Keep pre-authentication enabled on every account unless absolutely necessary; If there is a legacy client dependency, isolate it and handle it separately.
• Gradually harden Etype policy: measure RC4 dependencies, switch to AES in pilot scope, keep path back ready. etype alone does not protect the password, but it does make it expensive to try.
• Enforce long and random password in cases where Preauth cannot be turned off; string-to-key cost increases with password length.
• Kerberos armoring (FAST) adds protection to the AS/pre-authentication exchange through the protected armor channel defined in RFC 6113; support and actual use must be verified separately in a Windows environment. It does not change the resource DACL decision.
• Verification step: for preauth reopened accounts, sign in is working and the PreAuthType value is 2 at 4768 (or 138 for FAST); See if your DONT_REQ_PREAUTH inventory is empty.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4771</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>14339</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T08:03:55.1180000Z" />
    <EventRecordID>30219</EventRecordID>
    <Correlation />
    <Execution ProcessID="520" ThreadID="1084" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">tunahan</Data>
    <Data Name="TargetSid">S-1-5-21-111111111-222222222-333333333-1142</Data>
    <Data Name="ServiceName">krbtgt/OUTREASON.EXAMPLE</Data>
    <Data Name="TicketOptions">0x40810010</Data>
    <Data Name="Status">0x18</Data>
    <Data Name="PreAuthType">2</Data>
    <Data Name="IpAddress">::ffff:192.0.2.44</Data>
    <Data Name="IpPort">49712</Data>
    <Data Name="CertIssuerName" />
    <Data Name="CertSerialNumber" />
    <Data Name="CertThumbprint" />
  </EventData>
</Event>

30 1e a0 03 02 01 12 a1 03 02 01 05 a2 12 04 10
c1 a0 c1 a0 de ad be ef 11 22 33 44 55 66 77 88

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "E07",
  "profileA": {
    "dcRelease": "Server 2022",
    "installedUpdateContext": "before April 14 2026 transition",
    "explicitDefaultDomainSupportedEncTypes": false,
    "accountTypesExplicit": false
  },
  "profileB": {
    "dcRelease": "Server 2022",
    "installedUpdateContext": "July 2026 or later applicable update",
    "explicitDefaultDomainSupportedEncTypes": false,
    "accountTypesExplicit": false
  },
  "separateInputs": [
    "available account keys",
    "client supported types",
    "service compatibility",
    "DFL unchanged"
  ]
}

Two reality checks

Assumption: Kerberoasting and AS-REP roasting are impossible on a domain using AES; encryption type prevents the attack.

In fact: Encryption type is not a proof, but a cost parameter of the offline trial. AES-based etype (17/18, RFC 3962) makes string-to-key much more expensive than RC4 (23, RFC 4757), but a weak password can still be cracked; It just takes longer. The main control is password strength, account type (gMSA/machine account) and preauth status. Saying "There is AES" does not mean "offline testing is impossible".

Assumption: The key used to open AS-REP and TGT's session key are the same thing.

In fact: The AS-REP enc-part is encrypted with the reply key, i.e. the client's long-term key, under key usage 3 (RFC 4120 §5.4.2, §7.5.1). The session key carried in this section is a separate key produced by KDC specific to that change; It has no version and is used with TGT in the next TGS replacement. Reply key is long-lived (carries kvno in EncryptedData), session key is not. The two have different ownership and lifespan; One unlocks the answer, the other is the key the answer carries.

Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §5.2.7 PA-DATA and §5.2.7.2 PA-ENC-TIMESTAMP (padata-type 2); §5.2.7.5 PA-ETYPE-INFO2 (enctype/salt/s2kparams); §5.4.1 and §3.1.3 separate selection of reply key and session key enctypes (they may differ); §5.4.2 AS-REP enc-part reply key and session key; §5.2.9 EncryptedData/kvno; §7.5.1 key usage 1/2/3; §7.5.9 error codes KDC_ERR_PREAUTH_REQUIRED 25, KDC_ERR_PREAUTH_FAILED 24, KDC_ERR_ETYPE_NOSUPP 14; §8.1 PA-ENC-TIMESTAMP and ETYPE-INFO2 requirement.
• RFC 3961 · Encryption and Checksum Specifications for Kerberos 5
  §3-§4 encryption type profiles and simplified profile: string-to-key and random-to-key are enctype-specific; each protocol key is bound to a single enctype (typed key). §5-§6 key usage and checksum framework.
• RFC 3962 · Advanced Encryption Standard (AES) Encryption for Kerberos 5
  AES-CTS-HMAC-SHA1-96 etype definitions: aes128-cts-hmac-sha1-96 (17) and aes256-cts-hmac-sha1-96 (18); string-to-key and iteration count parameters.
• RFC 4757 · The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows
  RC4-HMAC etype 23 (and export version 24); key derivation and NT hash-based string-to-key behavior.
• Microsoft · 4771(F) Kerberos pre-authentication failed
  Subcategory Audit Kerberos Authentication Service; Task 14339; DC only and note that it is not generated if preauth is disabled; EventData fields (TargetUserName, ServiceName, Status, PreAuthType); Failure Code table (0x17, 0x18); Pre-Authentication Types table (0, 2, 15, 16, 17, 138).
• RFC 6113 · A Generalized Framework for Kerberos Pre-Authentication
  §1 FAST protected channel between client and KDC; §3.2 Strengthening Reply Key Facility; §5.4 FAST request/response and armor encapsulation of pre-authentication data.
• KB5073381 — KDC RC4 default transition
  Summary; Timing of updates; MONITOR; registry gate; events 201/205
• LDAP signing overview
  What signing does; layer table; default behavior; upgrade considerations; event table
• KB5014754 certificate mapping
  Timeline; strong/weak mapping; KDC event guidance; Schannel distinction
• WHfB deployment planning
  Deployment/trust types; PKI requirements; OS requirements table
• Microsoft Learn · Event 4768
  PreAuthType 0 and successful TGT issuance; inspect Status separately.
• Microsoft Learn · UserAccountControl flags
  DONT_REQ_PREAUTH flag; directory configuration, not proof of an observed attempt.