{
	"id": "44ace072-8445-4c48-817f-1a1eb0caa8dd",
	"created_at": "2026-04-06T00:20:15.536335Z",
	"updated_at": "2026-04-10T03:20:26.210067Z",
	"deleted_at": null,
	"sha1_hash": "c67669254f1114c56fdb688d1d508051f6811050",
	"title": "4768(S, F) A Kerberos authentication ticket (TGT) was requested. - Windows 10",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 194846,
	"plain_text": "4768(S, F) A Kerberos authentication ticket (TGT) was requested. -\r\nWindows 10\r\nBy vinaypamnani-msft\r\nArchived: 2026-04-05 21:17:37 UTC\r\nUpdate: Windows Server 2016 and later OSs will display an updated version of Event 4768 after getting the January 14th,\r\n2025 or later Security Cumulative Update.\r\nUser's image\r\nPrevious version:\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 1 of 21\n\nSubcategory: Audit Kerberos Authentication Service\r\nEvent Description:\r\nThis event generates every time Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT).\r\nThis event generates only on domain controllers.\r\nIf TGT issue fails then you will see Failure event with Result Code field not equal to “0x0”.\r\nThis event doesn't generate for Result Codes: 0x10 and 0x18. Event “4771: Kerberos pre-authentication failed.” generates\r\ninstead.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 2 of 21\n\nNote\nFor recommendations, see Security Monitoring Recommendations for this event.\nEvent XML:\nUpdated Event 4768: 4768201433900x80200000000000002868SecurityDC01.contoso.local duser CONTOSO.LOCAL S-1-5-21-3114123713-1067509961-1646476345-1104 krbtgt S-1-5-21-3114123713-1067509961-1646476345-502 0x40810010 0x0 0x12 2 ::ffff:172.27.248.104 54393 j2P3Uf3sxhIsE6N4+wMt0WDyhXdVBUKMoWzmRRpxqaI= 0x27 (DES, RC4, AES-Sk) AES-SHA1, RC4 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96) AES-SHA1, RC4 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96) AES-SHA1, RC4 AES256-CTS-HMAC-SHA1-96 RC4-HMAC-NT RC4-HMAC-OLD RC4-MD4 RC4-HMAC-NT-EXP RC 0x12 0x12 Previous Event:\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\nPage 3 of 21\n\n- - 4768001433900x8020000000000000166747SecurityDC01.contoso.local - dadmin CONTOSO.LOCAL S-1-5-21-3457937927-2839227994-823803824-1104 krbtgt S-1-5-21-3457937927-2839227994-823803824-502 0x40810010 0x0 0x12 15 ::ffff:10.0.0.12 49273 contoso-DC01-CA-1 1D0000000D292FBE3C6CDDAFA200020000000D 564DFAEE99C71D62ABC553E695BD8DBC46669413 Required Server Roles: Active Directory domain controller.\nMinimum OS Version: Windows Server 2008.\nEvent Versions: 0.\nField Descriptions:\nAccount Information:\nAccount Name [Type = UnicodeString]: the name of account, for which (TGT) ticket was requested. Computer\naccount name ends with $ character.\nUser account example: dadmin\nComputer account example: WIN81$\nSupplied Realm Name [Type = UnicodeString]: the name of the Kerberos Realm that Account Name belongs to.\nThis can appear in a variety of formats, including the following:\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\nPage 4 of 21\n\nDomain NETBIOS name example: CONTOSO\r\nLowercase full domain name: contoso.local\r\nUppercase full domain name: CONTOSO.LOCAL\r\nNote\r\nA Kerberos Realm is a set of managed nodes that share the same Kerberos database. The Kerberos database resides\r\non the Kerberos master computer system, which should be kept in a physically secure room. Active Directory domain\r\nis the example of Kerberos Realm in the Microsoft Windows Active Directory world.\r\nUser ID [Type = SID]: SID of account for which (TGT) ticket was requested. Event Viewer automatically tries to\r\nresolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.\r\nFor example: CONTOSO\\dadmin or CONTOSO\\WIN81$.\r\nNULL SID – this value shows in 4768 Failure events.\r\nNote\r\nA security identifier (SID) is a unique value of variable length used to identify a trustee (security principal). Each\r\naccount has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a\r\nsecurity database. Each time a user logs on, the system retrieves the SID for that user from the database and places it\r\nin the access token for that user. The system uses the SID in the access token to identify the user in all subsequent\r\ninteractions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot\r\never be used again to identify another user or group. For more information about SIDs, see Security identifiers.\r\n[New] MSDS-SupportedEncryptionTypes [Type = UnicodeString]: Hexadecimal and string values of the account's\r\nMsDs-SupportedEncryptionTypes as stored in Active Directory. This field is sometimes referred to as \"msds-SET\"\r\nfor short. These values indicate what encryption type an account is able to use.\r\nFor computer accounts, this value is managed automatically based on the computer's encryption policy.\r\nFor Domain Controllers, Read-Only Domain Controllers, and Trusts, AES is supported-by-default unless the\r\naccount's msds-SET has been manually changed.\r\nFor user, gMSA, and other accounts, if their msds-SET has not been manually configured then Windows\r\nDomain Controllers use the value of the DefaultDomainSupportedEncType policy.\r\nThe field displays \"N/A\" if the information could not be queried or was otherwise unavailable.\r\n[New] Available Keys: [Type = UnicodeString]: List of available keys for the account stored in active directory.\r\nThese keys are generated during password sets and password changes. If the domain has a DFL of 2008 or greater\r\nand accounts have had at least one password rotation, AES keys are available for the account.\r\nService Information:\r\nService Name [Type = UnicodeString]: the name of the service in the Kerberos Realm to which TGT request was\r\nsent. Typically has value “krbtgt” for TGT requests, which means Ticket Granting Ticket issuing service.\r\nFor Failure events Service Name typically has the following format: krbtgt/REALM_NAME. For example:\r\nkrbtgt/CONTOSO.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 5 of 21\n\nService ID [Type = SID]: SID of the service account in the Kerberos Realm to which TGT request was sent. Event\r\nViewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see\r\nthe source data in the event.\r\nDomain controllers have a specific service account (krbtgt) that is used by the Key Distribution Center (KDC)\r\nservice to issue Kerberos tickets. It has a built-in, pre-defined SID: S-1-5-21-DOMAIN_IDENTIFIER-502.\r\nNULL SID – this value shows in 4768 Failure events.\r\n[New] MSDS-SupportedEncryptionTypes [Type = UnicodeString]: Hexadecimal and string values of the service's\r\nMsDs-SupportedEncryptionTypes as stored in Active Directory. This field is sometimes referred to as \"msds-SET\"\r\nfor short. These values indicate what encryption type an account is able to use.\r\nThis value is based on the account in Active Directory where the service has been registered to.\r\n[New] Available Keys: [Type = UnicodeString]: List of available keys for the service account that's stored in active\r\ndirectory. These keys are generated during password sets and password changes. If the domain has a DFL of 2008 or\r\ngreater and accounts have had at least one password rotation, AES keys are available for the service.\r\n[New] Domain Controller Information:\r\n[New] MSDS-SupportedEncryptionTypes [Type = UnicodeString]: Hexadecimal and string values of the Domain\r\nController's MsDs-SupportedEncryptionTypes as stored in Active Directory. This field is sometimes referred to as\r\n\"msds-SET\" for short. This value is determined based on the Kerberos Encryption Policy that's set on the Domain\r\nController.\r\n[New] Available Keys [Type = UnicodeString]: List of available keys for the Domain Controller. These keys are\r\ngenerated during password sets and password changes, as well as during DCPROMO. If the domain has a DFL of\r\n2008 or greater and accounts have had at least one password rotation, AES keys are available for the Domain\r\nController.\r\nNetwork Information:\r\nClient Address [Type = UnicodeString]: IP address of the computer from which the TGT request was received.\r\nFormats vary, and include the following:\r\nIPv6 or IPv4 address.\r\n::ffff:IPv4_address.\r\n::1 - localhost.\r\nClient Port [Type = UnicodeString]: source port number of client network connection (TGT request connection).\r\n0 for local (localhost) requests.\r\n[New] Advertized Etypes [Type = UnicodeString]: A list of encryption types the Kerberos client has advertised\r\nsupport for as part of the Kerberos Protocol. If an encryption type is not recognized, it's numeral value is logged.\r\nCommon types include:\r\nDecimal Value Hexidecimal Value Name\r\n0 0x0 NULL\r\n1 0x1 DES-CBC-CRC\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 6 of 21\n\nDecimal Value Hexidecimal Value Name\r\n2 0x2 DES-CBC-MD5\r\n12 0xC RC2-CBC-ENV\r\n15 0xF DES-EDE3-CBC-ENV\r\n17 0x11 AES128-CTS-HMAC-SHA1-96\r\n18 0x12 AES256-CTS-HMAC-SHA1-96\r\n23 0x18 RC4-HMAC-NT\r\n24 0x19 RC4-HMAC-NT-EXP\r\n-128 0xFFFFFF80 RC4-MD4\r\n-133 0xFFFFFF7B RC4-HMAC-OLD\r\n-135 0xFFFFFECB RC4-HMAC-OLD-EXP\r\nNote\r\nWindows clients and servers advertise a \"set\" of encryption types based on the Kerberos Encryption Policy that's deployed\r\non the machines.\r\nAdditional information:\r\nTicket Options [Type = HexInt32]: this is a set of different ticket flags in hexadecimal format.\r\nExample:\r\nTicket Options: 0x40810010\r\nBinary view: 01000000100000010000000000010000\r\nUsing MSB 0 bit numbering we have bit 1, 8, 15 and 27 set = Forwardable, Renewable, Canonicalize,\r\nRenewable-ok.\r\nNote\r\nIn the table below “MSB 0” bit numbering is used, because RFC documents use this style. In “MSB 0” style bit numbering\r\nbegins from left.\r\nThe most common values:\r\n0x40810010 - Forwardable, Renewable, Canonicalize, Renewable-ok\r\n0x40810000 - Forwardable, Renewable, Canonicalize\r\n0x60810010 - Forwardable, Forwarded, Renewable, Canonicalize, Renewable-ok\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 7 of 21\n\nBit Flag Name Description\r\n0 Reserved -\r\n1 Forwardable\r\n(TGT only). Tells the ticket-granting service that it can issue a new TGT—based on the\r\npresented TGT—with a different network address based on the presented TGT.\r\n2 Forwarded\r\nIndicates either that a TGT has been forwarded or that a ticket was issued from a forwarded\r\nTGT.\r\n3 Proxiable\r\n(TGT only). Tells the ticket-granting service that it can issue tickets with a network address\r\nthat differs from the one in the TGT.\r\n4 Proxy\r\nIndicates that the network address in the ticket is different from the one in the TGT used to\r\nobtain the ticket.\r\n5\r\nAllow-postdatePostdated tickets SHOULD NOT be supported in KILE (Microsoft Kerberos Protocol\r\nExtension).\r\n6 Postdated\r\nPostdated tickets SHOULD NOT be supported in KILE (Microsoft Kerberos Protocol\r\nExtension).\r\n7 Invalid\r\nThis flag indicates that a ticket is invalid, and it must be validated by the KDC before use.\r\nApplication servers must reject tickets which have this flag set.\r\n8 Renewable\r\nUsed in combination with the End Time and Renew Till fields to cause tickets with long life\r\nspans to be renewed at the KDC periodically.\r\n9 Initial\r\nIndicates that a ticket was issued using the authentication service (AS) exchange and not\r\nissued based on a TGT.\r\n10 Pre-authent\r\nIndicates that the client was authenticated by the KDC before a ticket was issued. This flag\r\nusually indicates the presence of an authenticator in the ticket. It can also flag the presence of\r\ncredentials taken from a smart card logon.\r\n11\r\nOpt-hardware-auth\r\nThis flag was originally intended to indicate that hardware-supported authentication was used\r\nduring pre-authentication. This flag is no longer recommended in the Kerberos V5 protocol.\r\nKDCs MUST NOT issue a ticket with this flag set. KDCs SHOULD NOT preserve this flag if\r\nit is set by another KDC.\r\n12\r\nTransited-policy-checked\r\nKILE MUST NOT check for transited domains on servers or a KDC. Application servers\r\nMUST ignore the TRANSITED-POLICY-CHECKED flag.\r\n13\r\nOk-as-delegateThe KDC MUST set the OK-AS-DELEGATE flag if the service account is trusted for\r\ndelegation.\r\n14\r\nRequest-anonymous\r\nKILE not use this flag.\r\n15\r\nName-canonicalizeIn order to request referrals the Kerberos client MUST explicitly request the \"canonicalize\"\r\nKDC option for the AS-REQ or TGS-REQ.\r\n16-\r\n25\r\nUnused -\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 8 of 21\n\nBit Flag Name Description\r\n26\r\nDisable-transited-check\r\nBy default the KDC will check the transited field of a TGT against the policy of the local\r\nrealm before it will issue derivative tickets based on the TGT. If this flag is set in the request,\r\nchecking of the transited field is disabled. Tickets issued without the performance of this check\r\nwill be noted by the reset (0) value of the TRANSITED-POLICY-CHECKED flag, indicating\r\nto the application server that the transited field must be checked locally. KDCs are encouraged\r\nbut not required to honor\r\nthe DISABLE-TRANSITED-CHECK option.\r\nShould not be in use, because Transited-policy-checked flag isn't supported by KILE.\r\n27 Renewable-ok\r\nThe RENEWABLE-OK option indicates that a renewable ticket will be acceptable if a ticket\r\nwith the requested life cannot otherwise be provided, in which case a renewable ticket may be\r\nissued with a renew-till equal to the requested end time. The value of the renew-till field may\r\nstill be limited by local limits, or limits selected by the individual principal or server.\r\n28\r\nEnc-tkt-in-skey\r\nNo information.\r\n29 Unused -\r\n30 Renew\r\nThe RENEW option indicates that the present request is for a renewal. The ticket provided is\r\nencrypted in the secret key for the server on which it is valid. This option will only be honored\r\nif the ticket to be renewed has its RENEWABLE flag set and if the time in its renew-till field\r\nhas not passed. The ticket to be renewed is passed in the padata field as part of the\r\nauthentication header.\r\n31 Validate\r\nThis option is used only by the ticket-granting service. The VALIDATE option indicates that\r\nthe request is to validate a postdated ticket. Should not be in use, because postdated tickets are\r\nnot supported by KILE.\r\nNote\r\nKILE (Microsoft Kerberos Protocol Extension) – Kerberos protocol extensions used in Microsoft operating systems.\r\nThese extensions provide additional capability for authorization information including group memberships, interactive logon\r\ninformation, and integrity levels.\r\nResult Code [Type = HexInt32]: hexadecimal result code of TGT issue operation. The “Table 3. TGT/TGS issue\r\nerror codes.” contains the list of the most common error codes for this event.\r\nCode Code Name Description Possible causes\r\n0x0 KDC_ERR_NONE No error No errors were found.\r\n0x1 KDC_ERR_NAME_EXP\r\nClient's entry\r\nin KDC\r\ndatabase has\r\nexpired\r\nNo information.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 9 of 21\n\nCode Code Name Description Possible causes\r\n0x2 KDC_ERR_SERVICE_EXP\r\nServer's entry\r\nin KDC\r\ndatabase has\r\nexpired\r\nNo information.\r\n0x3 KDC_ERR_BAD_PVNO\r\nRequested\r\nKerberos\r\nversion number\r\nnot supported\r\nNo information.\r\n0x4 KDC_ERR_C_OLD_MAST_KVNO\r\nClient's key\r\nencrypted in\r\nold master key\r\nNo information.\r\n0x5 KDC_ERR_S_OLD_MAST_KVNO\r\nServer's key\r\nencrypted in\r\nold master key\r\nNo information.\r\n0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN\r\nClient not\r\nfound in\r\nKerberos\r\ndatabase\r\nThe username doesn’t exist.\r\n0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN\r\nServer not\r\nfound in\r\nKerberos\r\ndatabase\r\nThis error can occur if the domain controller\r\ncannot find the server’s name in Active Directory\r\nThis error is similar to\r\nKDC_ERR_C_PRINCIPAL_UNKNOWN excep\r\nthat it occurs when the server name cannot be\r\nfound.\r\n0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE\r\nMultiple\r\nprincipal\r\nentries in KDC\r\ndatabase\r\nThis error occurs if duplicate principal names\r\nexist. Unique principal names are crucial for\r\nensuring mutual authentication. Thus, duplicate\r\nprincipal names are strictly forbidden, even\r\nacross multiple realms. Without unique principal\r\nnames, the client has no way of ensuring that the\r\nserver it is communicating with is the correct\r\none.\r\n0x9 KDC_ERR_NULL_KEY\r\nThe client or\r\nserver has a\r\nnull key\r\n(master key)\r\nNo master key was found for client or server.\r\nUsually it means that administrator should reset\r\nthe password on the account.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 10 of 21\n\nCode Code Name Description Possible causes\r\n0xA KDC_ERR_CANNOT_POSTDATE\r\nTicket (TGT)\r\nnot eligible for\r\npostdating\r\nThis error can occur if a client requests\r\npostdating of a Kerberos ticket. Postdating is the\r\nact of requesting that a ticket’s start time be set\r\ninto the future.\r\nIt also can occur if there is a time difference\r\nbetween the client and the KDC.\r\n0xB KDC_ERR_NEVER_VALID\r\nRequested start\r\ntime is later\r\nthan end time\r\nThere is a time difference between the KDC and\r\nthe client.\r\n0xC KDC_ERR_POLICY\r\nRequested start\r\ntime is later\r\nthan end time\r\nThis error is usually the result of logon\r\nrestrictions in place on a user’s account. For\r\nexample workstation restriction, smart card\r\nauthentication requirement or logon time\r\nrestriction.\r\n0xD KDC_ERR_BADOPTION\r\nKDC cannot\r\naccommodate\r\nrequested\r\noption\r\nImpending expiration of a TGT.\r\nThe SPN to which the client is attempting to\r\ndelegate credentials isn't in its Allowed-to-delegate-to list\r\n0xE KDC_ERR_ETYPE_NOTSUPP\r\nKDC has no\r\nsupport for\r\nencryption type\r\nIn general, this error occurs when the KDC or a\r\nclient receives a packet that it cannot decrypt.\r\n0xF KDC_ERR_SUMTYPE_NOSUPP\r\nKDC has no\r\nsupport for\r\nchecksum type\r\nThe KDC, server, or client receives a packet for\r\nwhich it does not have a key of the appropriate\r\nencryption type. The result is that the computer i\r\nunable to decrypt the ticket.\r\n0x10 KDC_ERR_PADATA_TYPE_NOSUPP\r\nKDC has no\r\nsupport for\r\nPADATA type\r\n(pre-authentication\r\ndata)\r\nSmart card logon is being attempted and the\r\nproper certificate cannot be located. This can\r\nhappen because the wrong certification authority\r\n(CA) is being queried or the proper CA cannot b\r\ncontacted.\r\nIt can also happen when a domain controller\r\ndoesn’t have a certificate installed for smart card\r\n(Domain Controller or Domain Controller\r\nAuthentication templates).\r\nThis error code cannot occur in event “4768. A\r\nKerberos authentication ticket (TGT) was\r\nrequested”. It occurs in “4771. Kerberos pre-authentication failed” event.\r\n0x11 KDC_ERR_TRTYPE_NO_SUPP\r\nKDC has no\r\nsupport for\r\ntransited type\r\nNo information.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 11 of 21\n\nCode Code Name Description Possible causes\r\n0x12 KDC_ERR_CLIENT_REVOKED\r\nClient’s\r\ncredentials\r\nhave been\r\nrevoked\r\nThis might be because of an explicit disabling or\r\nbecause of other restrictions in place on the\r\naccount. For example: account disabled, expired\r\nor locked out.\r\n0x13 KDC_ERR_SERVICE_REVOKED\r\nCredentials for\r\nserver have\r\nbeen revoked\r\nNo information.\r\n0x14 KDC_ERR_TGT_REVOKED\r\nTGT has been\r\nrevoked\r\nSince the remote KDC may change its\r\nPKCROSS key while there are PKCROSS ticket\r\nstill active, it SHOULD cache the old PKCROSS\r\nkeys until the last issued PKCROSS ticket\r\nexpires. Otherwise, the remote KDC will respon\r\nto a client with a KRB-ERROR message of type\r\nKDC_ERR_TGT_REVOKED. See RFC1510 fo\r\nmore details.\r\n0x15 KDC_ERR_CLIENT_NOTYET\r\nClient not yet\r\nvalid—try\r\nagain later\r\nNo information.\r\n0x16 KDC_ERR_SERVICE_NOTYET\r\nServer not yet\r\nvalid—try\r\nagain later\r\nNo information.\r\n0x17 KDC_ERR_KEY_EXPIRED\r\nPassword has\r\nexpired—\r\nchange\r\npassword to\r\nreset\r\nThe user’s password has expired.\r\n0x18 KDC_ERR_PREAUTH_FAILED\r\nPre-authentication\r\ninformation\r\nwas invalid\r\nThe wrong password was provided.\r\nThis error code cannot occur in event “4768. A\r\nKerberos authentication ticket (TGT) was\r\nrequested”. It occurs in “4771. Kerberos pre-authentication failed” event.\r\n0x19 KDC_ERR_PREAUTH_REQUIRED\r\nAdditional pre-authentication\r\nrequired\r\nThis error often occurs in UNIX interoperability\r\nscenarios. MIT-Kerberos clients do not request\r\npre-authentication when they send a\r\nKRB_AS_REQ message. If pre-authentication is\r\nrequired (the default), Windows systems will\r\nsend this error. Most MIT-Kerberos clients will\r\nrespond to this error by giving the pre-authentication, in which case the error can be\r\nignored, but some clients might not respond in\r\nthis way.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 12 of 21\n\nCode Code Name Description Possible causes\r\n0x1A KDC_ERR_SERVER_NOMATCH\r\nKDC does not\r\nknow about the\r\nrequested\r\nserver\r\nNo information.\r\n0x1D KDC_ERR_SVC_UNAVAILABLE\r\nKDC is\r\nunavailable\r\nNo information.\r\n0x1F KRB_AP_ERR_BAD_INTEGRITY\r\nIntegrity check\r\non decrypted\r\nfield failed\r\nThe authenticator was encrypted with something\r\nother than the session key. The result is that the\r\nclient cannot decrypt the resulting message. The\r\nmodification of the message could be the result o\r\nan attack or it could be because of network noise\r\n0x20 KRB_AP_ERR_TKT_EXPIRED\r\nThe ticket has\r\nexpired\r\nThe smaller the value for the “Maximum lifetim\r\nfor user ticket” Kerberos policy setting, the more\r\nlikely it is that this error will occur. Because\r\nticket renewal is automatic, you should not have\r\nto do anything if you get this message.\r\n0x21 KRB_AP_ERR_TKT_NYV\r\nThe ticket is\r\nnot yet valid\r\nThe ticket presented to the server isn't yet valid\r\n(in relationship to the server time). The most\r\nprobable cause is that the clocks on the KDC and\r\nthe client are not synchronized.\r\nIf cross-realm Kerberos authentication is being\r\nattempted, then you should verify time\r\nsynchronization between the KDC in the target\r\nrealm and the KDC in the client realm, as well.\r\n0x22 KRB_AP_ERR_REPEAT\r\nThe request is\r\na replay\r\nThis error indicates that a specific authenticator\r\nshowed up twice — the KDC has detected that\r\nthis session ticket duplicates one that it has\r\nalready received.\r\n0x23 KRB_AP_ERR_NOT_US\r\nThe ticket is\r\nnot for us\r\nThe server has received a ticket that was meant\r\nfor a different realm.\r\n0x24 KRB_AP_ERR_BADMATCH\r\nThe ticket and\r\nauthenticator\r\ndo not match\r\nThe KRB_TGS_REQ is being sent to the wrong\r\nKDC.\r\nThere is an account mismatch during protocol\r\ntransition.\r\n0x25 KRB_AP_ERR_SKEW\r\nThe clock skew\r\nis too great\r\nThis error is logged if a client computer sends a\r\ntimestamp whose value differs from that of the\r\nserver’s timestamp by more than the number of\r\nminutes found in the “Maximum tolerance for\r\ncomputer clock synchronization” setting in\r\nKerberos policy.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 13 of 21\n\nCode Code Name Description Possible causes\r\n0x26 KRB_AP_ERR_BADADDR\r\nNetwork\r\naddress in\r\nnetwork layer\r\nheader doesn't\r\nmatch address\r\ninside ticket\r\nSession tickets MAY include the addresses from\r\nwhich they are valid. This error can occur if the\r\naddress of the computer sending the ticket is\r\ndifferent from the valid address in the ticket. A\r\npossible cause of this could be an Internet\r\nProtocol (IP) address change. Another possible\r\ncause is when a ticket is passed through a proxy\r\nserver or NAT. The client is unaware of the\r\naddress scheme used by the proxy server, so\r\nunless the program caused the client to request a\r\nproxy server ticket with the proxy server's source\r\naddress, the ticket could be invalid.\r\n0x27 KRB_AP_ERR_BADVERSION\r\nProtocol\r\nversion\r\nnumbers don't\r\nmatch (PVNO)\r\nWhen an application receives a KRB_SAFE\r\nmessage, it verifies it. If any error occurs, an\r\nerror code is reported for use by the application.\r\nThe message is first checked by verifying that th\r\nprotocol version and type fields match the curren\r\nversion and KRB_SAFE, respectively. A\r\nmismatch generates a\r\nKRB_AP_ERR_BADVERSION.\r\nSee RFC4120 for more details.\r\n0x28 KRB_AP_ERR_MSG_TYPE\r\nMessage type\r\nis unsupported\r\nThis message is generated when target server\r\nfinds that message format is wrong. This applies\r\nto KRB_AP_REQ, KRB_SAFE, KRB_PRIV an\r\nKRB_CRED messages.\r\nThis error also generated if use of UDP protocol\r\nis being attempted with User-to-User\r\nauthentication.\r\n0x29 KRB_AP_ERR_MODIFIED\r\nMessage\r\nstream\r\nmodified and\r\nchecksum\r\ndidn't match\r\nThe authentication data was encrypted with the\r\nwrong key for the intended server.\r\nThe authentication data was modified in transit\r\nby a hardware or software error, or by an attacke\r\nThe client sent the authentication data to the\r\nwrong server because incorrect DNS data caused\r\nthe client to send the request to the wrong server\r\nThe client sent the authentication data to the\r\nwrong server because DNS data was out-of-date\r\non the client.\r\n0x2A KRB_AP_ERR_BADORDER\r\nMessage out of\r\norder (possible\r\ntampering)\r\nThis event generates for KRB_SAFE and\r\nKRB_PRIV messages if an incorrect sequence\r\nnumber is included, or if a sequence number is\r\nexpected but not present. See RFC4120 for more\r\ndetails.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 14 of 21\n\nCode Code Name Description Possible causes\r\n0x2C KRB_AP_ERR_BADKEYVER\r\nSpecified\r\nversion of key\r\nisn't available\r\nThis error might be generated on server side\r\nduring receipt of invalid KRB_AP_REQ\r\nmessage. If the key version indicated by the\r\nTicket in the KRB_AP_REQ isn't one the server\r\ncan use (e.g., it indicates an old key, and the\r\nserver no longer possesses a copy of the old key)\r\nthe KRB_AP_ERR_BADKEYVER error is\r\nreturned.\r\n0x2D KRB_AP_ERR_NOKEY\r\nService key not\r\navailable\r\nThis error might be generated on server side\r\nduring receipt of invalid KRB_AP_REQ\r\nmessage. Because it is possible for the server to\r\nbe registered in multiple realms, with different\r\nkeys in each, the realm field in the unencrypted\r\nportion of the ticket in the KRB_AP_REQ is use\r\nto specify which secret key the server should use\r\nto decrypt that ticket. The\r\nKRB_AP_ERR_NOKEY error code is returned\r\nthe server doesn't have the proper key to deciphe\r\nthe ticket.\r\n0x2E KRB_AP_ERR_MUT_FAIL\r\nMutual\r\nauthentication\r\nfailed\r\nNo information.\r\n0x2F KRB_AP_ERR_BADDIRECTION\r\nIncorrect\r\nmessage\r\ndirection\r\nNo information.\r\n0x30 KRB_AP_ERR_METHOD\r\nAlternative\r\nauthentication\r\nmethod\r\nrequired\r\nAccording to RFC4120 this error message is\r\nobsolete.\r\n0x31 KRB_AP_ERR_BADSEQ\r\nIncorrect\r\nsequence\r\nnumber in\r\nmessage\r\nNo information.\r\n0x32 KRB_AP_ERR_INAPP_CKSUM\r\nInappropriate\r\ntype of\r\nchecksum in\r\nmessage\r\n(checksum\r\nmay be\r\nunsupported)\r\nWhen KDC receives KRB_TGS_REQ message\r\ndecrypts it, and after that, the user-supplied\r\nchecksum in the Authenticator MUST be verified\r\nagainst the contents of the request. The message\r\nMUST be rejected either if the checksums do no\r\nmatch (with an error code of\r\nKRB_AP_ERR_MODIFIED) or if the checksum\r\nisn't collision-proof (with an error code of\r\nKRB_AP_ERR_INAPP_CKSUM).\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 15 of 21\n\nCode Code Name Description Possible causes\r\n0x33 KRB_AP_PATH_NOT_ACCEPTED\r\nDesired path is\r\nunreachable\r\nNo information.\r\n0x34 KRB_ERR_RESPONSE_TOO_BIG Too much data\r\nThe size of a ticket is too large to be transmitted\r\nreliably via UDP. In a Windows environment, th\r\nmessage is purely informational. A computer\r\nrunning a Windows operating system will\r\nautomatically try TCP if UDP fails.\r\n0x3C KRB_ERR_GENERIC Generic error\r\nGroup membership has overloaded the PAC.\r\nMultiple recent password changes have not\r\npropagated.\r\nCrypto subsystem error caused by running out of\r\nmemory.\r\nSPN too long.\r\nSPN has too many parts.\r\n0x3D KRB_ERR_FIELD_TOOLONG\r\nField is too\r\nlong for this\r\nimplementation\r\nEach request (KRB_KDC_REQ) and response\r\n(KRB_KDC_REP or KRB_ERROR) sent over\r\nthe TCP stream is preceded by the length of the\r\nrequest as 4 octets in network byte order. The\r\nhigh bit of the length is reserved for future\r\nexpansion and MUST currently be set to zero. If\r\na KDC that does not understand how to interpret\r\na set high bit of the length encoding receives a\r\nrequest with the high order bit of the length set, i\r\nMUST return a KRB-ERROR message with the\r\nerror KRB_ERR_FIELD_TOOLONG and\r\nMUST close the TCP stream.\r\n0x3E KDC_ERR_CLIENT_NOT_TRUSTED\r\nThe client trust\r\nfailed or isn't\r\nimplemented\r\nThis typically happens when user’s smart-card\r\ncertificate is revoked or the root Certification\r\nAuthority that issued the smart card certificate (i\r\na chain) isn't trusted by the domain controller.\r\n0x3F KDC_ERR_KDC_NOT_TRUSTED\r\nThe KDC\r\nserver trust\r\nfailed or could\r\nnot be verified\r\nThe trustedCertifiers field contains a list of\r\ncertification authorities trusted by the client, in\r\nthe case that the client does not possess the\r\nKDC's public key certificate. If the KDC has no\r\ncertificate signed by any of the trustedCertifiers,\r\nthen it returns an error of type\r\nKDC_ERR_KDC_NOT_TRUSTED. See\r\nRFC1510 for more details.\r\n0x40 KDC_ERR_INVALID_SIG\r\nThe signature\r\nis invalid\r\nThis error is related to PKINIT. If a PKI trust\r\nrelationship exists, the KDC then verifies the\r\nclient's signature on AuthPack (TGT request\r\nsignature). If that fails, the KDC returns an error\r\nmessage of type KDC_ERR_INVALID_SIG.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 16 of 21\n\nCode Code Name Description Possible causes\r\n0x41 KDC_ERR_KEY_TOO_WEAK\r\nA higher\r\nencryption\r\nlevel is needed\r\nIf the clientPublicValue field is filled in,\r\nindicating that the client wishes to use Diffie-Hellman key agreement, then the KDC checks to\r\nsee that the parameters satisfy its policy. If they\r\ndo not (e.g., the prime size is insufficient for the\r\nexpected encryption type), then the KDC sends\r\nback an error message of type\r\nKDC_ERR_KEY_TOO_WEAK.\r\n0x42 KRB_AP_ERR_USER_TO_USER_REQUIRED\r\nUser-to-user\r\nauthorization is\r\nrequired\r\nIn the case that the client application doesn't\r\nknow that a service requires user-to-user\r\nauthentication, and requests and receives a\r\nconventional KRB_AP_REP, the client will send\r\nthe KRB_AP_REP request, and the server will\r\nrespond with a KRB_ERROR token as described\r\nin RFC1964, with a msg-type of\r\nKRB_AP_ERR_USER_TO_USER_REQUIRED\r\n0x43 KRB_AP_ERR_NO_TGT\r\nNo TGT was\r\npresented or\r\navailable\r\nIn user-to-user authentication if the service does\r\nnot possess a ticket granting ticket, it should\r\nreturn the error KRB_AP_ERR_NO_TGT.\r\n0x44 KDC_ERR_WRONG_REALM\r\nIncorrect\r\ndomain or\r\nprincipal\r\nAlthough this error rarely occurs, it occurs when\r\na client presents a cross-realm TGT to a realm\r\nother than the one specified in the TGT.\r\nTypically, this results from incorrectly configure\r\nDNS.\r\nTicket Encryption Type [Type = HexInt32]: the cryptographic suite that was used for issued TGT. These values are\r\nthe same as the \"Advertised Etypes\" field, with some minor name changes.\r\n[New] Session Encryption Type [Type = HexInt32]: the cryptographic suite that was used for session key in the\r\nissued TGT. These values are the same as the \"Advertised Etypes\" field, with some minor name changes.\r\nTable 4. Kerberos encryption types\r\nType Type Name Description\r\n0x1 DES-CBC-CRC\r\nDisabled by default starting from Windows 7 and Windows\r\nServer 2008 R2.\r\n0x3 DES-CBC-MD5\r\nDisabled by default starting from Windows 7 and Windows\r\nServer 2008 R2.\r\n0x11\r\nAES128-CTS-HMAC-SHA1-96Supported starting from Windows Server 2008 and Windows\r\nVista.\r\n0x12\r\nAES256-CTS-HMAC-SHA1-96Supported starting from Windows Server 2008 and Windows\r\nVista.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 17 of 21\n\nType Type Name Description\r\n0x17 RC4-HMAC\r\nDefault suite for operating systems before Windows Server 2008\r\nand Windows Vista.\r\n0x18 RC4-HMAC-EXP\r\nDefault suite for operating systems before Windows Server 2008\r\nand Windows Vista.\r\n0xFFFFFFFF or\r\n0xffffffff\r\n- This type shows in Audit Failure events.\r\nPre-Authentication Type [Type = UnicodeString]: the code number of pre-Authentication type which was used in\r\nTGT request.\r\n[New] Pre-Authentication EncryptionType [Type = HexInt32]: The Encryption Type that was selected for the Pre-Authentication flow. The values are the same as the \"Ticket Encryption Type\" field.\r\nTable 5. Kerberos Pre-Authentication types\r\nType Type Name Description\r\n0 - Logon without Pre-Authentication.\r\n2\r\nPA-ENC-TIMESTAMP\r\nThis is a normal type for standard password authentication.\r\n11 PA-ETYPE-INFO\r\nThe ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-ERROR\r\nindicating a requirement for additional pre-authentication. It is usually used to notify a\r\nclient of which key to use for the encryption of an encrypted timestamp for the purposes\r\nof sending a PA-ENC-TIMESTAMP pre-authentication value.\r\nNever saw this Pre-Authentication Type in Microsoft Active Directory environment.\r\n15\r\nPA-PK-AS-REP_OLD\r\nUsed for Smart Card logon authentication.\r\n16 PA-PK-AS-REQ Request sent to KDC in Smart Card authentication scenarios.\r\n17 PA-PK-AS-REP\r\nThis type should also be used for Smart Card authentication, but in certain Active\r\nDirectory environments, it is never seen.\r\n19 PA-ETYPE-INFO2\r\nThe ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-ERROR\r\nindicating a requirement for additional pre-authentication. It is usually used to notify a\r\nclient of which key to use for the encryption of an encrypted timestamp for the purposes\r\nof sending a PA-ENC-TIMESTAMP pre-authentication value.\r\nNever saw this Pre-Authentication Type in Microsoft Active Directory environment.\r\n20\r\nPA-SVR-REFERRAL-INFO\r\nUsed in KDC Referrals tickets.\r\n138\r\nPA-ENCRYPTED-CHALLENGELogon using Kerberos Armoring (FAST). Supported starting from Windows Server\r\n2012 domain controllers and Windows 8 clients.\r\n- This type shows in Audit Failure events.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 18 of 21\n\nCertificate Information:\r\nCertificate Issuer Name [Type = UnicodeString]: the name of the Certification Authority that issued the smart card\r\ncertificate. Populated in Issued by field in certificate.\r\nCertificate Serial Number [Type = UnicodeString]: smart card certificate’s serial number. Can be found in Serial\r\nnumber field in the certificate.\r\nCertificate Thumbprint [Type = UnicodeString]: smart card certificate’s thumbprint. Can be found in Thumbprint\r\nfield in the certificate.\r\n[New] Ticket Information\r\n[New] Response ticket hash [Type = UnicodeString]: The hash of the ticket that the Windows Domain Controller\r\nreplied back to the client as part of the Response.\r\nSecurity Monitoring Recommendations\r\nFor 4768(S, F): A Kerberos authentication ticket (TGT) was requested.\r\nType of monitoring required Recommendation\r\nHigh-value accounts: You might have high-value domain or\r\nlocal accounts for which you need to monitor each action.\r\nExamples of high-value accounts are database administrators,\r\nbuilt-in local administrator account, domain administrators,\r\nservice accounts, domain controller accounts and so on.\r\nMonitor this event with the “User ID” that\r\ncorresponds to the high-value account or accounts.\r\nAnomalies or malicious actions: You might have specific\r\nrequirements for detecting anomalies or monitoring potential\r\nmalicious actions. For example, you might need to monitor for\r\nuse of an account outside of working hours.\r\nWhen you monitor for anomalies or malicious\r\nactions, use the “User ID” (with other information)\r\nto monitor how or when a particular account is\r\nbeing used.\r\nNon-active accounts: You might have non-active, disabled, or\r\nguest accounts, or other accounts that should never be used.\r\nMonitor this event with the “User ID” that\r\ncorresponds to the accounts that should never be\r\nused.\r\nAccount allowlist: You might have a specific allowlist of\r\naccounts that are the only ones allowed to perform actions\r\ncorresponding to particular events.\r\nIf this event corresponds to an “allowlist-only”\r\naction, review the “User ID” for accounts that are\r\noutside the allowlist.\r\nExternal accounts: You might be monitoring accounts from\r\nanother domain, or “external” accounts that are not allowed to\r\nperform certain actions (represented by certain specific events).\r\nMonitor this event for the “Supplied Realm\r\nName” corresponding to another domain or\r\n“external” location.\r\nAccount naming conventions: Your organization might have\r\nspecific naming conventions for account names.\r\nMonitor “User ID” for names that don’t comply\r\nwith naming conventions.\r\nYou can track all 4768 events where the Client Address isn't from your internal IP address range or not from private\r\nIP address ranges.\r\nIf you know that Account Name should be used only from known list of IP addresses, track all Client Address\r\nvalues for this Account Name in 4768 events. If Client Address isn't from the allowlist, generate the alert.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 19 of 21\n\nAll Client Address = ::1 means local authentication. If you know the list of accounts which should log on to the\r\ndomain controllers, then you need to monitor for all possible violations, where Client Address = ::1 and Account\r\nName isn't allowed to log on to any domain controller.\r\nAll 4768 events with Client Port field value \u003e 0 and \u003c 1024 should be examined, because a well-known port was\r\nused for outbound connection.\r\nAlso consider monitoring the fields shown in the following table, to discover the issues listed:\r\nField Issue to discover\r\nCertificate Issuer\r\nName\r\nCertification authority name is not from your PKI.\r\nCertificate Issuer\r\nName\r\nCertification authority name is not authorized to issue smart card authentication certificates.\r\nPre-Authentication\r\nType\r\nValue is 0, which means that pre-authentication was not used. All accounts should use Pre-Authentication, except accounts configured with “Do not require Kerberos preauthentication,”\r\nwhich is a security risk. For more information, see Table 5. Kerberos Pre-Authentication types.\r\nPre-Authentication\r\nType\r\nValue is not 15 when account must use a smart card for authentication. For more information, see\r\nTable 5. Kerberos Pre-Authentication types.\r\nPre-Authentication\r\nType\r\nValue is not 2 when only standard password authentication is in use in the organization. For more\r\ninformation, see Table 5. Kerberos Pre-Authentication types.\r\nPre-Authentication\r\nType\r\nValue is not 138 when Kerberos Armoring is enabled for all Kerberos communications in the\r\norganization. For more information, see Table 5. Kerberos Pre-Authentication types.\r\nTicket\r\nEncryption Type\r\nValue is 0x1 or 0x3, which means the DES algorithm was used. DES should not be in use, because\r\nof low security and known vulnerabilities. It is disabled by default starting from Windows 7 and\r\nWindows Server 2008 R2. For more information, see Table 4. Kerberos encryption types.\r\nTicket\r\nEncryption Type\r\nStarting with Windows Vista and Windows Server 2008, monitor for values other than 0x11 and\r\n0x12. These are the expected values, starting with these operating systems, and represent AES-family algorithms. For more information, see Table 4. Kerberos encryption types.\r\nResult Code\r\n0x6 (The username doesn't exist), if you see, for example N events in last N minutes. This can be\r\nan indicator of account enumeration attack, especially for highly critical accounts.\r\nResult Code\r\n0x7 (Server not found in Kerberos database). This error can occur if the domain controller cannot\r\nfind the server's name in Active Directory.\r\nResult Code 0x8 (Multiple principal entries in KDC database). This will help you to find duplicate SPNs faster.\r\nResult Code\r\n0x9 (The client or server has a null key (master key)). This error can help you to identify problems\r\nwith Kerberos authentication faster.\r\nResult Code\r\n0xA (Ticket (TGT) not eligible for postdating). Microsoft systems should not request postdated\r\ntickets. These events could help identify anomaly activity.\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 20 of 21\n\nField Issue to discover\r\nResult Code\r\n0xC (Requested start time is later than end time), if you see, for example N events in last N\r\nminutes. This can be an indicator of an account compromise attempt, especially for highly critical\r\naccounts.\r\nResult Code\r\n0xE (KDC has no support for encryption type). In general, this error occurs when the KDC or a\r\nclient receives a packet that it cannot decrypt. Monitor for these events because this should not\r\nhappen in a standard Active Directory environment.\r\nResult Code\r\n0xF (KDC has no support for checksum type). Monitor for these events because this should not\r\nhappen in a standard Active Directory environment.\r\nResult Code\r\n0x12 (Client's credentials have been revoked), if you see, for example N events in last N minutes.\r\nThis can be an indicator of anomaly activity or brute-force attack, especially for highly critical\r\naccounts.\r\nResult Code\r\n0x1F (Integrity check on decrypted field failed). The authenticator was encrypted with something\r\nother than the session key. The result is that the KDC cannot decrypt the TGT. The modification of\r\nthe message could be the result of an attack or it could be because of network noise.\r\nResult Code\r\n0x22 (The request is a replay). This error indicates that a specific authenticator showed up twice—\r\nthe KDC has detected that this session ticket duplicates one that it has already received. It could\r\nbe a sign of attack attempt.\r\nResult Code\r\n0x29 (Message stream modified and checksum didn't match). The authentication data was\r\nencrypted with the wrong key for the intended server. The authentication data was modified in\r\ntransit by a hardware or software error, or by an attacker. Monitor for these events because this\r\nshould not happen in a standard Active Directory environment.\r\nResult Code\r\n0x3C (Generic error). This error can help you more quickly identify problems with Kerberos\r\nauthentication.\r\nResult Code\r\n0x3E (The client trust failed or is not implemented). This error helps you identify logon attempts\r\nwith revoked certificates and the situations when the root Certification Authority that issued the\r\nsmart card certificate (through a chain) is not trusted by a domain controller.\r\nResult Code\r\n0x3F, 0x40, 0x41 errors. These errors can help you more quickly identify smart-card related\r\nproblems with Kerberos authentication.\r\nSource: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nhttps://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768"
	],
	"report_names": [
		"event-4768"
	],
	"threat_actors": [],
	"ts_created_at": 1775434815,
	"ts_updated_at": 1775791226,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c67669254f1114c56fdb688d1d508051f6811050.pdf",
		"text": "https://archive.orkl.eu/c67669254f1114c56fdb688d1d508051f6811050.txt",
		"img": "https://archive.orkl.eu/c67669254f1114c56fdb688d1d508051f6811050.jpg"
	}
}