ItemBox

4769(S, F) A Kerberos service ticket was requested.

4769(S, F): A Kerberos service ticket was requested.

Subcategory: Audit Kerberos Service Ticket Operations

Event Description:

This event generates every time Key Distribution Center gets a Kerberos Ticket Granting Service (TGS) ticket request.

This event generates only on domain controllers.

If TGS issue fails then you’ll see Failure event with Failure Code field not equal to “0x0”.

You’ll typically see many Failure events with Failure Code0x20”, 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 for this event.

Event XML:

- <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>4769</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>14337</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2015-08-07T18:13:46.043256100Z" />
<EventRecordID>166746</EventRecordID>
<Correlation />
<Execution ProcessID="520" ThreadID="1496" />
<Channel>Security</Channel>
<Computer>DC01.contoso.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">dadmin@CONTOSO.LOCAL</Data>
<Data Name="TargetDomainName">CONTOSO.LOCAL</Data>
<Data Name="ServiceName">WIN2008R2$</Data>
<Data Name="ServiceSid">S-1-5-21-3457937927-2839227994-823803824-2102</Data>
<Data Name="TicketOptions">0x40810000</Data>
<Data Name="TicketEncryptionType">0x12</Data>
<Data Name="IpAddress">::ffff:10.0.0.12</Data>
<Data Name="IpPort">49272</Data>
<Data Name="Status">0x0</Data>
<Data Name="LogonGuid">{F85C455E-C66E-205C-6B39-F6C60A7FE453}</Data>
<Data Name="TransmittedServices">-</Data>
</EventData>
</Event>

Required Server Roles: Active Directory domain controller.

Minimum OS Version: Windows Server 2008.

Event Versions: 0.

Field Descriptions:

Account Information:

  • Account Name [Type = UnicodeString]: the user name of the account that requested the ticket in the User Principal Name (UPN) syntax. Computer account name ends with $ character in the user name part. This field typically has the following value format: user_account_name@FULL_DOMAIN_NAME.

    • User account example: dadmin@CONTOSO.LOCAL

    • Computer account example: WIN81$@CONTOSO.LOCAL

      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.

  • Account Domain [Type = UnicodeString]: the name of the Kerberos Realm that Account Name belongs to. This can appear in a variety of formats, including the following:

    • Domain NETBIOS name example: CONTOSO

    • Lowercase full domain name: contoso.local

    • Uppercase full domain name: CONTOSO.LOCAL

      This parameter in this event is optional and can be empty in some cases.

  • Logon GUID [Type = GUID]: a GUID that can help you correlate this event (on a domain controller) with other events (on the target computer for which the TGS was issued) that can contain the same Logon GUID. These events are “4624: An account was successfully logged on”, “4648(S): A logon was attempted using explicit credentials” and “4964(S): Special groups have been assigned to a new logon.”

    This parameter might not be captured in the event, and in that case appears as “{00000000-0000-0000-0000-000000000000}”.

Note  GUID is an acronym for ‘Globally Unique Identifier’. It is a 128-bit integer number used to identify resources, activities or instances.

Service Information:

  • Service Name [Type = UnicodeString]: the name of the account or computer for which the TGS ticket was requested.

    • 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 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 can’t ever be used again to identify another user or group. For more information about SIDs, see Security identifiers.

Network Information:

  • Client Address [Type = UnicodeString]: IP address of the computer from which the TGS request was received. Formats vary, and include the following:

    • IPv6 or IPv4 address.

    • ::ffff:IPv4_address.

    • ::1 - localhost.

  • Client Port [Type = UnicodeString]: source port number of client network connection (TGS request connection).

    • 0 for local (localhost) requests.

Additional information:

  • Ticket Options: [Type = HexInt32]: this is a set of different Ticket Flags in hexadecimal format.

    Example:

    • Ticket Options: 0x40810010

    • Binary view: 01000000100000010000000000010000

    • Using MSB 0 bit numbering we have bit 1, 8, 15 and 27 set = Forwardable, Renewable, Canonicalize, Renewable-ok.

Note  In the table below “MSB 0” bit numbering is used, because RFC documents use this style. In “MSB 0” style bit numbering begins from left.

The most common values:

  • 0x40810010 - Forwardable, Renewable, Canonicalize, Renewable-ok

  • 0x40810000 - Forwardable, Renewable, Canonicalize

  • 0x60810010 - Forwardable, Forwarded, Renewable, Canonicalize, Renewable-ok

BitFlag NameDescription
0Reserved-
1Forwardable(TGT only). Tells the ticket-granting service that it can issue a new TGT—based on the presented TGT—with a different network address based on the presented TGT.
2ForwardedIndicates either that a TGT has been forwarded or that a ticket was issued from a forwarded TGT.
3Proxiable(TGT only). Tells the ticket-granting service that it can issue tickets with a network address that differs from the one in the TGT.
4ProxyIndicates that the network address in the ticket is different from the one in the TGT used to obtain the ticket.
5Allow-postdatePostdated tickets SHOULD NOT be supported in KILE (Microsoft Kerberos Protocol Extension).
6PostdatedPostdated tickets SHOULD NOT be supported in KILE (Microsoft Kerberos Protocol Extension).
7InvalidThis flag indicates that a ticket is invalid, and it must be validated by the KDC before use. Application servers must reject tickets which have this flag set.
8RenewableUsed in combination with the End Time and Renew Till fields to cause tickets with long life spans to be renewed at the KDC periodically.
9InitialIndicates that a ticket was issued using the authentication service (AS) exchange and not issued based on a TGT.
10Pre-authentIndicates that the client was authenticated by the KDC before a ticket was issued. This flag usually indicates the presence of an authenticator in the ticket. It can also flag the presence of credentials taken from a smart card logon.
11Opt-hardware-authThis flag was originally intended to indicate that hardware-supported authentication was used during pre-authentication. This flag is no longer recommended in the Kerberos V5 protocol. KDCs MUST NOT issue a ticket with this flag set. KDCs SHOULD NOT preserve this flag if it is set by another KDC.
12Transited-policy-checkedKILE MUST NOT check for transited domains on servers or a KDC. Application servers MUST ignore the TRANSITED-POLICY-CHECKED flag.
13Ok-as-delegateThe KDC MUST set the OK-AS-DELEGATE flag if the service account is trusted for delegation.
14Request-anonymousKILE not use this flag.
15Name-canonicalizeIn order to request referrals the Kerberos client MUST explicitly request the “canonicalize” KDC option for the AS-REQ or TGS-REQ.
16-25Unused-
26Disable-transited-checkBy 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 honorthe DISABLE-TRANSITED-CHECK option.Should not be in use, because Transited-policy-checked flag isn’t supported by KILE.
27Renewable-okThe 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.
28Enc-tkt-in-skeyNo information.
29Unused-
30RenewThe 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.
31ValidateThis 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.
  • Ticket Encryption Type: [Type = HexInt32]: the cryptographic suite that was used for issued TGS.
TypeType NameDescription
0x1DES-CBC-CRCDisabled by default starting from Windows 7 and Windows Server 2008 R2.
0x3DES-CBC-MD5Disabled by default starting from Windows 7 and Windows Server 2008 R2.
0x11AES128-CTS-HMAC-SHA1-96Supported starting from Windows Server 2008 and Windows Vista.
0x12AES256-CTS-HMAC-SHA1-96Supported starting from Windows Server 2008 and Windows Vista.
0x17RC4-HMACDefault suite for operating systems before Windows Server 2008 and Windows Vista.
0x18RC4-HMAC-EXPDefault suite for operating systems before Windows Server 2008 and Windows Vista.
0xFFFFFFFF or 0xffffffff-This type shows in Audit Failure events.
  • Failure Code [Type = HexInt32]: hexadecimal result code of TGS issue operation. Some errors are only reported when you set KdcExtraLogLevel registry key value with the following flags:
  • 0x01: Audit SPN unknown errors.
  • 0x10: Log audit events on encryption type (ETYPE) and bad options errors.

The table below contains the list of the most common error codes for this event:

CodeCode NameDescriptionPossible causes
0x0KDC_ERR_NONENo errorNo errors were found.
0x1KDC_ERR_NAME_EXPClient’s entry in KDC database has expiredNo information.
0x2KDC_ERR_SERVICE_EXPServer’s entry in KDC database has expiredNo information.
0x3KDC_ERR_BAD_PVNORequested Kerberos version number not supportedNo information.
0x4KDC_ERR_C_OLD_MAST_KVNOClient’s key encrypted in old master keyNo information.
0x5KDC_ERR_S_OLD_MAST_KVNOServer’s key encrypted in old master keyNo information.
0x6KDC_ERR_C_PRINCIPAL_UNKNOWNClient not found in Kerberos databaseThe username doesn’t exist.
0x7KDC_ERR_S_PRINCIPAL_UNKNOWNServer not found in Kerberos databaseThis 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.
0x8KDC_ERR_PRINCIPAL_NOT_UNIQUEMultiple principal entries in KDC databaseThis 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.
0x9KDC_ERR_NULL_KEYThe 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.
0xAKDC_ERR_CANNOT_POSTDATETicket (TGT) not eligible for postdatingThis 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.It also can occur if there is a time difference between the client and the KDC.
0xBKDC_ERR_NEVER_VALIDRequested start time is later than end timeThere’s a time difference between the KDC and the client.
0xCKDC_ERR_POLICYRequested start time is later than end timeThis 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.
0xDKDC_ERR_BADOPTIONKDC cannot accommodate requested optionImpending expiration of a TGT.The SPN to which the client is attempting to delegate credentials isn’t in its Allowed-to-delegate-to list
0xEKDC_ERR_ETYPE_NOTSUPPKDC has no support for encryption typeIn general, this error occurs when the KDC or a client receives a packet that it can’t decrypt.
0xFKDC_ERR_SUMTYPE_NOSUPPKDC has no support for checksum typeThe 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.
0x10KDC_ERR_PADATA_TYPE_NOSUPPKDC 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.It can also happen when a domain controller doesn’t have a certificate installed for smart cards (Domain Controller or Domain Controller Authentication templates).This error code can’t occur in event “4768. A Kerberos authentication ticket (TGT) was requested”. It occurs in “4771. Kerberos pre-authentication failed” event.
0x11KDC_ERR_TRTYPE_NO_SUPPKDC has no support for transited typeNo information.
0x12KDC_ERR_CLIENT_REVOKEDClient’s credentials have been revokedThis 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.
0x13KDC_ERR_SERVICE_REVOKEDCredentials for server have been revokedNo information.
0x14KDC_ERR_TGT_REVOKEDTGT has been revokedSince 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 for more details.
0x15KDC_ERR_CLIENT_NOTYETClient not yet valid—try again laterNo information.
0x16KDC_ERR_SERVICE_NOTYETServer not yet valid—try again laterNo information.
0x17KDC_ERR_KEY_EXPIREDPassword has expired—change password to resetThe user’s password has expired.This error code can’t occur in event “4768. A Kerberos authentication ticket (TGT) was requested”. It occurs in “4771. Kerberos pre-authentication failed” event.
0x18KDC_ERR_PREAUTH_FAILEDPre-authentication information was invalidThe wrong password was provided.This error code can’t occur in event “4768. A Kerberos authentication ticket (TGT) was requested”. It occurs in “4771. Kerberos pre-authentication failed” event.
0x19KDC_ERR_PREAUTH_REQUIREDAdditional pre-authentication requiredThis 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.
0x1AKDC_ERR_SERVER_NOMATCHKDC does not know about the requested serverNo information.
0x1BKDC_ERR_MUST_USE_USER2USERServer principal valid for user2user onlyThis error occurs because the service is missing an SPN.
0x1FKRB_AP_ERR_BAD_INTEGRITYIntegrity check on decrypted field failedThe 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.
0x20KRB_AP_ERR_TKT_EXPIREDThe ticket has expiredThe 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.
0x21KRB_AP_ERR_TKT_NYVThe ticket is not yet validThe 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.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.
0x22KRB_AP_ERR_REPEATThe request is a replayThis error indicates that a specific authenticator showed up twice — the KDC has detected that this session ticket duplicates one that it has already received.
0x23KRB_AP_ERR_NOT_USThe ticket is not for usThe server has received a ticket that was meant for a different realm.
0x24KRB_AP_ERR_BADMATCHThe ticket and authenticator do not matchThe KRB_TGS_REQ is being sent to the wrong KDC.There’s an account mismatch during protocol transition.
0x25KRB_AP_ERR_SKEWThe clock skew is too greatThis 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.
0x26KRB_AP_ERR_BADADDRNetwork address in network layer header doesn’t match address inside ticketSession 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.
0x27KRB_AP_ERR_BADVERSIONProtocol 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.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.See RFC4120 for more details.
0x28KRB_AP_ERR_MSG_TYPEMessage type is unsupportedThis 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. This error also generated if use of UDP protocol is being attempted with User-to-User authentication.
0x29KRB_AP_ERR_MODIFIEDMessage stream modified and checksum didn’t matchThe authentication data was encrypted with the wrong key for the intended server.The authentication data was modified in transit by a hardware or software error, or by an attacker.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.The client sent the authentication data to the wrong server because DNS data was out-of-date on the client.
0x2AKRB_AP_ERR_BADORDERMessage 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 for more details.
0x2CKRB_AP_ERR_BADKEYVERSpecified version of key is not availableThis 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.
0x2DKRB_AP_ERR_NOKEYService key not availableThis 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.
0x2EKRB_AP_ERR_MUT_FAILMutual authentication failedNo information.
0x2FKRB_AP_ERR_BADDIRECTIONIncorrect message directionNo information.
0x30KRB_AP_ERR_METHODAlternative authentication method requiredAccording to RFC4120 this error message is obsolete.
0x31KRB_AP_ERR_BADSEQIncorrect sequence number in messageNo information.
0x32KRB_AP_ERR_INAPP_CKSUMInappropriate 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).
0x33KRB_AP_PATH_NOT_ACCEPTEDDesired path is unreachableNo information.
0x34KRB_ERR_RESPONSE_TOO_BIGToo much dataThe 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.
0x3CKRB_ERR_GENERICGeneric errorGroup membership has overloaded the PAC.Multiple recent password changes haven’t propagated.Crypto subsystem error caused by running out of memory.SPN too long.SPN has too many parts.
0x3DKRB_ERR_FIELD_TOOLONGField is too long for this implementationEach 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.
0x3EKDC_ERR_CLIENT_NOT_TRUSTEDThe client trust failed or is not implementedThis 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.
0x3FKDC_ERR_KDC_NOT_TRUSTEDThe KDC server trust failed or could not be verifiedThe 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 for more details.
0x40KDC_ERR_INVALID_SIGThe signature is invalidThis 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.
0x41KDC_ERR_KEY_TOO_WEAKA higher encryption level is neededIf 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.
0x42KRB_AP_ERR_USER_TO_USER_REQUIREDUser-to-user authorization is requiredIn 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, with a msg-type of KRB_AP_ERR_USER_TO_USER_REQUIRED.
0x43KRB_AP_ERR_NO_TGTNo TGT was presented or availableIn user-to-user authentication if the service doesn’t possess a ticket granting ticket, it should return the error KRB_AP_ERR_NO_TGT.
0x44KDC_ERR_WRONG_REALMIncorrect domain or principalAlthough 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 constrained Kerberos delegation was used.

Note  Service Principal Name (SPN) is the name by which a client uniquely identifies an instance of a service. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host.

Security Monitoring Recommendations

For 4769(S, F): A Kerberos service ticket was requested.

Type of monitoring requiredRecommendation
High-value accounts: You might have high-value domain or local accounts for which you need to monitor each action.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 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 events with the corresponding Account Name and Service ID fields.

  • You can track all 4769 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 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 4769 events with Client Port field value > 0 and < 1024 should be examined, because a well-known port was used for outbound connection.

  • Monitor for a Ticket Encryption Type of 0x1 or 0x3, which means the DES algorithm was used. DES should not be in use, because of low security and known vulnerabilities. It is disabled by default starting from Windows 7 and Windows Server 2008 R2.

  • Starting with Windows Vista and Windows Server 2008, monitor for a Ticket Encryption Type other than 0x11 and 0x12. These are the expected values, starting with these operating systems, and represent AES-family algorithms.

  • If you have a list of important Failure Codes, monitor for these codes.