deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-20 12:53:38 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Update event-4768.md

Browse Source 
Line 187: it's > its
Line 239 (x2), 245, 250 (x2), 320, 322, 324: is not > isn't
Line 243: According > According to
This commit is contained in:
Angela Fleischmann
2022-10-25 16:04:01 -06:00
committed by GitHub
parent 8b25c2c338
commit e7631dc273
1 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
windows/security/threat-protection/auditing/event-4768.md
View File

@ -184,7 +184,7 @@ The most common values:
| 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. |
| 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 it’s renew-till field has not passed. The ticket to be renewed is passed in the padata field as part of the authentication header. |
| 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. |
## Table 2. Kerberos ticket flags
@ -236,18 +236,18 @@ The most common values:
| 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 isn't 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 that, the user-supplied checksum in the Authenticator MUST be verified against the contents of the request. The message MUST be rejected either 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 that, the user-supplied checksum in the Authenticator MUST be verified against the contents of the request. The message MUST be rejected either if the checksums do not 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. |
| 0x3E | KDC\_ERR\_CLIENT\_NOT\_TRUSTED | The client trust failed or isn't 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 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. |
| 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. |
@ -317,11 +317,11 @@ For 4768(S, F): A Kerberos authentication ticket (TGT) was requested.
| **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 **“Supplied Realm Name”** corresponding to another domain or “external” location. |
| **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. |
- You can track all [4768](event-4768.md) events where the **Client Address** is not from your internal IP address range or not from private IP address ranges.
- You can track all [4768](event-4768.md) events where the **Client Address** isn't from your internal IP address range or not from private IP address ranges.
- If you know that **Account Name** should be used only from known list of IP addresses, track all **Client Address** values for this **Account Name** in [4768](event-4768.md) events. If **Client Address** is not from the allowlist, generate the alert.
- If you know that **Account Name** should be used only from known list of IP addresses, track all **Client Address** values for this **Account Name** in [4768](event-4768.md) events. If **Client Address** isn't from the allowlist, generate the alert.
- All **Client Address** = ::1 means local authentication. If you know the list of accounts which should log on to the domain controllers, then you need to monitor for all possible violations, where **Client Address** = ::1 and **Account Name** is not allowed to log on to any domain controller.
- All **Client Address** = ::1 means local authentication. If you know the list of accounts which should log on to the domain controllers, then you need to monitor for all possible violations, where **Client Address** = ::1 and **Account Name** isn't allowed to log on to any domain controller.
- All [4768](event-4768.md) events with **Client Port** field value &gt; 0 and &lt; 1024 should be examined, because a well-known port was used for outbound connection.