Generates And Issues Session Keys In Kerberos

-->

In Kerberos parlance, the former message is often called the user's credentials, the latter message is called the ticket, and the random key is called the session key. At this stage, only the user knows the session key (provided he really is the user and knows the appropriate long-term key).

Applies to

Windows 10
Windows Server 2016

Subcategory:Audit Kerberos Authentication Service

Event Description:

This event generates every time Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT).

This event generates only on domain controllers.

If TGT issue fails then you will see Failure event with Result Code field not equal to “0x0”.

This event doesn't generate for Result Codes: 0x10, 0x17 and 0x18. Event “4771: Kerberos pre-authentication failed.” generates instead.

Note For recommendations, see Security Monitoring Recommendations for this event.

Event XML:

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 name of account, for which (TGT) ticket was requested. Computer account name ends with $ character.
- User account example: dadmin
- Computer account example: WIN81$
Supplied Realm Name [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

Note A Kerberos Realm is a set of managed nodes that share the same Kerberos database. The Kerberos database resides on the Kerberos master computer system, which should be kept in a physically secure room. Active Directory domain is the example of Kerberos Realm in the Microsoft Windows Active Directory world.

User ID [Type = SID]: SID of account for which (TGT) ticket was requested. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
For example: CONTOSOdadmin or CONTOSOWIN81$.
- NULL SID – this value shows in 4768 Failure events.

Note A security identifier (SID) is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see Security identifiers.

Service Information:

Service Name [Type = UnicodeString]: the name of the service in the Kerberos Realm to which TGT request was sent. Typically has value “krbtgt” for TGT requests, which means Ticket Granting Ticket issuing service.
- For Failure events Service Name typically has the following format: krbtgt/REALM_NAME. For example: krbtgt/CONTOSO.
Service ID [Type = SID]: SID of the service account in the Kerberos Realm to which TGT request was sent. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
Domain controllers have a specific service account (krbtgt) that is used by the Key Distribution Center (KDC) service to issue Kerberos tickets. It has a built-in, pre-defined SID: S-1-5-21-DOMAIN_IDENTIFIER-502.
- NULL SID – this value shows in 4768 Failure events.

Network Information:

Client Address [Type = UnicodeString]: IP address of the computer from which the TGT 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 (TGT 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

Bit	Flag Name	Description
0	Reserved	-
1	Forwardable	(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.
2	Forwarded	Indicates either that a TGT has been forwarded or that a ticket was issued from a forwarded TGT.
3	Proxiable	(TGT only). Tells the ticket-granting service that it can issue tickets with a network address that differs from the one in the TGT.
4	Proxy	Indicates that the network address in the ticket is different from the one in the TGT used to obtain the ticket.
5	Allow-postdate	Postdated tickets SHOULD NOT be supported in KILE (Microsoft Kerberos Protocol Extension).
6	Postdated	Postdated tickets SHOULD NOT be supported in KILE (Microsoft Kerberos Protocol Extension).
7	Invalid	This 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.
8	Renewable	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	Indicates that a ticket was issued using the authentication service (AS) exchange and not issued based on a TGT.
10	Pre-authent	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. It can also flag the presence of credentials 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. KDCs SHOULD NOT preserve this flag if it is set by another KDC.
12	Transited-policy-checked	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 not use this flag.
15	Name-canonicalize	In order to request referrals the Kerberos client MUST explicitly request the 'canonicalize' KDC option for the AS-REQ or TGS-REQ.
16-25	Unused	-
26	Disable-transited-check	By default the KDC will check the transited field of a TGT against the policy of the local realm before it will issue derivative tickets based on the TGT. If this flag is set in the request, checking of the transited field is disabled. Tickets issued without the performance of this check will be noted by the reset (0) value of the TRANSITED-POLICY-CHECKED flag, indicating to the application server that the transited field must be checked locally. KDCs are encouraged but not required to honor the DISABLE-TRANSITED-CHECK option. Should not be in use, because Transited-policy-checked flag is not supported by KILE.
27	Renewable-ok	The RENEWABLE-OK option indicates that a renewable ticket will be acceptable if a ticket with the requested life cannot otherwise be provided, in which case a renewable ticket may be issued with a renew-till equal to the requested end time. The value of the renew-till field may still be limited by local limits, or limits selected by the individual principal or server.
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.
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.

NoteKILE(Microsoft Kerberos Protocol Extension) – Kerberos protocol extensions used in Microsoft operating systems. These extensions provide additional capability for authorization information including group memberships, interactive logon information, and integrity levels.

Result Code [Type = HexInt32]: hexadecimal result code of TGT issue operation. The “Table 3. TGT/TGS issue error codes.” contains the list of the most common error codes for this event.

Code	Code Name	Description	Possible causes
0x0	KDC_ERR_NONE	No error	No errors were found.
0x1	KDC_ERR_NAME_EXP	Client's entry in KDC database has expired	No information.
0x2	KDC_ERR_SERVICE_EXP	Server's entry in KDC database has expired	No information.
0x3	KDC_ERR_BAD_PVNO	Requested Kerberos version number not supported	No information.
0x4	KDC_ERR_C_OLD_MAST_KVNO	Client's key encrypted in old master key	No information.
0x5	KDC_ERR_S_OLD_MAST_KVNO	Server's key encrypted in old master key	No information.
0x6	KDC_ERR_C_PRINCIPAL_UNKNOWN	Client not found in Kerberos database	The username doesn’t exist.
0x7	KDC_ERR_S_PRINCIPAL_UNKNOWN	Server not found in Kerberos database	This error can occur if the domain controller cannot find the server’s name in Active Directory. This error is similar to KDC_ERR_C_PRINCIPAL_UNKNOWN except that it occurs when the server name cannot be found.
0x8	KDC_ERR_PRINCIPAL_NOT_UNIQUE	Multiple principal entries in KDC database	This error occurs if duplicate principal names exist. Unique principal names are crucial for ensuring mutual authentication. Thus, duplicate principal names are strictly forbidden, even across multiple realms. Without unique principal names, the client has no way of ensuring that the server it is communicating with is the correct one.
0x9	KDC_ERR_NULL_KEY	The client or server has a null key (master key)	No master key was found for client or server. Usually it means that administrator should reset the password on the account.
0xA	KDC_ERR_CANNOT_POSTDATE	Ticket (TGT) not eligible for postdating	This error can occur if a client requests postdating of a Kerberos ticket. Postdating is the act of requesting that a ticket’s start time be set into the future. It also can occur if there is a time difference between the client and the KDC.
0xB	KDC_ERR_NEVER_VALID	Requested start time is later than end time	There is a time difference between the KDC and the client.
0xC	KDC_ERR_POLICY	Requested start time is later than end time	This error is usually the result of logon restrictions in place on a user’s account. For example workstation restriction, smart card authentication requirement or logon time restriction.
0xD	KDC_ERR_BADOPTION	KDC cannot accommodate requested option	Impending expiration of a TGT. The SPN to which the client is attempting to delegate credentials is not in its Allowed-to-delegate-to list
0xE	KDC_ERR_ETYPE_NOTSUPP	KDC has no support for encryption type	In general, this error occurs when the KDC or a client receives a packet that it cannot decrypt.
0xF	KDC_ERR_SUMTYPE_NOSUPP	KDC has no support for checksum type	The KDC, server, or client receives a packet for which it does not have a key of the appropriate encryption type. The result is that the computer is unable to decrypt the ticket.
0x10	KDC_ERR_PADATA_TYPE_NOSUPP	KDC has no support for PADATA type (pre-authentication data)	Smart card logon is being attempted and the proper certificate cannot be located. This can happen because the wrong certification authority (CA) is being queried or the proper CA cannot be contacted. 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 cannot occur in event “4768. A Kerberos authentication ticket (TGT) was requested”. It occurs in “4771. Kerberos pre-authentication failed” event.
0x11	KDC_ERR_TRTYPE_NO_SUPP	KDC has no support for transited type	No information.
0x12	KDC_ERR_CLIENT_REVOKED	Client’s credentials have been revoked	This might be because of an explicit disabling or because of other restrictions in place on the account. For example: account disabled, expired, or locked out.
0x13	KDC_ERR_SERVICE_REVOKED	Credentials for server have been revoked	No information.
0x14	KDC_ERR_TGT_REVOKED	TGT has been revoked	Since the remote KDC may change its PKCROSS key while there are PKCROSS tickets still active, it SHOULD cache the old PKCROSS keys until the last issued PKCROSS ticket expires. Otherwise, the remote KDC will respond to a client with a KRB-ERROR message of type KDC_ERR_TGT_REVOKED. See RFC1510 for more details.
0x15	KDC_ERR_CLIENT_NOTYET	Client not yet valid—try again later	No information.
0x16	KDC_ERR_SERVICE_NOTYET	Server not yet valid—try again later	No information.
0x17	KDC_ERR_KEY_EXPIRED	Password has expired—change password to reset	The user’s password has expired. This error code cannot occur in event “4768. A Kerberos authentication ticket (TGT) was requested”. It occurs in “4771. Kerberos pre-authentication failed” event.
0x18	KDC_ERR_PREAUTH_FAILED	Pre-authentication information was invalid	The wrong password was provided. This error code cannot occur in event “4768. A Kerberos authentication ticket (TGT) was requested”. It occurs in “4771. Kerberos pre-authentication failed” event.
0x19	KDC_ERR_PREAUTH_REQUIRED	Additional pre-authentication required	This error often occurs in UNIX interoperability scenarios. MIT-Kerberos clients do not request pre-authentication when they send a KRB_AS_REQ message. If pre-authentication is required (the default), Windows systems will send this error. Most MIT-Kerberos clients will respond to this error by giving the pre-authentication, in which case the error can be ignored, but some clients might not respond in this way.
0x1A	KDC_ERR_SERVER_NOMATCH	KDC does not know about the requested server	No information.
0x1D	KDC_ERR_SVC_UNAVAILABLE	KDC is unavailable	No information.
0x1F	KRB_AP_ERR_BAD_INTEGRITY	Integrity check on decrypted field failed	The authenticator was encrypted with something other than the session key. The result is that the client cannot decrypt the resulting message. The modification of the message could be the result of an attack or it could be because of network noise.
0x20	KRB_AP_ERR_TKT_EXPIRED	The ticket has expired	The smaller the value for the “Maximum lifetime for user ticket” Kerberos policy setting, the more likely it is that this error will occur. Because ticket renewal is automatic, you should not have to do anything if you get this message.
0x21	KRB_AP_ERR_TKT_NYV	The ticket is not yet valid	The ticket presented to the server is not yet valid (in relationship to the server time). The most probable cause is that the clocks on the KDC and the client are not synchronized. If cross-realm Kerberos authentication is being attempted, then you should verify time synchronization between the KDC in the target realm and the KDC in the client realm, as well.
0x22	KRB_AP_ERR_REPEAT	The request is a replay	This error indicates that a specific authenticator showed up twice — the KDC has detected that this session ticket duplicates one that it has already received.
0x23	KRB_AP_ERR_NOT_US	The ticket is not for us	The server has received a ticket that was meant for a different realm.
0x24	KRB_AP_ERR_BADMATCH	The ticket and authenticator do not match	The KRB_TGS_REQ is being sent to the wrong KDC. There is an account mismatch during protocol transition.
0x25	KRB_AP_ERR_SKEW	The clock skew is too great	This error is logged if a client computer sends a timestamp whose value differs from that of the server’s timestamp by more than the number of minutes found in the “Maximum tolerance for computer clock synchronization” setting in Kerberos policy.
0x26	KRB_AP_ERR_BADADDR	Network address in network layer header doesn't match address inside ticket	Session tickets MAY include the addresses from which they are valid. This error can occur if the address of the computer sending the ticket is different from the valid address in the ticket. A possible cause of this could be an Internet Protocol (IP) address change. Another possible cause is when a ticket is passed through a proxy server or NAT. The client is unaware of the address scheme used by the proxy server, so unless the program caused the client to request a proxy server ticket with the proxy server's source address, the ticket could be invalid.
0x27	KRB_AP_ERR_BADVERSION	Protocol version numbers don't match (PVNO)	When an application receives a KRB_SAFE message, it verifies it. If any error occurs, an error code is reported for use by the application. 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.
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. 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. 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.
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 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.
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 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).
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. Multiple recent password changes have not propagated. Crypto subsystem error caused by running out of memory. SPN too long. SPN has too many parts.
0x3D	KRB_ERR_FIELD_TOOLONG	Field is too long for this implementation	Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) sent over the TCP stream is preceded by the length of the request as 4 octets in network byte order. The high bit of the length is reserved for future expansion and MUST currently be set to zero. If a KDC that does not understand how to interpret a set high bit of the length encoding receives a request with the high order bit of the length set, it MUST return a KRB-ERROR message with the error KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
0x3E	KDC_ERR_CLIENT_NOT_TRUSTED	The client trust failed or is not implemented	This typically happens when user’s smart-card certificate is revoked or the root Certification Authority that issued the smart card certificate (in a chain) is not trusted by the domain controller.
0x3F	KDC_ERR_KDC_NOT_TRUSTED	The KDC server trust failed or could not be verified	The trustedCertifiers field contains a list of certification authorities trusted by the client, in the case that the client does not possess the KDC's public key certificate. If the KDC has no certificate signed by any of the trustedCertifiers, then it returns an error of type KDC_ERR_KDC_NOT_TRUSTED. See RFC1510 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.
0x42	KRB_AP_ERR_USER_TO_USER_REQUIRED	User-to-user authorization is required	In the case that the client application doesn't know that a service requires user-to-user authentication, and requests and receives a conventional KRB_AP_REP, the client will send the KRB_AP_REP request, and the server will respond with a KRB_ERROR token as described in RFC1964, with a msg-type of KRB_AP_ERR_USER_TO_USER_REQUIRED.
0x43	KRB_AP_ERR_NO_TGT	No TGT was presented or available	In user-to-user authentication if the service does not possess a ticket granting ticket, it should return the error KRB_AP_ERR_NO_TGT.
0x44	KDC_ERR_WRONG_REALM	Incorrect domain or principal	Although this error rarely occurs, it occurs when a client presents a cross-realm TGT to a realm other than the one specified in the TGT. Typically, this results from incorrectly configured DNS.

Table 3. TGT/TGS issue error codes.

Ticket Encryption Type [Type = HexInt32]: the cryptographic suite that was used for issued TGT.

## Table 4. Kerberos encryption types

Type	Type Name	Description
0x1	DES-CBC-CRC	Disabled by default starting from Windows 7 and Windows Server 2008 R2.
0x3	DES-CBC-MD5	Disabled by default starting from Windows 7 and Windows Server 2008 R2.
0x11	AES128-CTS-HMAC-SHA1-96	Supported starting from Windows Server 2008 and Windows Vista.
0x12	AES256-CTS-HMAC-SHA1-96	Supported starting from Windows Server 2008 and Windows Vista.
0x17	RC4-HMAC	Default suite for operating systems before Windows Server 2008 and Windows Vista.
0x18	RC4-HMAC-EXP	Default suite for operating systems before Windows Server 2008 and Windows Vista.
0xFFFFFFFF or 0xffffffff	-	This type shows in Audit Failure events.

Pre-Authentication Type [Type = UnicodeString]: the code number of pre-Authentication type which was used in TGT request.

## Table 5. Kerberos Pre-Authentication types.

Type	Type Name	Description
0	-	Logon without Pre-Authentication.
2	PA-ENC-TIMESTAMP	This is a normal type for standard password authentication.
11	PA-ETYPE-INFO	The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-ERROR indicating a requirement for additional pre-authentication. It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. Never saw this Pre-Authentication Type in Microsoft Active Directory environment.
15	PA-PK-AS-REP_OLD	Used for Smart Card logon authentication.
17	PA-PK-AS-REP	This type should also be used for Smart Card authentication, but in certain Active Directory environments, it is never seen.
19	PA-ETYPE-INFO2	The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-ERROR indicating a requirement for additional pre-authentication. It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. Never saw this Pre-Authentication Type in Microsoft Active Directory environment.
20	PA-SVR-REFERRAL-INFO	Used in KDC Referrals tickets.
138	PA-ENCRYPTED-CHALLENGE	Logon using Kerberos Armoring (FAST). Supported starting from Windows Server 2012 domain controllers and Windows 8 clients.
-	This type shows in Audit Failure events.

Certificate Information:

Certificate Issuer Name [Type = UnicodeString]: the name of the Certification Authority that issued the smart card certificate. Populated in Issued by field in certificate.
Certificate Serial Number [Type = UnicodeString]: smart card certificate’s serial number. Can be found in Serial number field in the certificate.
Certificate Thumbprint [Type = UnicodeString]: smart card certificate’s thumbprint. Can be found in Thumbprint field in the certificate.

Security Monitoring Recommendations

For 4768(S, F): A Kerberos authentication ticket (TGT) was requested.

Type of monitoring required	Recommendation
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 “User ID” 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 “User ID” (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 “User ID” that corresponds to the accounts that should never be used.
Account whitelist: You might have a specific whitelist of accounts that are the only ones allowed to perform actions corresponding to particular events.	If this event corresponds to a “whitelist-only” action, review the “User ID” for accounts that are outside the whitelist.
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 events where the Client Address is not from your internal IP range or not from private IP 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 events. If Client Address is not from the whitelist, 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 4768 events with Client Port field value > 0 and < 1024 should be examined, because a well-known port was used for outbound connection.
Also consider monitoring the fields shown in the following table, to discover the issues listed:

Field	Issue to discover
Certificate Issuer Name	Certification authority name is not from your PKI infrastructure.
Certificate Issuer Name	Certification authority name is not authorized to issue smart card authentication certificates.
Pre-Authentication Type	Value 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,” which is a security risk. For more information, see Table 5. Kerberos Pre-Authentication types.
Pre-Authentication Type	Value is not 15 when account must use a smart card for authentication. For more information, see Table 5. Kerberos Pre-Authentication types.
Pre-Authentication Type	Value is not 2 when only standard password authentication is in use in the organization. For more information, see Table 5. Kerberos Pre-Authentication types.
Pre-Authentication Type	Value is not 138 when Kerberos Armoring is enabled for all Kerberos communications in the organization. For more information, see Table 5. Kerberos Pre-Authentication types.
Ticket Encryption Type	Value is 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. For more information, see Table 4. Kerberos encryption types.
Ticket Encryption Type	Starting with Windows Vista and Windows Server 2008, monitor for values other than 0x11 and 0x12. These are the expected values, starting with these operating systems, and represent AES-family algorithms. For more information, see Table 4. Kerberos encryption types.
Result Code	0x6 (The username doesn't exist), if you see, for example N events in last N minutes. This can be an indicator of account enumeration attack, especially for highly critical accounts.
Result Code	0x7 (Server not found in Kerberos database). This error can occur if the domain controller cannot find the server's name in Active Directory.
Result Code	0x8 (Multiple principal entries in KDC database). This will help you to find duplicate SPNs faster.
Result Code	0x9 (The client or server has a null key (master key)). This error can help you to identify problems with Kerberos authentication faster.
Result Code	0xA (Ticket (TGT) not eligible for postdating). Microsoft systems should not request postdated tickets. These events could help identify anomaly activity.
Result Code	0xC (Requested start time is later than end time), if you see, for example N events in last N minutes. This can be an indicator of an account compromise attempt, especially for highly critical accounts.
Result Code	0xE (KDC has no support for encryption type). In general, this error occurs when the KDC or a client receives a packet that it cannot decrypt. Monitor for these events because this should not happen in a standard Active Directory environment.
Result Code	0xF (KDC has no support for checksum type). Monitor for these events because this should not happen in a standard Active Directory environment.
Result Code	0x12 (Client's credentials have been revoked), if you see, for example N events in last N minutes. This can be an indicator of anomaly activity or brute-force attack, especially for highly critical accounts.
Result Code	0x1F (Integrity check on decrypted field failed). The authenticator was encrypted with something other than the session key. The result is that the KDC cannot decrypt the TGT. The modification of the message could be the result of an attack or it could be because of network noise.
Result Code	0x22 (The request is a replay). This error indicates that a specific authenticator showed up twice—the KDC has detected that this session ticket duplicates one that it has already received. It could be a sign of attack attempt.
Result Code	0x29 (Message stream modified and checksum didn't match). The 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. Monitor for these events because this should not happen in a standard Active Directory environment.
Result Code	0x3C (Generic error). This error can help you more quickly identify problems with Kerberos authentication.
Result Code	0x3E (The client trust failed or is not implemented). This error helps you identify logon attempts with revoked certificates and the situations when the root Certification Authority that issued the smart card certificate (through a chain) is not trusted by a domain controller.
Result Code	0x3F, 0x40, 0x41 errors. These errors can help you more quickly identify smart-card related problems with Kerberos authentication.

This is a continuation post of part1 and part2 of my 'Integrated Windows Authentication blog series' and last one in this series where we are going to discuss about what we can do when Kerberos Authentication fails, how to detect it and correct it!

Let me start by mentioning this --> C:WindowsSystem32Wininet.dll file calls the InitializeSecurityContext function to build the Kerberos ticket.

The InitializeSecurityContext (Kerberos) function initiates the client side, outbound security context from a credential handle. The function is used to build a security context between the client application and a remote peer. InitializeSecurityContext (Kerberos) returns a token that the client must pass to the remote peer, which the peer in turn submits to the local security implementation through the AcceptSecurityContext (Kerberos) call. The token generated should be considered opaque by all callers.

Typically, the InitializeSecurityContext (Kerberos) function is called in a loop until a sufficient security context is established.

From <https://msdn.microsoft.com/en-us/library/aa375507(VS.85).aspx>

I have explained in my Part1 post about how the kerberos authentication works, I strongly recommend reading that first before troubleshooting so we know what we are doing.

So, when the Kerberos AUTHETICATION FAILS or maybe not yet, This is how you verify/check/resolve:

Firewall Configuration:

Open firewall ports to allow HTTP traffic in on default and non-default ports. Ensure clients can connect to Kerberos Ports on the Active Directory.

Before testing authentication, ensure clients can access the SharePoint Server web applications on the configured HTTP ports. In addition, ensure clients can authenticate with Active Directory and request Kerberos tickets from the KDC over the standard Kerberos ports.

Open firewall ports to allow HTTP traffic in on default and non-default ports:

Typically you have to configure the firewall on each front-end Web to allow incoming requests over ports TCP 80 and TCP 443. Open Windows Firewall with Advanced Security and browse to the following Inbound Rules:

World Wide Web Services (HTTP Traffic-In)
World Wide Web Services (HTTPS Traffic-In)

Make sure the appropriate ports are open in your environment. In our example, we access SharePoint Server over HTTP (port 80), so this rule was enabled.

In addition, we have to open the non-default port used in our example (TCP 5555). If you have web sites running on non-default ports, you also have to configure custom rules to allow HTTP traffic on those ports.

Ensure that clients can connect to Kerberos ports on the Active Directory role

To use Kerberos authentication, clients will have to request ticket granting tickets (TGT) and service tickets (ST) from the Key Distribution Center (KDC) over UDP or TCP port 88. By default, when you install the Active Directory Role in Windows Server 2008 and later, the role will configure the following incoming rules to allow this communication by default:

Kerberos Key Distribution Center – PCR (TCP-In)
Kerberos Key Distribution Center – PCR (UDP-In)
Kerberos Key Distribution Center (TCP-In)
Kerberos Key Distribution Center (UDP-In)

In your environment ensure these rules are enabled and that clients can connect to the KDC (domain controller) over port 88.

Ck-100 auto key programmer v37.01 sbb the latest generation 3. CK-100 is a portable transponder key programming device — for programming keys in immobilizer units. This tool connects via the 16-pin OBD-2 diagnostic port in a car (virtually every car has this port) — to carry out a wide range of functions programming new keys. This unit is EXACTLY the same to older generation Silca SBB. CK-100 Auto Key Programmer V99.99 is a new generation of the SBB Key Programmer, the replace version. Welcome to obd2tool.com! Login，New User？ Join Free Currencies. Home 2020 New Year deals New. CK-100 CK100 Auto Key Programmer V99.99 SBB the latest generation.

From <https://technet.microsoft.com/en-us/library/gg502602(v=office.14).aspx>

Test browser authentication:

After configuring Active Directory, DNS and SharePoint Server you can now test whether Kerberos authentication is configured correctly by browsing to your web applications. When testing in the browser, ensure the following conditions are met:

The test user is logged into a Windows 7 or higher computer joined to the domain that SharePoint Server is installed in, or is logged into a domain trusted by the SharePoint Server domain.
Integrated Windows authentication is enabled in the browser. Under Internet Options in the Advanced tab, make sure Enable Integrated Windows Authentication* is enabled in the Security section:

Local intranet is configured to automatically logon clients. Under Internet explorer option, in the Security tab, select Local Intranet and click the Custom level button. Scroll down and make sure that Automatic logon only in Intranet zone is selected.
Ensure that Automatically detect intranet network is selected in Internet options->Security->Intranet Zone->Sites.
If you are using fully qualified domain names to access the SharePoint Server web applications, ensure that the FQDNs are included in the intranet zone, either explicitly or by wildcard inclusion (for example, '*.vmlab.local').

The easiest way to determine if Kerberos authentication is being used is by logging into a test workstation and navigating to the web site in question. If the user isn't prompted for credentials and the site is rendered correctly, you can assume Integrated Windows authentication is working.

From <https://technet.microsoft.com/en-us/library/gg502602(v=office.14).aspx>

If any of the above is not set properly, then Delegation fails even when Kerberos authentication works:

Kerberos delegation is only allowed for the « Intranet » and « Trusted Sites » zones (in other words, IE sets the ISC_REQ_DELEGATE flag when it calls InitializeSecurityContext only if the zone computed is « Intranet » or « Trusted Sites » )
The account used for the application pool identity must have the « Trusted for delegation » flag set
If delegation still fails, you may consider using DELEGCONFIG. This tool allows to diagnose - and resolve - dozens of issues preventing Kerberos authentication from working correctly. Check the following link for more details: http://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx

The next step is to determine if the negotiate protocol was used to negotiate Kerberos authentication as the authentication provider for the request. This can be done in the following ways:

SharePoint server Front-end Windows security logs

If Kerberos authentication is working correctly you will see Logon events in the security event logs on the front-end webs with event ID = 4624. In the general information for these events you should see the security ID being logged onto the computer and the Logon Process used, which should be Kerberos.

Event is here below:

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 5/6/2018 10:27:48 PM

Event ID: 4624

Task Category: Logon

Level: Information

Keywords: Audit Success

User: N/A

Computer: SP.contoso.com

Description:

An account was successfully logged on.

Subject:

Security ID: NULL SID

Account Name: -

Account Domain: -

Logon ID: 0x0

Logon Type: 3

Impersonation Level: Impersonation

New Logon:

Security ID: contosospfarm

Account Name: spfarm

Account Domain: contoso

Logon ID: 0x15636

Logon GUID: {02398194-25d2-4852-4d60-026f36f6632a}

Process Information:

Process ID: 0x0

Process Name: -

Network Information:

Workstation Name:

Source Network Address: -

Source Port: -

Detailed Authentication Information:

Logon Process: Kerberos

Authentication Package: Kerberos

Transited Services: -

Package Name (NTLM only): -

Key Length: 0

Event Xml:

<Channel>Security</Channel>

<Computer>SP.contoso.com</Computer>

</System>

<Data Name='TargetUserName'>spfarm</Data>

<Data Name='TargetDomainName'>contoso</Data>

<Data Name='LogonProcessName'>Kerberos</Data>

<Data Name='AuthenticationPackageName'>Kerberos</Data>

</Data>

</EventData>

</Event>

We should see same event on KDC (Domain controller) too:

Check if the IIS server is actually configured to send the WWW-Authenticate: Negotiate header:

If IIS doesn't send this header, you'll need to use ADSUTIL to set the Negotiate header though the NTAuthenticationProviders metabase property (see http://support.microsoft.com/kb/215383)
Note: by default, the NTAuthenticationProviders property is not set which causes IIS to send both Negotiate and NTLM headers:

To check or set the property: Locate the directory that contains the Adsutil.vbs file. By default, this directory is C:InetpubAdminscripts.

Use the following command to retrieve the current values for the NTAuthenticationProviders metabase property:
cscript adsutil.vbs get w3svc/WebSite/root/NTAuthenticationProviders
In this command, WebSite is a placeholder for the Web site ID number. The Web site ID number of the default Web site is 1.

For Example:

PS C:UsersAdministrator.contoso> cscript 'C:inetpubAdminScriptsadsutil.vbs' get w3svc/1834077867/root/NTAuthenticat

ionProviders

Microsoft (R) Windows Script Host Version 5.8

NTAuthenticationProviders : (STRING) 'Negotiate,NTLM'

If the command above does not return the string 'Negotiate,NTLM,' use the following command to enable the Negotiate process:
cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders 'Negotiate,NTLM'

Example: cscript adsutil.vbs set w3svc/1834077867/root/NTAuthenticationProviders 'Negotiate,NTLM'

Warning: If you edit the metabase incorrectly, you can cause serious problems that may require that you reinstall any product that uses the metabase. Microsoft cannot guarantee that problems that result if you incorrectly edit the metabase can be solved. Edit the metabase at your own risk.

Note: Always back up the metabase before you edit it.

From <https://support.microsoft.com/en-us/help/215383/how-to-configure-iis-to-support-both-the-kerberos-protocol-and-the-ntl>

Check if the client and server are on the same machine:

Kerberos is not enabled in this configuration and a hard coded loopback check will always force usage of NTLM in this scenario. Note that NTLM may also not work in this configuration (see http://support.microsoft.com/kb/896861for more details).

Workarounds:

Set DisableStrictNameChecking to 1 And

Either

[Preferred method if NTLM is needed]Create 'Multi-String Value' BackConnectionHostNames = 'HostName of the site' at location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0

Create Dword 'DisableLoopbackCheck' = 1 at location HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa

Duplicate or Wrong Service principal name set for Application Pool identity:

If a wrong SPN is set for the APP Pool identity or if there are Duplicate SPNs set, kerberos AUTHENTICATION fails because it cannot determine which account to use to Decrypt the Ticket.

We can use these SETSPN.EXE commands to check any SPN related issues:

SETSPN -L [Application Pool account] --> Will list all SPNs registered for that account.

SETSPN -X --> Will show any Duplicate SPNs

SETSPN -Q --> Can be used to Query for Specific or all SPNs.

SETSPN.EXE Usage: C:Windowssystem32setspn.exe [modifiers switch] [accountname]

Where 'accountname' can be the name or domainname

of the target computer or user account

Edit Mode Switches:

-R = reset HOST ServicePrincipalName

Usage: setspn -R accountname

-S = add arbitrary SPN after verifying no duplicates exist

Usage: setspn -S SPN accountname

-D = delete arbitrary SPN

Usage: setspn -D SPN accountname

-L = list SPNs registered to target account

Usage: setspn [-L] accountname

Query Mode Switches:

-Q = query for existence of SPN

Usage: setspn -Q SPN

-X = search for duplicate SPNs

Usage: setspn -X

Some Example commands with outputs are as below:

PS C:UsersAdministrator.contoso> SetSPN -S HTTP/Kerberos.contoso.com:9090 ContosoSPAppPool

Checking domain DC=contoso,DC=com

____ Generates And Issues Session Keys In Kerberos

Registering ServicePrincipalNames for CN=SPAppPool,CN=Users,DC=contoso,DC=com

HTTP/Kerberos.contoso.com:9090

Updated object

PS C:UsersAdministrator.contoso> setspn -l contosoSPAppPool

Registered ServicePrincipalNames for CN=SPAppPool,CN=Users,DC=contoso,DC=com:

HTTP/Kerberos.contoso.com:9090

HTTP/Kerberos:9090

HTTP/Kerberos.contoso.com

HTTP/Kerberos

PS C:UsersAdministrator.contoso> SetSPN -S HTTP/Kerberos ContosoSPAppPool

Checking domain DC=contoso,DC=com

CN=SPAppPool,CN=Users,DC=contoso,DC=com

HTTP/Kerberos.contoso.com:9090

HTTP/Kerberos:9090

HTTP/Kerberos.contoso.com

HTTP/Kerberos

Duplicate SPN found, aborting operation!

PS C:UsersAdministrator.contoso> setspn -Q http/sp

Checking domain DC=contoso,DC=com

No such SPN found.

PS C:UsersAdministrator.contoso> setspn -Q */SQL

Checking domain DC=contoso,DC=com

CN=SQL,CN=Computers,DC=contoso,DC=com

MSSQLSvc/SQL.contoso.com:1433

MSSQLSvc/SQL.contoso.com

TERMSRV/SQL

TERMSRV/SQL.contoso.com

WSMAN/SQL

WSMAN/SQL.contoso.com

RestrictedKrbHost/SQL

HOST/SQL

RestrictedKrbHost/SQL.contoso.com

HOST/SQL.contoso.com

Existing SPN found!

PS C:UsersAdministrator.contoso> setspn -Q */sp

Checking domain DC=contoso,DC=com

CN=SP,CN=Computers,DC=contoso,DC=com

TERMSRV/SP

TERMSRV/SP.contoso.com

WSMAN/SP

WSMAN/SP.contoso.com

RestrictedKrbHost/SP

HOST/SP

RestrictedKrbHost/SP.contoso.com

HOST/SP.contoso.com

Existing SPN found!

PS C:UsersAdministrator.contoso> setspn -X

Checking domain DC=contoso,DC=com

Processing entry 0

found 0 group of duplicate SPNs.

So, for same Service there should not be 2 different Service accounts for which SPNs are registered otherwise IIS will not know which account to decrypt from.

Tools:

Klist
Kerberos Authentication tester
Fiddler
Microsoft network monitor

Klist.EXE:

this command-line tool helps you list and purge tickets on your client machine. You can list tickets to verify the validity of tickets. You can also check for other details, such as the permissible flags, SPN type, the client, and server details.

KLIST output (in this example, for a Site URL: http://kerberos:9090):

PS C:UsersAdministrator.contoso> klist

Current LogonId is 0:0x16958c

Cached Tickets: (2)

#0> Client: Administrator @ CONTOSO.COM

Server: krbtgt/CONTOSO.COM @ CONTOSO.COM

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize

Start Time: 5/6/2018 21:43:29 (local)

End Time: 5/7/2018 7:43:29 (local)

Renew Time: 5/13/2018 21:43:29 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

Cache Flags: 0x1 -> PRIMARY

Kdc Called: DC.contoso.com

#1> Client: Administrator @ CONTOSO.COM

Server: HTTP/kerberos @ CONTOSO.COM

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize

Start Time: 5/6/2018 21:43:29 (local)

End Time: 5/7/2018 7:43:29 (local)

Renew Time: 5/13/2018 21:43:29 (local)

Session Key Type: RSADSI RC4-HMAC(NT)

Cache Flags: 0

Kdc Called: DC.contoso.com

So, if server does not have same Decryption mechanism (Say RC4) so it can't decrypt tickets. In that case, make sure you enable AES encryption for Service account properties.

Run these two commands below if you want to Purge user and System level Kerberos Tickets.

PS C:UsersAdministrator.contoso> klist purge

Current LogonId is 0:0x16958c

Deleting all tickets:

Ticket(s) purged!

PS C:UsersAdministrator.contoso> klist -li 0x3e7 purge

Current LogonId is 0:0x16958c

Targeted LogonId is 0:0x3e7

Deleting all tickets:

Ticket(s) purged!

Kerberos Authentication Tester (It can be found here: http://blog.michelbarneveld.nl/michel/archive/2009/12/05/kerberos-authentication-tester.aspx)

Kerberos Authentication Tester Features:

It shows what authentication method is used in a web request: None, Basic, NTLM or Kerberos
It shows the SPN used in case of Kerberos
It shows the HTTP status
It shows the HTTP Headers of the request.
It shows the version of NTLM used (v1 or v2)
It has a detailed view with a complete breakdown of the Authorization header. (Yep, went through all the RFCs to dissect the Kerberos and NTLM packages)
It shows your current Kerberos tickets and allows you to remove them (like klist.exe)

The blue details link at the top right shows a new screen with the details of the request, including a breakdown of the Authorization HTTP Header. You can also save this XML.

It shows all kerb Tickets.

Network Monitor/WireShark: network trace capture and review tools. You can review trace to identify Kerberos errors.

Best way to get the network capture is:

1. To reduce the possibility of caching data, do one of the following:

•Close/Reopen client application

•Logoff/Logon client workstation

•Reboot client workstation

2. Start the network capture

3. Clear DNS cache using:

ipconfig /flushdns

4. Clear NetBIOS cache using:

nbtstat –RR

5. Clear user Kerberos tickets using:

klist purge

6. Clear system / computer Kerberos tickets using (Vista or higher only):

Klist –li 0x3e7 purge

7. Reproduce the authentication failure with the application in question

8. Stop the network capture

Now that you have the capture, you can filter the traffic using the string 'Kerberosv5' if you are using Network Monitor. If you are using Wireshark, you can filter using the string 'Kerberos'.

To be more thorough, load the Authentication Traffic filter that shows packets containing Kerberos tickets as well. You can do this by clicking the Load Filter button, choose Standard Filters, and then click Authentication Traffic.

OR add this Filter:

KerberosV5

OR KerberosV5.KrbError.Sname

OR KerberosV5.AsReq

OR KerberosV5.AsRep

OR KerberosV5.TgsReq

OR KerberosV5.TgsRep

Vista ultimate key generator free download - Windows Vista Ultimate, CD Key Generator, Serial Key Generator, and many more programs. Windows vista ultimate key generator free download. Daily2soft.com-Windows Vista Product Key, Generator Full And Free Download Here Daily2kblog is the best and lightest operating system introduced by Microsoft for use on personal computers, including home and business desktops, laptops, tablets PCs, and media center PCs. Windows Vista was introduced after Windows XP, and before the update of. Jan 27, 2020 Windows Vista Product Key Generator Plus Ultimate Keygen. Windows Vista is the retailer version of the Windows working to combine the PowerISO. Now, Windows Vista comes with many new features. It has a special graphical user interface that helps you to access the apps and tools easily without any hassle. Windows vista ultimate key generator free download - Windows Vista Ultimate, Windows Vista Ultimate Wallpaper Series Pack, Windows Product Key Viewer and Changer, and many more programs.

Click 'Apply' to begin filtering…

In my Network trace examples below:

I am using SQL as my Client machine

Kerberos Flow

192.168.2.50 is DC (KDC)

SP is SharePoint server

Analysing Network trace……………………….

First, we see AS (Authentication Server) request and response.

DC given AS response Ticket (TGT) to client.

(Service name) Sname requested and sent is krbtgt:

Sname: krbtgt/CONTOSO.COM

Then Client uses AS response Ticket to make TGS request (Service ticket) to KDC.

TGS Response ticket (Service Ticket) is sent to client by KDC.

(Service name) Sname requested and sent is HTTP:

Sname: HTTP/WebApp name

FIDDLER:

1st request will be anonymous if user is not authenticated.

401 is what we see first …………….

Kerberos Authentication

Then we see 302 client Presenting kerberos Ticket to Server (SP) where server responds with a Kerberos Reply after decrypting the ticket with App Pool Identity.

If the Ticket presented by Client is valid then server moves request (302) to the page Client should be going to.

It could be home page of the Site, as in this example is:

Location: http://teams/_layouts/15/start.aspx#/SitePages/Home.aspx

In Next step, Client uses it's Original Kerberos ticket to obtain data.

SO, we see 200 ……………. And we get the page.

Then further, client uses same ticket to access the Site resources (pages, links, files etc.).

------------------------------------------------------------------------------------------------------------------------------------

And that's all you might need for almost all of your Kerberos related issues - Of Course, wrt SharePoint 🙂

Happy SharePointing !!

Check other Part links in this series too:

Part2: Step by step Guide for Configuring Kerberos Authentication in SharePoint 2013/2016

Additional References:

Kerberos RFC: