Direct Inward Dialing: +1 408 916 9892
The first time a user enters their domain username and password into their workstation, the workstation contacts a local domain controller (DC) and requests a ticket-granting ticket (TGT). If the username and password are valid and the user account passes status and restriction checks, then the DC grants a TGT and logs event ID 4768 (authentication ticket granted).
Figure 1. Kerberos authentication.
Windows records event ID 4771 (F) if the ticket request (Step 1 of Figure 1) failed; this event is only recorded on DCs. If the problem arose during pre-authentication (either steps 2, 3, or 4 of Figure 1), Windows records event 4768 instead.
|1||Forwardable||This flag is for TGTs only. This tells the ticket-granting service that it can issue a new TGT with a different network address based on the presented TGT.|
|2||Forwarded||This flag indicates either that a TGT has been forwarded or that a ticket was issued from a forwarded TGT.|
|3||Proxiable||This flag is for TGTs only. This tells the ticket-granting service that it can issue tickets with a network address that differs from the one in the TGT.|
|4||Proxy||This flag indicates that the network address in the ticket is different from the one in the TGT used to obtain the ticket.|
|5||Allow-postdate||This flag indicates that the ticket to be issued is to have its MAY-POSTDATE flag set. It may only be set on the initial request or in a subsequent request if the TGT on which it is based also has its MAY-POSTDATE flag set.
Postdated tickets are not supported in KILE (Microsoft Kerberos Protocol Extension).
|6||Postdated||This flag indicates that this is a request for a postdated ticket. This option will only be honored if the TGT on which it is based has its MAY-POSTDATE flag set. The resulting ticket will also have its INVALID flag set, and that flag may be reset by a subsequent request to the KDC after the start time in the ticket has been reached.
Postdated tickets are not supported in KILE (Microsoft Kerberos Protocol Extension).
|7||Invalid||This flag indicates that a ticket is invalid, meaning it must be validated by the key distribution center (KDC) before use. Application servers must reject tickets which have this flag set.|
|8||Renewable||This flag is used in combination with the End Time and Renew Till fields to cause tickets with long life spans to be renewed at the KDC periodically.|
|9||Initial||This flag indicates that a ticket was issued using the authentication service (AS) exchange and not issued based on a TGT.|
|10||Pre-authent||This flag indicates 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, but it could also indicate the presence of credentials that were taken from a Smart Card logon.|
|11||Opt-hardware-auth||This 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. Likewise, KDCs should not preserve this flag if it was set by another KDC.|
|12||Transited-policy-checked||This flag indicates that KILE must not check for transited domains on servers or a KDC. Application servers must ignore the TRANSITED-POLICY-CHECKED flag.|
|13||Ok-as-delegate||The KDC must set the OK-AS-DELEGATE flag if the service account is trusted for delegation.|
|14||Request-anonymous||KILE does not use this flag.|
|15||Name-canonicalize||If this flag is set to true, initial ticket requests to the KDC will request canonicalization of the client principal name, and answers with different client principals than the requested principal will be accepted. The default value is false.|
|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, the transited field will not be checked. 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 the DISABLE-TRANSITED-CHECK option. This flag should not be in use due to the Transited-policy-checked flag not being supported by KILE.
|27||Renewable-ok||This flag 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 value 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||This option is used only by the ticket-granting service. The ENC-TKT-IN-SKEY option indicates that the ticket for the end server is to be encrypted in the session key from the additional TGT provided.|
|30||Renew||This flag indicates that the present request is for a renewal. The ticket provided to this request is encrypted in the secret key for the server on which it is valid. This option will only be honored if the ticket that is being renewed has its RENEWABLE flag set and if the time in its renew-till field has not passed. The ticket being renewed is passed in the padata field as part of the authentication header.|
|31||Validate||This flag indicates that the request is to validate a postdated ticket. This option is used only by the ticket-granting service; however, it shouldn't be used because postdated tickets are not supported by KILE.|
|Code||Code name||Description||Possible causes|
|0x10||KDC_ERR_PADATA_TYPE_NOSUPP||KDC has no support for the 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 in order to get domain controller authentication certificates for the DC. It can also happen when a DC doesn’t have a certificate installed for Smart Cards.|
|0x17||KDC_ERR_KEY_EXPIRED||Password has expired—change password to reset.||The user’s password has expired.|
|0x18||KDC_ERR_PREAUTH_FAILED||Pre-authentication information was invalid.||The wrong password was provided.|
|0||-||This code indicates a logon without pre-authentication.|
|2||PA-ENC-TIMESTAMP||This code is the normal type for standard password authentication.|
|11||PA-ETYPE-INFO||This code is sent by the KDC in a KRB-ERROR, indicating additional pre-authentication is required. It is usually used to notify a client of which encryption key to use to encrypt a timestamp when sending a PA-ENC-TIMESTAMP pre-authentication value.|
|15||PA-PK-AS-REP_OLD||This code is used for Smart Card logon authentication.|
|17||PA-PK-AS-REP||This code should also be used for Smart Card authentication, but it's never seen in certain Active Directory environments.|
|19||PA-ETYPE-INFO2||This code is sent by the KDC in a KRB-ERROR indicating that it requires additional pre-authentication. Usually, it's used to notify a client of which key to use for the encryption of an encrypted timestamp for the purpose of sending a PA-ENC-TIMESTAMP pre-authentication value.|
|20||PA-SVR-REFERRAL-INFO||This code is used in KDC Referrals tickets.|
|138||PA-ENCRYPTED-CHALLENGE||This code is used to indicate a logon using Kerberos Armoring (FAST). Support for this code started with Windows Server 2012 and Windows 8.|
|-||This code is displayed in Audit Failure events.|
This information is only filled for logons with a Smart Card. It is always empty for event ID 4771.
Although you can attach a task to the security log and ask Windows to send you an email, you are limited to simply getting an email whenever event ID 4771 is generated. Windows also lacks the ability to apply more granular filters that are required to meet security recommendations.
With a tool like ADAudit Plus, not only can you apply granular filters to focus on real threats, you can get notified in real time via SMS, too.
Leverage advanced statistical analysis and machine learning techniques to detect anomalous behavior within your network.
Meet various compliance standards, such as SOX, HIPAA, PCI, FISMA, GLBA, and the GDPR with out-of-the-box compliance reports.
Go from downloading ADAudit Plus to receiving real-time alerts in less than 30 minutes. With over 200 preconfigured reports and alerts, ADAudit Plus ensures that your Active Directory stays secure and compliant.