Windows event id 4768

4768: A Kerberos authentication ticket (TGT) was requested

On this page

• Description of this event
• Field level details
• Examples

Result codes:

Free Security Log Resources by Randy

• Free Security Log Quick Reference Chart
• Windows Event Collection: Supercharger Free Edtion
• Free Active Directory Change Auditing Solution
• Free Course: Security Log Secrets

Description Fields in
4768

Account Information: 

• Account Name:  logon name of the account that just authenticated
• Supplied Realm Name: domain name of the account
• User ID:   SID of the account
• MSDS-SupportedEncryptionTypes:
• Available Keys:

Service Information:

• Service Name:  always «krbtgt»
• Service ID:
• MSDS-SupportedEncryptionTypes:
• Available Keys:

Domain Controller Information:

• MSDS-SupportedEncryptionTypes:
• Available Keys:

Network Information:

• Client Address:  IP address where user is present
• Client Port:  source port 
• Advertized Etypes:

Additional Information:

• Ticket Options:  unknown.  Please start a discussion if you have information to share on this field.
• Result Code:  error if any — see above table
• Ticket Encryption Type: unknown.  Please start a discussion if you have information to share on this field.
• Session Encryption Type:
• Pre-Authentication Type: unknown.  Please start a discussion if you have information to share on this field. 
• Pre-Authentication EncryptionType:

Certificate Information:

This information is only filled in if logging on with a smart card. 

• Certificate Issuer Name:
• Certificate Serial Number:
• Certificate Thumbprint:

Ticket Information:

• Response ticket hash: Unique identifier of the ticket issuedy by the domain controller which can be either a ticket granting ticket (event id 4768) or a ticket granting service (event id 4769 and 4770)

Supercharger Enterprise

Картинка с сайта: www.ultimatewindowssecurity.com

Load Balancing for Windows Event Collection

Время на прочтение4 мин

Количество просмотров309K

Картинка с сайта: habr.com

Рэнди Франклин Смит (CISA, SSCP, Security MVP) имеет в своем арсенале очень полезный документ, рассказывающий о том, какие события (event IDs) обязательно должны отслеживаться в рамках обеспечения информационной безопасности Windows. В этом документе изложена крайне полезная информация, которая позволит Вам “выжать” максимум из штатной системы аудита. Мы подготовили перевод этого материала. Заинтересованных приглашаем под кат.

О том, как настроить аудит, мы уже обстоятельно писали в одном из наших постов. Но из всех event id, которые встречаются в журналах событий, необходимо остановить свое внимание на нескольких критических важных. На каких именно – решать каждому. Однако Рэнди Франклин Смит предлагает сосредоточить внимание на 10 важных событиях безопасности в Windows.

Контроллеры доменов

Event ID — (Категория) — Описание

1) 675 или 4771
(Аудит событий входа в систему)
Событие 675/4771 на контроллере домена указывает на неудачную попытку войти через Kerberos на рабочей станции с доменной учетной записью. Обычно причиной этого является несоответствующий пароль, но код ошибки указывает, почему именно аутентификация была неудачной. Таблица кодов ошибок Kerberos приведена ниже.

2) 676, или Failed 672 или 4768
(Аудит событий входа в систему)
Событие 676/4768 логгируется для других типов неудачной аутентификации. Таблица кодов Kerberos приведена ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 672 вместо 676.

3) 681 или Failed 680 или 4776
(Аудит событий входа в систему)
Событие 681/4776 на контроллере домена указывает на неудачную попытку входа в систему через
NTLM с доменной учетной записью. Код ошибки указывает, почему именно аутентификация была неудачной.
Коды ошибок NTLM приведены ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 680 вместо 681.

4) 642 или 4738
(Аудит управления учетными записями)
Событие 642/4738 указывает на изменения в указанной учетной записи, такие как сброс пароля или активация деактивированной до этого учетной записи. Описание события уточняется в соответствие с типом изменения.

5) 632 или 4728; 636 или 4732; 660 или 4756
(Аудит управления учетными записями)
Все три события указывают на то, что указанный пользователь был добавлен в определенную группу. Обозначены Глобальная (Global), Локальная (Local) и Общая (Universal) соответственно для каждого ID.

6) 624 или 4720
(Аудит управления учетными записями)
Была создана новая учетная запись пользователя

7) 644 или 4740
(Аудит управления учетными записями)
Учетная запись указанного пользователя была заблокирована после нескольких попыток входа

517 или 1102
(Аудит системных событий)
Указанный пользователь очистил журнал безопасности

Вход и выход из системы (Logon/Logoff)

Event Id — Описание

528 или 4624 — Успешный вход в систему
529 или 4625 — Отказ входа в систему – Неизвестное имя пользователя или неверный пароль
530 или 4625 Отказ входа в систему – Вход в систему не был осуществлен в течение обозначенного периода времени
531 или 4625 — Отказ входа в систему – Учетная запись временно деактивирована
532 или 4625 — Отказ входа в систему – Срок использования указанной учетной записи истек
533 или 4625 — Отказ входа в систему – Пользователю не разрешается осуществлять вход в систему на данном компьютере
534 или 4625 или 5461 — Отказ входа в систему – Пользователь не был разрешен запрашиваемый тип входа на данном компьютере
535 или 4625 — Отказ входа в систему – Срок действия пароля указанной учетной записи истек
539 или 4625 — Отказ входа в систему – Учетная запись заблокирована
540 или 4624 — Успешный сетевой вход в систему (Только Windows 2000, XP, 2003)

Типы входов в систему (Logon Types)

Тип входа в систему — Описание

2 — Интерактивный (вход с клавиатуры или экрана системы)
3 — Сетевой (например, подключение к общей папке на этом компьютере из любого места в сети или IIS вход — Никогда не заходил 528 на Windows Server 2000 и выше. См. событие 540)
4 — Пакет (batch) (например, запланированная задача)
5 — Служба (Запуск службы)
7 — Разблокировка (например, необслуживаемая рабочая станция с защищенным паролем скринсейвером)
8 — NetworkCleartext (Вход с полномочиями (credentials), отправленными в виде простого текст. Часто обозначает вход в IIS с “базовой аутентификацией”)
9 — NewCredentials
10 — RemoteInteractive (Терминальные службы, Удаленный рабочий стол или удаленный помощник)
11 — CachedInteractive (вход с кешированными доменными полномочиями, например, вход на рабочую станцию, которая находится не в сети)

Коды отказов Kerberos

Код ошибки — Причина

6 — Имя пользователя не существует
12 — Ограничение рабочей машины; ограничение времени входа в систему
18 — Учетная запись деактивирована, заблокирована или истек срок ее действия
23 — Истек срок действия пароля пользователя
24 — Предварительная аутентификация не удалась; обычно причиной является неверный пароль
32 — Истек срок действия заявки. Это нормальное событие, которое логгируется учетными записями компьютеров
37 — Время на рабочей машины давно не синхронизировалось со временем на контроллере домена

Коды ошибок NTLM

Код ошибки (десятичная система) — Код ошибки (16-ричная система) — Описание

3221225572 — C0000064 — Такого имени пользователя не существует
3221225578 — C000006A — Верное имя пользователя, но неверный пароль
3221226036 — C0000234 — Учетная запись пользователя заблокирована
3221225586 — C0000072 — Учетная запись деактивирована
3221225583 — C000006F — Пользователь пытается войти в систему вне обозначенного периода времени (рабочего времени)
3221225584 — C0000070 — Ограничение рабочей станции
3221225875 — C0000193 — Истек срок действия учетной записи
3221225585 — C0000071 — Истек срок действия пароля
3221226020 — C0000224 — Пользователь должен поменять пароль при следующем входе в систему

Еще раз продублируем ссылку на скачивание документа на сайте Рэнди Франклина Смита www.ultimatewindowssecurity.com/securitylog/quickref/Default.aspx. Нужно будет заполнить небольшую форму, чтобы получить к нему доступ.

P.S. Хотите полностью автоматизировать работу с журналами событий? Попробуйте новую версию NetWrix Event Log Manager 4.0, которая осуществляет сбор и архивирование журналов событий, строит отчеты и генерирует оповещения в режиме реального времени. Программа собирает данные с многочисленных компьютеров сети, предупреждает Вас о критических событиях и централизованно хранит данные обо всех событиях в сжатом формате для удобства анализа архивных данных журналов. Доступна бесплатная версия программы для 10 контроллеров доменов и 100 компьютеров.

Last Updated on December 24, 2024 by Deepanshu Sharma

Картинка с сайта: www.lepide.com

Have you ever pondered over the intricacies of digital security in a world where data breaches lurk around every digital corner? Picture this: you’re safeguarding your organization’s network, but are you certain that every user accessing it is who they claim to be? Enter Kerberos, the guardian angel of network authentication. But here’s the catch: how do you ensure Kerberos itself isn’t compromised? The answer lies within Event ID 4768, the gateway to deciphering Kerberos authentication tickets.

Event ID 4768 Components

Картинка с сайта: www.lepide.com

Account Information

Account Name: Specifies the name of the account for which a Ticket Granting Ticket (TGT) was requested. Notably, computer account names end with a $ symbol.

Supplied Realm Name: Identifies the Kerberos Realm to which the Account Name belongs.

User ID: Represents the Security Identifier (SID) of the account that requested a TGT. If the SID cannot be resolved, the source data appears in the event.

Service Information

Service Name: Indicates the name of the service in the Kerberos Realm to which the TGT request was sent.

Service ID: Denotes the SID of the service account in the Kerberos Realm to which the TGT request was sent.

Network Information

Client Address: Specifies the IP address of the computer from which the TGT request was received.

Client Port: Indicates the source port number of the client network connection. It’s typically “0” for local (localhost) requests.

Additional Information

Ticket Options: Represents a set of different ticket flags in hexadecimal format, including values like Forwardable, Renewable, Canonicalize, and Renewable-ok.

Result Code: Displays a set of different failure codes in hexadecimal format, providing insights into the outcome of the authentication attempt. Possible causes are varied, including issues like expired passwords, invalid credentials, or unsupported encryption types.

Ticket Encryption Type: Specifies the cryptographic suite used for issuing the TGT, such as DES, AES, or RC4.

Pre-Authentication Type: Indicates the code number of the pre-authentication type used for the TGT request, offering details about the authentication method employed.

Certificate Issuer Name: Identifies the name of the Certificate Authority (CA) that issued the smart card certificate.

Certificate Serial Number: Represents the serial number of the smart card certificate used during logon.

Certificate Thumbprint: Denotes the thumbprint of the smart card certificate, providing a unique identifier for authentication purposes.

Understanding Event ID 4768

Картинка с сайта: www.lepide.com

A. Ticket Granting Ticket (TGT)

At the core of Kerberos authentication lies the Ticket Granting Ticket (TGT), a digital key granting access to the network’s inner sanctum. Far beyond a mere credential, the TGT acts as the cornerstone of secure traversal across the digital landscape. It encapsulates the user’s authenticated identity, enabling seamless interaction with network resources while maintaining robust security protocols.

B. The Ritual of TGT Procurement

Event ID 4768 serves as the herald, signaling the commencement of the TGT procurement process. When a user seeks access to network resources, they embark on a journey orchestrated by the Key Distribution Center (KDC). This journey entails a series of cryptographic exchanges, culminating in the issuance of the coveted TGT. Event ID 4768 captures the essence of this ritual, offering insights into the intricate mechanisms governing user authentication within the Kerberos framework.

C. Unveiling the Veil of Secrecy

Despite its significance, Event ID 4768 operates within the confines of certain limitations. Notably, the event fails to disclose critical details, such as the identity of the user requesting the TGT. This omission poses challenges for security administrators, who must navigate the digital landscape armed with incomplete information. However, despite its limitations, Event ID 4768 remains a valuable tool in the arsenal of security professionals, offering glimpses into the inner workings of Kerberos authentication and guiding organizations towards enhanced network security practices.

In essence, understanding Event ID 4768 transcends mere technical proficiency; it necessitates a comprehensive grasp of the symbiotic relationship between Kerberos authentication and network security. By navigating the intricate nuances of this event, organizations can bolster their defenses against potential threats and navigate the digital landscape with confidence and resilience.

Event ID 4768 is an important security event logged by Windows operating systems when a Kerberos authentication ticket (TGT – Ticket Granting Ticket) is requested. This event is a normal part of the Kerberos authentication process which is integral to authenticating and authorizing users and services in a network. Understanding how to fix issues related to this event is crucial for maintaining a secure and efficient network. In this article, we will delve deep into the implications of Event ID 4768, what it indicates, and how to address any associated problems effectively.

Understanding Event ID 4768

The Kerberos authentication protocol is essential for secure identity verification in Windows environments, especially within Active Directory (AD) networks. When a user logs into a Windows domain, their credentials are verified against AD, which issues a Kerberos ticket if authentication is successful.

Event ID 4768 specifically indicates that a Kerberos TGT was requested. This request can be triggered by various actions:

• Users logging into their accounts.
• Service accounts starting, which may request their tickets.
• Applications that require tickets to access resources on the network.

The Event ID 4768 will generally look something like this in the Windows Security Event Log:

A Kerberos authentication ticket (TGT) was requested.

Subject:
    Security ID:      [Security ID of the requester]
    Account Name:     [Account Name of the requester]
    Account Domain:   [Domain or Source of the account]
    Logon ID:         [Unique Logon ID]

Service Information:
    Service ID:       [Service ID]
    Service Name:     [Service's SID]

Ticket Information:
    Ticket Options:    [...]   
    Ticket Encrypt Type: [...]  
    Ticket Lifetime:   [...]

Client Address:          [IP address]
Client Port:             [Port number]

The Significance of this Event

While Event ID 4768 itself does not indicate a problem, it can serve as a marker for issues related to authentication failures, improperly configured services, and even potential security breaches. Recognizing the patterns associated with this ID can help network administrators maintain the integrity of their services and address any security risks proactively.

Common Issues Associated with Event ID 4768

Despite being a part of a normal authentication process, several issues may arise in conjunction with Event ID 4768, particularly under the following circumstances:

1. Multiple Failed Logon Attempts

If you notice numerous 4768 events in quick succession, it could indicate users or services are repeatedly failing to authenticate. This could alert you to:

• Password issues (e.g., expired passwords).
• Accounts that are locked out or disabled.
• Misconfigured application identities, such as incorrect service principals.

2. Unusual Ticket Requests

Requests for Kerberos tickets from unusual or unexpected accounts may signal unauthorized access attempts, particularly if you observe requests from unknown IP addresses or applications.

3. Time Synchronization Issues

Kerberos relies heavily on time synchronization between the client and server. If there are discrepancies, it can lead to authentication failures that, while not directly logged as Event ID 4768, are reflected in event log failures that can stem from improper time settings.

4. Service Account Misconfiguration

Service accounts may request tickets as they authenticate to other services. If these accounts are misconfigured, you may see an abnormal number of requests alongside frequent failures.

Troubleshooting Steps

To effectively manage issues related to Event ID 4768, the following troubleshooting steps can be undertaken:

Step 1: Review the Event Logs

Begin by closely examining the Windows Event Viewer logs. Look at the Security logs, focusing on the timestamp and details surrounding Event ID 4768. Evaluate the Logon ID and the source accounts involved.

Step 2: Look for Related Events

Often, Event ID 4768 will be accompanied by other events such as:

• Event ID 4771 – Kerberos pre-authentication failed.
• Event ID 4740 – A user account was locked out.

Identifying patterns and correlating these events can offer insights into potential issues.

Step 3: Analyze Authentication Failures

Should any authentication failures be recorded, check the accounts involved to determine if they are locked out or if their passwords have expired. If issues are identified, follow the necessary protocols to reset passwords or unlock accounts.

Step 4: Check for Time Synchronization Issues

Ensure that all devices within the domain are synchronized with a reliable time service. Kerberos operates using timestamps, making accurate timekeeping vital. You can do this by verifying the time settings both on the client and the domain controllers. Use the following command to check the time settings:

w32tm /query /status

Step 5: Validate Service Account Credentials

If service accounts are involved, verify that:

• They have the correct permissions.
• Their passwords are not expired.
• They are configured properly within services.

Step 6: Implement Monitoring

Implement continuous monitoring solutions that can alert administrators to multiple ticket requests or failed authentications automatically. Such monitoring aids in the rapid identification of unusual patterns.

Step 7: Review Security Policies

Examine the Active Directory security policies to ensure they align with best practices for authentication. Incorporating policies around password expiry, account lockout thresholds, and Kerberos ticket lifetimes can enhance your AD’s resilience.

Common Resolutions to Problems

Once you’ve identified the issues contributing to the Event ID 4768 occurrences, addressing them may include the following remedies:

1. Resetting Passwords

For locked-out or expired accounts, reset the user passwords and verify their access to resources subsequently.

2. Configuring Time Synchronization

Use NTP (Network Time Protocol) to ensure all devices are time-synchronized:

• Configure the primary domain controller to an external NTP server.
• Update additional domain controllers and member servers to use the primary domain controller as their time source.

3. Updating Service Account Settings

Review any associated service accounts and ensure they are properly set up with valid credentials.

4. Adjusting Security Settings

Consider revising Active Directory security policies to better manage how authentication and access are governed. This may involve:

• Implementing stricter account lockout policies.
• Adjusting password policies to require complexity and regular updates.

5. Enabling Auditing Features

Increase the level of security auditing for user logon events. This can help trace back the source of the problem should similar issues arise in the future.

Conclusion

Understanding and troubleshooting Event ID 4768 is critical for maintaining a secure Windows environment. While the event itself may not indicate a fault, it serves as a reminder to review and verify an organization’s security posture regularly. The knowledge gained from analyzing authentication ticket requests can play a pivotal role in building a solid defense against unauthorized access and maintaining the integrity of network operations.

Taking proactive measures, monitoring account activities, validating configurations, and ensuring time synchronization are essential steps that contribute towards the efficient management of Kerberos authentication in Windows domains. Implementing these practices not only helps in rectifying issues related to Event ID 4768 but also strengthens the network’s overall security landscape.