mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-20 12:53:38 +00:00
Update event-4769.md
Lines 30, 32, and 115: you will > you'll Line 244: According > According to Line 282: Add backticks to ::1 (x2) to try to improve Acro score. Lines 15, 207 (x2), 119, 177, 214, 216 (x3), 223-224, and 228: cannot > can't Lines 89, 176, 213, 230, 240, 246, 251, 278, and 280: is not > isn't Line 180: has not: hasn't Line 181: Should not > Shouldn't Lines 181 and 230: are not > aren't Lines 211 and 233: there is > there's Lines 215, 250, 252, and 256: does not > doesn't Line 272: are not > aren't Lines 225, 246, and 254: do not > don't Line 249: have not > haven't
This commit is contained in:
Angela Fleischmann
committed by
GitHub
GitHub
parent
2efd6fab73
commit
8b25c2c338
@ -27,9 +27,9 @@ This event generates every time Key Distribution Center gets a Kerberos Ticket G
|
||||
|
||||
This event generates only on domain controllers.
|
||||
|
||||
If TGS issue fails then you will see Failure event with **Failure Code** field not equal to “**0x0**”.
|
||||
If TGS issue fails then you'll see Failure event with **Failure Code** field not equal to “**0x0**”.
|
||||
|
||||
You will typically see many Failure events with **Failure Code** “**0x20**”, which simply means that a TGS ticket has expired. These are informational messages and have little to no security relevance.
|
||||
You'll typically see many Failure events with **Failure Code** “**0x20**”, which simply means that a TGS ticket has expired. These are informational messages and have little to no security relevance.
|
||||
|
||||
> **Note** For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
|
||||
|
||||
@ -86,7 +86,7 @@ You will typically see many Failure events with **Failure Code** “**0x20**”,
|
||||
|
||||
- Computer account example: WIN81$@CONTOSO.LOCAL
|
||||
|
||||
> **Note** Although this field is in the UPN format, this is not the attribute value of "UserPrincipalName" of the user account. It is the "normalized" name or implicit UPN. It is built from the user SamAccountName and the Active Directory domain name.
|
||||
> **Note** Although this field is in the UPN format, this isn't the attribute value of "UserPrincipalName" of the user account. It is the "normalized" name or implicit UPN. It is built from the user SamAccountName and the Active Directory domain name.
|
||||
|
||||
This parameter in this event is optional and can be empty in some cases.
|
||||
|
||||
@ -112,11 +112,11 @@ You will typically see many Failure events with **Failure Code** “**0x20**”,
|
||||
|
||||
- This parameter in this event is optional and can be empty in some cases.
|
||||
|
||||
- **Service ID** \[Type = SID\]**:** SID of the account or computer object for which the TGS ticket was requested. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
|
||||
- **Service ID** \[Type = SID\]**:** SID of the account or computer object for which the TGS ticket was requested. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
|
||||
|
||||
- **NULL SID** – this value shows in Failure events.
|
||||
|
||||
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
|
||||
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it can't ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
|
||||
|
||||
**Network Information:**
|
||||
|
||||
@ -173,12 +173,12 @@ The most common values:
|
||||
| 14 | Request-anonymous | KILE not use this flag. |
|
||||
| 15 | Name-canonicalize | In order to request referrals the Kerberos client MUST explicitly request the “canonicalize” KDC option for the AS-REQ or TGS-REQ. |
|
||||
| 16-25 | Unused | - |
|
||||
| 26 | Disable-transited-check | By default the KDC will check the transited field of a TGT against the policy of the local realm before it will issue derivative tickets based on the TGT. If this flag is set in the request, checking of the transited field is disabled. Tickets issued without the performance of this check will be noted by the reset (0) value of the TRANSITED-POLICY-CHECKED flag, indicating to the application server that the transited field must be checked locally. KDCs are encouraged but not required to honor<br>the DISABLE-TRANSITED-CHECK option.<br>Should not be in use, because Transited-policy-checked flag is not supported by KILE. |
|
||||
| 27 | Renewable-ok | The RENEWABLE-OK option indicates that a renewable ticket will be acceptable if a ticket with the requested life cannot otherwise be provided, in which case a renewable ticket may be issued with a renew-till equal to the requested end time. The value of the renew-till field may still be limited by local limits, or limits selected by the individual principal or server. |
|
||||
| 26 | Disable-transited-check | By default the KDC will check the transited field of a TGT against the policy of the local realm before it will issue derivative tickets based on the TGT. If this flag is set in the request, checking of the transited field is disabled. Tickets issued without the performance of this check will be noted by the reset (0) value of the TRANSITED-POLICY-CHECKED flag, indicating to the application server that the transited field must be checked locally. KDCs are encouraged but not required to honor<br>the DISABLE-TRANSITED-CHECK option.<br>Should not be in use, because Transited-policy-checked flag isn't supported by KILE. |
|
||||
| 27 | Renewable-ok | The RENEWABLE-OK option indicates that a renewable ticket will be acceptable if a ticket with the requested life can't otherwise be provided, in which case a renewable ticket may be issued with a renew-till equal to the requested end time. The value of the renew-till field may still be limited by local limits, or limits selected by the individual principal or server. |
|
||||
| 28 | Enc-tkt-in-skey | No information. |
|
||||
| 29 | Unused | - |
|
||||
| 30 | Renew | The RENEW option indicates that the present request is for a renewal. The ticket provided is encrypted in the secret key for the server on which it is valid. This option will only be honored if the ticket to be renewed has its RENEWABLE flag set and if the time in its renew-till field has not passed. The ticket to be renewed is passed in the padata field as part of the authentication header. |
|
||||
| 31 | Validate | This option is used only by the ticket-granting service. The VALIDATE option indicates that the request is to validate a postdated ticket. Should not be in use, because postdated tickets are not supported by KILE. <span id="kerberos-encryption-types" /> |
|
||||
| 30 | Renew | The RENEW option indicates that the present request is for a renewal. The ticket provided is encrypted in the secret key for the server on which it is valid. This option will only be honored if the ticket to be renewed has its RENEWABLE flag set and if the time in its renew-till field hasn't passed. The ticket to be renewed is passed in the padata field as part of the authentication header. |
|
||||
| 31 | Validate | This option is used only by the ticket-granting service. The VALIDATE option indicates that the request is to validate a postdated ticket. Shouldn't be in use, because postdated tickets aren't supported by KILE. <span id="kerberos-encryption-types" /> |
|
||||
| ## Table 4. Kerberos encryption types | | |
|
||||
|
||||
- **Ticket Encryption Type**: \[Type = HexInt32\]: the cryptographic suite that was used for issued TGS.
|
||||
@ -204,56 +204,56 @@ The most common values:
|
||||
| 0x4 | KDC\_ERR\_C\_OLD\_MAST\_KVNO | Client's key encrypted in old master key | No information. |
|
||||
| 0x5 | KDC\_ERR\_S\_OLD\_MAST\_KVNO | Server's key encrypted in old master key | No information. |
|
||||
| 0x6 | KDC\_ERR\_C\_PRINCIPAL\_UNKNOWN | Client not found in Kerberos database | The username doesn’t exist. |
|
||||
| 0x7 | KDC\_ERR\_S\_PRINCIPAL\_UNKNOWN | Server not found in Kerberos database | This error can occur if the domain controller cannot find the server’s name in Active Directory. This error is similar to KDC\_ERR\_C\_PRINCIPAL\_UNKNOWN except that it occurs when the server name cannot be found. |
|
||||
| 0x7 | KDC\_ERR\_S\_PRINCIPAL\_UNKNOWN | Server not found in Kerberos database | This error can occur if the domain controller can't find the server’s name in Active Directory. This error is similar to KDC\_ERR\_C\_PRINCIPAL\_UNKNOWN except that it occurs when the server name can't be found. |
|
||||
| 0x8 | KDC\_ERR\_PRINCIPAL\_NOT\_UNIQUE | Multiple principal entries in KDC database | This error occurs if duplicate principal names exist. Unique principal names are crucial for ensuring mutual authentication. Thus, duplicate principal names are strictly forbidden, even across multiple realms. Without unique principal names, the client has no way of ensuring that the server it is communicating with is the correct one. |
|
||||
| 0x9 | KDC\_ERR\_NULL\_KEY | The client or server has a null key (master key) | No master key was found for client or server. Usually it means that administrator should reset the password on the account. |
|
||||
| 0xA | KDC\_ERR\_CANNOT\_POSTDATE | Ticket (TGT) not eligible for postdating | This error can occur if a client requests postdating of a Kerberos ticket. Postdating is the act of requesting that a ticket’s start time be set into the future.<br>It also can occur if there is a time difference between the client and the KDC. |
|
||||
| 0xB | KDC\_ERR\_NEVER\_VALID | Requested start time is later than end time | There is a time difference between the KDC and the client. |
|
||||
| 0xB | KDC\_ERR\_NEVER\_VALID | Requested start time is later than end time | There's a time difference between the KDC and the client. |
|
||||
| 0xC | KDC\_ERR\_POLICY | Requested start time is later than end time | This error is usually the result of logon restrictions in place on a user’s account. For example workstation restriction, smart card authentication requirement or logon time restriction. |
|
||||
| 0xD | KDC\_ERR\_BADOPTION | KDC cannot accommodate requested option | Impending expiration of a TGT.<br>The SPN to which the client is attempting to delegate credentials is not in its Allowed-to-delegate-to list |
|
||||
| 0xE | KDC\_ERR\_ETYPE\_NOTSUPP | KDC has no support for encryption type | In general, this error occurs when the KDC or a client receives a packet that it cannot decrypt. |
|
||||
| 0xF | KDC\_ERR\_SUMTYPE\_NOSUPP | KDC has no support for checksum type | The KDC, server, or client receives a packet for which it does not have a key of the appropriate encryption type. The result is that the computer is unable to decrypt the ticket. |
|
||||
| 0x10 | KDC\_ERR\_PADATA\_TYPE\_NOSUPP | KDC has no support for PADATA type (pre-authentication data) | Smart card logon is being attempted and the proper certificate cannot be located. This can happen because the wrong certification authority (CA) is being queried or the proper CA cannot be contacted.<br>It can also happen when a domain controller doesn’t have a certificate installed for smart cards (Domain Controller or Domain Controller Authentication templates).<br>This error code cannot occur in event “[4768](event-4768.md). A Kerberos authentication ticket (TGT) was requested”. It occurs in “[4771](event-4771.md). Kerberos pre-authentication failed” event. |
|
||||
| 0xD | KDC\_ERR\_BADOPTION | KDC cannot accommodate requested option | Impending expiration of a TGT.<br>The SPN to which the client is attempting to delegate credentials isn't in its Allowed-to-delegate-to list |
|
||||
| 0xE | KDC\_ERR\_ETYPE\_NOTSUPP | KDC has no support for encryption type | In general, this error occurs when the KDC or a client receives a packet that it can't decrypt. |
|
||||
| 0xF | KDC\_ERR\_SUMTYPE\_NOSUPP | KDC has no support for checksum type | The KDC, server, or client receives a packet for which it doesn't have a key of the appropriate encryption type. The result is that the computer is unable to decrypt the ticket. |
|
||||
| 0x10 | KDC\_ERR\_PADATA\_TYPE\_NOSUPP | KDC has no support for PADATA type (pre-authentication data) | Smart card logon is being attempted and the proper certificate can't be located. This can happen because the wrong certification authority (CA) is being queried or the proper CA can't be contacted.<br>It can also happen when a domain controller doesn’t have a certificate installed for smart cards (Domain Controller or Domain Controller Authentication templates).<br>This error code can't occur in event “[4768](event-4768.md). A Kerberos authentication ticket (TGT) was requested”. It occurs in “[4771](event-4771.md). Kerberos pre-authentication failed” event. |
|
||||
| 0x11 | KDC\_ERR\_TRTYPE\_NO\_SUPP | KDC has no support for transited type | No information. |
|
||||
| 0x12 | KDC\_ERR\_CLIENT\_REVOKED | Client’s credentials have been revoked | This might be because of an explicit disabling or because of other restrictions in place on the account. For example: account disabled, expired, or locked out. |
|
||||
| 0x13 | KDC\_ERR\_SERVICE\_REVOKED | Credentials for server have been revoked | No information. |
|
||||
| 0x14 | KDC\_ERR\_TGT\_REVOKED | TGT has been revoked | Since the remote KDC may change its PKCROSS key while there are PKCROSS tickets still active, it SHOULD cache the old PKCROSS keys until the last issued PKCROSS ticket expires. Otherwise, the remote KDC will respond to a client with a KRB-ERROR message of type KDC\_ERR\_TGT\_REVOKED. See [RFC1510](https://www.ietf.org/proceedings/49/I-D/draft-ietf-cat-kerberos-pk-cross-07.txt) for more details. |
|
||||
| 0x15 | KDC\_ERR\_CLIENT\_NOTYET | Client not yet valid—try again later | No information. |
|
||||
| 0x16 | KDC\_ERR\_SERVICE\_NOTYET | Server not yet valid—try again later | No information. |
|
||||
| 0x17 | KDC\_ERR\_KEY\_EXPIRED | Password has expired—change password to reset | The user’s password has expired.<br>This error code cannot occur in event “[4768](event-4768.md). A Kerberos authentication ticket (TGT) was requested”. It occurs in “[4771](event-4771.md). Kerberos pre-authentication failed” event. |
|
||||
| 0x18 | KDC\_ERR\_PREAUTH\_FAILED | Pre-authentication information was invalid | The wrong password was provided.<br>This error code cannot occur in event “[4768](event-4768.md). A Kerberos authentication ticket (TGT) was requested”. It occurs in “[4771](event-4771.md). Kerberos pre-authentication failed” event. |
|
||||
| 0x19 | KDC\_ERR\_PREAUTH\_REQUIRED | Additional pre-authentication required | This error often occurs in UNIX interoperability scenarios. MIT-Kerberos clients do not request pre-authentication when they send a KRB\_AS\_REQ message. If pre-authentication is required (the default), Windows systems will send this error. Most MIT-Kerberos clients will respond to this error by giving the pre-authentication, in which case the error can be ignored, but some clients might not respond in this way. |
|
||||
| 0x17 | KDC\_ERR\_KEY\_EXPIRED | Password has expired—change password to reset | The user’s password has expired.<br>This error code can't occur in event “[4768](event-4768.md). A Kerberos authentication ticket (TGT) was requested”. It occurs in “[4771](event-4771.md). Kerberos pre-authentication failed” event. |
|
||||
| 0x18 | KDC\_ERR\_PREAUTH\_FAILED | Pre-authentication information was invalid | The wrong password was provided.<br>This error code can't occur in event “[4768](event-4768.md). A Kerberos authentication ticket (TGT) was requested”. It occurs in “[4771](event-4771.md). Kerberos pre-authentication failed” event. |
|
||||
| 0x19 | KDC\_ERR\_PREAUTH\_REQUIRED | Additional pre-authentication required | This error often occurs in UNIX interoperability scenarios. MIT-Kerberos clients don't request pre-authentication when they send a KRB\_AS\_REQ message. If pre-authentication is required (the default), Windows systems will send this error. Most MIT-Kerberos clients will respond to this error by giving the pre-authentication, in which case the error can be ignored, but some clients might not respond in this way. |
|
||||
| 0x1A | KDC\_ERR\_SERVER\_NOMATCH | KDC does not know about the requested server | No information. |
|
||||
| 0x1B | KDC\_ERR\_MUST\_USE\_USER2USER | Server principal valid for user2user only | This error occurs because the service is missing an SPN. |
|
||||
| 0x1F | KRB\_AP\_ERR\_BAD\_INTEGRITY | Integrity check on decrypted field failed | The authenticator was encrypted with something other than the session key. The result is that the client cannot decrypt the resulting message. The modification of the message could be the result of an attack or it could be because of network noise. |
|
||||
| 0x1F | KRB\_AP\_ERR\_BAD\_INTEGRITY | Integrity check on decrypted field failed | The authenticator was encrypted with something other than the session key. The result is that the client can't decrypt the resulting message. The modification of the message could be the result of an attack or it could be because of network noise. |
|
||||
| 0x20 | KRB\_AP\_ERR\_TKT\_EXPIRED | The ticket has expired | The smaller the value for the “Maximum lifetime for user ticket” Kerberos policy setting, the more likely it is that this error will occur. Because ticket renewal is automatic, you should not have to do anything if you get this message. |
|
||||
| 0x21 | KRB\_AP\_ERR\_TKT\_NYV | The ticket is not yet valid | The ticket presented to the server is not yet valid (in relationship to the server time). The most probable cause is that the clocks on the KDC and the client are not synchronized.<br>If cross-realm Kerberos authentication is being attempted, then you should verify time synchronization between the KDC in the target realm and the KDC in the client realm, as well. |
|
||||
| 0x21 | KRB\_AP\_ERR\_TKT\_NYV | The ticket is not yet valid | The ticket presented to the server isn't yet valid (in relationship to the server time). The most probable cause is that the clocks on the KDC and the client aren't synchronized.<br>If cross-realm Kerberos authentication is being attempted, then you should verify time synchronization between the KDC in the target realm and the KDC in the client realm, as well. |
|
||||
| 0x22 | KRB\_AP\_ERR\_REPEAT | The request is a replay | This error indicates that a specific authenticator showed up twice — the KDC has detected that this session ticket duplicates one that it has already received. |
|
||||
| 0x23 | KRB\_AP\_ERR\_NOT\_US | The ticket is not for us | The server has received a ticket that was meant for a different realm. |
|
||||
| 0x24 | KRB\_AP\_ERR\_BADMATCH | The ticket and authenticator do not match | The KRB\_TGS\_REQ is being sent to the wrong KDC.<br>There is an account mismatch during protocol transition. |
|
||||
| 0x24 | KRB\_AP\_ERR\_BADMATCH | The ticket and authenticator do not match | The KRB\_TGS\_REQ is being sent to the wrong KDC.<br>There's an account mismatch during protocol transition. |
|
||||
| 0x25 | KRB\_AP\_ERR\_SKEW | The clock skew is too great | This error is logged if a client computer sends a timestamp whose value differs from that of the server’s timestamp by more than the number of minutes found in the “Maximum tolerance for computer clock synchronization” setting in Kerberos policy. |
|
||||
| 0x26 | KRB\_AP\_ERR\_BADADDR | Network address in network layer header doesn't match address inside ticket | Session tickets MAY include the addresses from which they are valid. This error can occur if the address of the computer sending the ticket is different from the valid address in the ticket. A possible cause of this could be an Internet Protocol (IP) address change. Another possible cause is when a ticket is passed through a proxy server or NAT. The client is unaware of the address scheme used by the proxy server, so unless the program caused the client to request a proxy server ticket with the proxy server's source address, the ticket could be invalid. |
|
||||
| 0x27 | KRB\_AP\_ERR\_BADVERSION | Protocol version numbers don't match (PVNO) | When an application receives a KRB\_SAFE message, it verifies it. If any error occurs, an error code is reported for use by the application.<br>The message is first checked by verifying that the protocol version and type fields match the current version and KRB\_SAFE, respectively. A mismatch generates a KRB\_AP\_ERR\_BADVERSION.<br>See [RFC4120](http://www.ietf.org/rfc/rfc4120.txt) for more details. |
|
||||
| 0x28 | KRB\_AP\_ERR\_MSG\_TYPE | Message type is unsupported | This message is generated when target server finds that message format is wrong. This applies to KRB\_AP\_REQ, KRB\_SAFE, KRB\_PRIV and KRB\_CRED messages. <br>This error also generated if use of UDP protocol is being attempted with User-to-User authentication. |
|
||||
| 0x29 | KRB\_AP\_ERR\_MODIFIED | Message stream modified and checksum didn't match | The authentication data was encrypted with the wrong key for the intended server.<br>The authentication data was modified in transit by a hardware or software error, or by an attacker.<br>The client sent the authentication data to the wrong server because incorrect DNS data caused the client to send the request to the wrong server.<br>The client sent the authentication data to the wrong server because DNS data was out-of-date on the client. |
|
||||
| 0x2A | KRB\_AP\_ERR\_BADORDER | Message out of order (possible tampering) | This event generates for KRB\_SAFE and KRB\_PRIV messages if an incorrect sequence number is included, or if a sequence number is expected but not present. See [RFC4120](http://www.ietf.org/rfc/rfc4120.txt) for more details. |
|
||||
| 0x2C | KRB\_AP\_ERR\_BADKEYVER | Specified version of key is not available | This error might be generated on server side during receipt of invalid KRB\_AP\_REQ message. If the key version indicated by the Ticket in the KRB\_AP\_REQ is not one the server can use (e.g., it indicates an old key, and the server no longer possesses a copy of the old key), the KRB\_AP\_ERR\_BADKEYVER error is returned. |
|
||||
| 0x2C | KRB\_AP\_ERR\_BADKEYVER | Specified version of key is not available | This error might be generated on server side during receipt of invalid KRB\_AP\_REQ message. If the key version indicated by the Ticket in the KRB\_AP\_REQ isn't one the server can use (e.g., it indicates an old key, and the server no longer possesses a copy of the old key), the KRB\_AP\_ERR\_BADKEYVER error is returned. |
|
||||
| 0x2D | KRB\_AP\_ERR\_NOKEY | Service key not available | This error might be generated on server side during receipt of invalid KRB\_AP\_REQ message. Because it is possible for the server to be registered in multiple realms, with different keys in each, the realm field in the unencrypted portion of the ticket in the KRB\_AP\_REQ is used to specify which secret key the server should use to decrypt that ticket. The KRB\_AP\_ERR\_NOKEY error code is returned if the server doesn't have the proper key to decipher the ticket. |
|
||||
| 0x2E | KRB\_AP\_ERR\_MUT\_FAIL | Mutual authentication failed | No information. |
|
||||
| 0x2F | KRB\_AP\_ERR\_BADDIRECTION | Incorrect message direction | No information. |
|
||||
| 0x30 | KRB\_AP\_ERR\_METHOD | Alternative authentication method required | According [RFC4120](http://www.ietf.org/rfc/rfc4120.txt) this error message is obsolete. |
|
||||
| 0x30 | KRB\_AP\_ERR\_METHOD | Alternative authentication method required | According to [RFC4120](http://www.ietf.org/rfc/rfc4120.txt) this error message is obsolete. |
|
||||
| 0x31 | KRB\_AP\_ERR\_BADSEQ | Incorrect sequence number in message | No information. |
|
||||
| 0x32 | KRB\_AP\_ERR\_INAPP\_CKSUM | Inappropriate type of checksum in message (checksum may be unsupported) | When KDC receives KRB\_TGS\_REQ message it decrypts it, and after the user-supplied checksum in the Authenticator MUST be verified against the contents of the request, and the message MUST be rejected if the checksums do not match (with an error code of KRB\_AP\_ERR\_MODIFIED) or if the checksum is not collision-proof (with an error code of KRB\_AP\_ERR\_INAPP\_CKSUM). |
|
||||
| 0x32 | KRB\_AP\_ERR\_INAPP\_CKSUM | Inappropriate type of checksum in message (checksum may be unsupported) | When KDC receives KRB\_TGS\_REQ message it decrypts it, and after the user-supplied checksum in the Authenticator MUST be verified against the contents of the request, and the message MUST be rejected if the checksums don't match (with an error code of KRB\_AP\_ERR\_MODIFIED) or if the checksum isn't collision-proof (with an error code of KRB\_AP\_ERR\_INAPP\_CKSUM). |
|
||||
| 0x33 | KRB\_AP\_PATH\_NOT\_ACCEPTED | Desired path is unreachable | No information. |
|
||||
| 0x34 | KRB\_ERR\_RESPONSE\_TOO\_BIG | Too much data | The size of a ticket is too large to be transmitted reliably via UDP. In a Windows environment, this message is purely informational. A computer running a Windows operating system will automatically try TCP if UDP fails. |
|
||||
| 0x3C | KRB\_ERR\_GENERIC | Generic error | Group membership has overloaded the PAC.<br>Multiple recent password changes have not propagated.<br>Crypto subsystem error caused by running out of memory.<br>SPN too long.<br>SPN has too many parts. |
|
||||
| 0x3D | KRB\_ERR\_FIELD\_TOOLONG | Field is too long for this implementation | Each request (KRB\_KDC\_REQ) and response (KRB\_KDC\_REP or KRB\_ERROR) sent over the TCP stream is preceded by the length of the request as 4 octets in network byte order. The high bit of the length is reserved for future expansion and MUST currently be set to zero. If a KDC that does not understand how to interpret a set high bit of the length encoding receives a request with the high order bit of the length set, it MUST return a KRB-ERROR message with the error KRB\_ERR\_FIELD\_TOOLONG and MUST close the TCP stream. |
|
||||
| 0x3E | KDC\_ERR\_CLIENT\_NOT\_TRUSTED | The client trust failed or is not implemented | This typically happens when user’s smart-card certificate is revoked or the root Certification Authority that issued the smart card certificate (in a chain) is not trusted by the domain controller. |
|
||||
| 0x3F | KDC\_ERR\_KDC\_NOT\_TRUSTED | The KDC server trust failed or could not be verified | The trustedCertifiers field contains a list of certification authorities trusted by the client, in the case that the client does not possess the KDC's public key certificate. If the KDC has no certificate signed by any of the trustedCertifiers, then it returns an error of type KDC\_ERR\_KDC\_NOT\_TRUSTED. See [RFC1510](https://www.ietf.org/proceedings/50/I-D/cat-kerberos-pk-init-13.txt) for more details. |
|
||||
| 0x3C | KRB\_ERR\_GENERIC | Generic error | Group membership has overloaded the PAC.<br>Multiple recent password changes hanven't propagated.<br>Crypto subsystem error caused by running out of memory.<br>SPN too long.<br>SPN has too many parts. |
|
||||
| 0x3D | KRB\_ERR\_FIELD\_TOOLONG | Field is too long for this implementation | Each request (KRB\_KDC\_REQ) and response (KRB\_KDC\_REP or KRB\_ERROR) sent over the TCP stream is preceded by the length of the request as 4 octets in network byte order. The high bit of the length is reserved for future expansion and MUST currently be set to zero. If a KDC that doesn't understand how to interpret a set high bit of the length encoding receives a request with the high order bit of the length set, it MUST return a KRB-ERROR message with the error KRB\_ERR\_FIELD\_TOOLONG and MUST close the TCP stream. |
|
||||
| 0x3E | KDC\_ERR\_CLIENT\_NOT\_TRUSTED | The client trust failed or is not implemented | This typically happens when user’s smart-card certificate is revoked or the root Certification Authority that issued the smart card certificate (in a chain) isn't trusted by the domain controller. |
|
||||
| 0x3F | KDC\_ERR\_KDC\_NOT\_TRUSTED | The KDC server trust failed or could not be verified | The trustedCertifiers field contains a list of certification authorities trusted by the client, in the case that the client doesn't possess the KDC's public key certificate. If the KDC has no certificate signed by any of the trustedCertifiers, then it returns an error of type KDC\_ERR\_KDC\_NOT\_TRUSTED. See [RFC1510](https://www.ietf.org/proceedings/50/I-D/cat-kerberos-pk-init-13.txt) for more details. |
|
||||
| 0x40 | KDC\_ERR\_INVALID\_SIG | The signature is invalid | This error is related to PKINIT. If a PKI trust relationship exists, the KDC then verifies the client's signature on AuthPack (TGT request signature). If that fails, the KDC returns an error message of type KDC\_ERR\_INVALID\_SIG. |
|
||||
| 0x41 | KDC\_ERR\_KEY\_TOO\_WEAK | A higher encryption level is needed | If the clientPublicValue field is filled in, indicating that the client wishes to use Diffie-Hellman key agreement, then the KDC checks to see that the parameters satisfy its policy. If they do not (e.g., the prime size is insufficient for the expected encryption type), then the KDC sends back an error message of type KDC\_ERR\_KEY\_TOO\_WEAK. |
|
||||
| 0x41 | KDC\_ERR\_KEY\_TOO\_WEAK | A higher encryption level is needed | If the clientPublicValue field is filled in, indicating that the client wishes to use Diffie-Hellman key agreement, then the KDC checks to see that the parameters satisfy its policy. If they don't (e.g., the prime size is insufficient for the expected encryption type), then the KDC sends back an error message of type KDC\_ERR\_KEY\_TOO\_WEAK. |
|
||||
| 0x42 | KRB\_AP\_ERR\_USER\_TO\_USER\_REQUIRED | User-to-user authorization is required | In the case that the client application doesn't know that a service requires user-to-user authentication, and requests and receives a conventional KRB\_AP\_REP, the client will send the KRB\_AP\_REP request, and the server will respond with a KRB\_ERROR token as described in [RFC1964](https://tools.ietf.org/html/rfc1964), with a msg-type of KRB\_AP\_ERR\_USER\_TO\_USER\_REQUIRED. |
|
||||
| 0x43 | KRB\_AP\_ERR\_NO\_TGT | No TGT was presented or available | In user-to-user authentication if the service does not possess a ticket granting ticket, it should return the error KRB\_AP\_ERR\_NO\_TGT. |
|
||||
| 0x43 | KRB\_AP\_ERR\_NO\_TGT | No TGT was presented or available | In user-to-user authentication if the service doesn't possess a ticket granting ticket, it should return the error KRB\_AP\_ERR\_NO\_TGT. |
|
||||
| 0x44 | KDC\_ERR\_WRONG\_REALM | Incorrect domain or principal | Although this error rarely occurs, it occurs when a client presents a cross-realm TGT to a realm other than the one specified in the TGT. Typically, this results from incorrectly configured DNS. |
|
||||
|
||||
- **Transited Services** \[Type = UnicodeString\]: this field contains list of SPNs which were requested if Kerberos delegation was used.
|
||||
@ -269,17 +269,17 @@ For 4769(S, F): A Kerberos service ticket was requested.
|
||||
| **High-value accounts**: You might have high-value domain or local accounts for which you need to monitor each action.<br>Examples of high-value accounts are database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts and so on. | Monitor this event with the **“Account Information\\Account Name”** that corresponds to the high-value account or accounts. |
|
||||
| **Anomalies or malicious actions**: You might have specific requirements for detecting anomalies or monitoring potential malicious actions. For example, you might need to monitor for use of an account outside of working hours. | When you monitor for anomalies or malicious actions, use the **“Account Information\\Account Name”** (with other information) to monitor how or when a particular account is being used. |
|
||||
| **Non-active accounts**: You might have non-active, disabled, or guest accounts, or other accounts that should never be used. | Monitor this event with the **“Account Information\\Account Name”** that corresponds to the accounts that should never be used. |
|
||||
| **External accounts**: You might be monitoring accounts from another domain, or “external” accounts that are not allowed to perform certain actions (represented by certain specific events). | Monitor this event for the **“Account Information\\Account Domain”** corresponding to another domain or “external” location. |
|
||||
| **External accounts**: You might be monitoring accounts from another domain, or “external” accounts that aren't allowed to perform certain actions (represented by certain specific events). | Monitor this event for the **“Account Information\\Account Domain”** corresponding to another domain or “external” location. |
|
||||
| **Restricted-use computers or devices**: You might have certain computers, machines, or devices on which certain people (accounts) should not typically perform any actions. | Monitor the target **Computer:** (or other target device) for actions performed by the **“Account Information\\Account Name”** that you are concerned about. |
|
||||
| **Account naming conventions**: Your organization might have specific naming conventions for account names. | Monitor “**User ID”** for names that don’t comply with naming conventions. |
|
||||
|
||||
- If you know that **Account Name** should never request any tickets for (that is, never get access to) a particular computer account or service account, monitor for [4769](event-4769.md) events with the corresponding **Account Name** and **Service ID** fields.
|
||||
|
||||
- You can track all [4769](event-4769.md) events where the **Client Address** is not from your internal IP range or not from private IP ranges.
|
||||
- You can track all [4769](event-4769.md) events where the **Client Address** isn't from your internal IP range or not from private IP ranges.
|
||||
|
||||
- If you know that **Account Name** should be able to request tickets (should be used) only from a known allow list of IP addresses, track all **Client Address** values for this **Account Name** in [4769](event-4769.md) events. If **Client Address** is not from your allow list of IP addresses, generate the alert.
|
||||
- If you know that **Account Name** should be able to request tickets (should be used) only from a known allow list of IP addresses, track all **Client Address** values for this **Account Name** in [4769](event-4769.md) events. If **Client Address** isn't from your allow list of IP addresses, generate the alert.
|
||||
|
||||
- All **Client Address** = ::1 means local TGS requests, which means that the **Account Name** logged on to a domain controller before making the TGS request. If you have an allow list of accounts allowed to log on to domain controllers, monitor events with **Client Address** = ::1 and any **Account Name** outside the allow list.
|
||||
- All **Client Address** = `::1` means local TGS requests, which means that the **Account Name** logged on to a domain controller before making the TGS request. If you have an allow list of accounts allowed to log on to domain controllers, monitor events with **Client Address** = `::1` and any **Account Name** outside the allow list.
|
||||
|
||||
- All [4769](event-4769.md) events with **Client Port** field value > 0 and < 1024 should be examined, because a well-known port was used for outbound connection.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user