Event ID 4768 fires on Active Directory domain controllers every time a principal requests a Kerberos Ticket Granting Ticket (TGT). This is the first step in Kerberos authentication: the client sends an AS-REQ to the KDC, and the DC logs 4768 with the result. Per Microsoft's security auditing documentation, the event captures both successful and failed attempts, making it central to authentication monitoring, brute-force detection, and credential attack forensics.
Key takeaways
- Event 4768 logs every Kerberos TGT request (AS-REQ) on domain controllers, both successes and failures.
- Result Code 0x0 means success. Common failure codes: 0x6 (bad username), 0x12 (disabled), 0x17 (expired), 0x18 (locked out).
- The event captures account name, client IP, encryption type, and pre-authentication type.
- High-volume: busy DCs can generate thousands of 4768 events per hour during peak.
- Key attack signal: AS-REP Roasting targets accounts without pre-authentication, visible through 4768 patterns.
Quick explanation
In simple terms
Event ID 4768 is the Windows Security log entry generated when someone or something requests a Kerberos authentication ticket (TGT) from a domain controller. It records every login attempt to the AD domain.
Technical definition
Event 4768 is a success/failure audit event from the Microsoft-Windows-Security-Auditing provider. It logs Kerberos Authentication Service (AS) exchanges: the client sends an AS-REQ to the KDC on TCP/UDP port 88, and the DC logs the request with account info, client IP, requested encryption type, pre-authentication type, and a result code (KRB_ERROR or success).
Analogy
Think of Event 4768 like the entry log at a building's front desk. Every person who shows up and asks for an access badge gets logged, whether they get the badge (success, 0x0) or are turned away (failure codes). The log records who asked, where they came from, and why they were denied.
Definition
Event ID 4768 is the Windows Security log entry generated when a Kerberos Ticket Granting Ticket (TGT) is requested from a domain controller's KDC. It logs every authentication attempt to the AD domain, including the result code, client IP, and encryption type.
Event ID 4768 is generated by the Microsoft-Windows-Security-Auditing provider on Active Directory domain controllers. It records every Kerberos Authentication Service (AS) exchange, which is the process of requesting a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC).
The event fires during the AS-REQ/AS-REP phase of Kerberos: the client sends an Authentication Service Request (AS-REQ) to port 88 on the DC, proving its identity through pre-authentication (typically by encrypting a timestamp with the user's password hash). The DC validates the request and either issues a TGT (success, result code 0x0) or returns an error (failure, with a specific KRB_ERROR code).
The event data includes: Account Information (name, SID of the requesting principal), Service Information (the krbtgt service name), Network Information (client IP and port), Additional Information (ticket encryption type, pre-authentication type, ticket options flags), and the Result Code. Per Microsoft Learn, the event requires the "Audit Kerberos Authentication Service" advanced audit policy to be enabled for Success and/or Failure events.
Why it matters
Core concepts
The Kerberos AS-REQ/AS-REP Exchange
The AS-REQ/AS-REP exchange is the first phase of Kerberos authentication where the client proves its identity and receives a TGT.
Kerberos authentication happens in two phases. Phase 1 (AS exchange, logged as Event 4768) gets the TGT. Phase 2 (TGS exchange, logged as Event 4769) uses the TGT to get a service ticket for a specific resource. Pre-authentication in the AS-REQ prevents offline brute-force attacks: the client must prove it knows the password before the DC issues a TGT. Without pre-authentication, an attacker can request a TGT for any account and crack the encrypted response offline, an attack known as AS-REP Roasting.
Example
A user types their password on a domain-joined PC. The PC encrypts a timestamp with the user's password hash and sends it as an AS-REQ to the DC. The DC decrypts it, validates the account, and returns a TGT in the AS-REP.
Why it matters — Understanding this exchange explains why 4768 is the starting point for all Kerberos authentication analysis.
Result Codes and Failure Analysis
The Result Code in Event 4768 indicates whether the TGT request succeeded (0x0) or failed with a specific Kerberos error.
Key failure codes for security monitoring: 0x0 = success, 0x6 = client not found (bad username), 0x12 = account disabled or expired, 0x17 = password has expired, 0x18 = pre-authentication failed (wrong password, also the brute-force indicator), 0x25 = clock skew too great (time sync issue). The Result Code is the single most important field for security analysis. Repeated 0x18 from one IP is a brute-force pattern. A burst of 0x6 means the attacker is enumerating usernames.
Example
Result Code 0x18 = KDC_ERR_PREAUTH_FAILED, meaning the password was wrong. Result Code 0x6 = KDC_ERR_C_PRINCIPAL_UNKNOWN, meaning the username doesn't exist in AD.
Why it matters — The result code tells you exactly why an authentication failed, driving both troubleshooting and threat detection.
Audit Policy Requirements
The Audit Kerberos Authentication Service policy under Advanced Audit Policy Configuration controls whether Event 4768 is generated.
Event 4768 only fires when the Audit Kerberos Authentication Service policy is enabled on the domain controller. It's separate from the legacy "Audit account logon events" policy. Per Microsoft's documentation, the advanced audit policy should be used instead of the legacy policy for granular control. Enabling only failure auditing reduces log volume while keeping the security-critical signals. On busy DCs, success auditing alone can generate thousands of events per hour.
Example
Enable via Group Policy: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Account Logon > Audit Kerberos Authentication Service = Success and Failure.
Why it matters — Without this policy enabled, 4768 events aren't generated, leaving a blind spot in authentication monitoring.
Benefits
Complete authentication visibility
4768 logs every authentication attempt with account name, client IP, and result code, providing a complete audit trail.
After a breach, investigators trace the attacker's initial access by filtering 4768 events for the compromised account's first successful TGT request from an unusual IP.
Brute-force and credential attack detection
Repeated 0x18 failures from a single IP, or 0x6 bursts (username enumeration), are directly visible in 4768 data.
A SIEM rule alerts when more than 20 failed 4768 events (code 0x18) occur from one client IP within 5 minutes.
Fast authentication troubleshooting
Result codes map directly to specific issues (expired password, disabled account, clock skew), cutting troubleshooting time.
A help desk ticket reports 'can't log in.' The admin filters 4768 for the username, sees result code 0x17, and confirms the password expired.
Limitations
High event volume on busy DCs
MediumBusy DCs can generate thousands of 4768 events per hour. Without filtering or SIEM forwarding, the Security log fills quickly.
Workaround — Enable failure-only auditing to reduce volume. Forward events to a SIEM with retention and search capabilities. Increase the Security log max size.
Logged only on domain controllers
Medium4768 only fires on DCs, not on member servers or workstations. If you don't collect logs from all DCs, you'll miss events.
Workaround — Use Windows Event Forwarding or SIEM agents on every DC. Centralize collection to ensure complete coverage.
No context on post-authentication activity
Low4768 shows the TGT request but not what the user did next. You need 4769 (service ticket) and 4624 (logon) events for the full picture.
Workaround — Correlate 4768 with Event 4769 (TGS requests), 4624 (logon), and 4625 (failed logon) for end-to-end authentication tracking.
Myths, corrected
Myth
Event 4768 fires on every machine in the domain
Correction
Event 4768 is generated only on domain controllers , specifically by the KDC service. Client machines and member servers never produce this event. The client-side equivalent is Event 4648 (explicit credential logon) or 4624 (successful logon).
Why it happens: Admins look for 4768 on workstations after a user reports a login issue, then think logging is broken.
Myth
A failed 4768 always means a wrong password
Correction
Result code 0x18 means wrong password (pre-auth failed). But other codes mean different things: 0x6 = unknown username, 0x12 = disabled/expired account, 0x17 = expired password, 0x25 = clock skew. Each requires a different response.
Why it happens: Admins see 'failure' and assume password, without reading the result code.
Myth
Enabling 4768 auditing slows down authentication
Correction
The audit event is written to the log asynchronously after the authentication decision is made. It doesn't add latency to the Kerberos exchange itself. The performance impact is on log I/O, not authentication speed.
Why it happens: Concerns about audit overhead on DCs lead admins to disable useful audit policies.
Practical implications
For admins
Enable Audit Kerberos Authentication Service on all DCs. Set Security log size to at least 1 GB. Build PowerShell queries filtering for result codes 0x6, 0x12, 0x17, 0x18. Correlate 4768 with 4769 and 4624 for complete authentication tracing.
For MSPs
Include 4768 monitoring in every AD-connected client's security stack. Build standardized SIEM rules for brute-force (0x18 threshold), username enumeration (0x6 bursts), and off-hours privileged account access.
For business
4768 monitoring directly supports compliance mandates (SOX, HIPAA, PCI-DSS, ISO 27001) that require authentication audit trails. It also reduces incident response time by providing immediate forensic data.
For security
Build detection rules around: 0x18 bursts from single IPs (brute force), 0x6 bursts (username enumeration), TGT requests for accounts without pre-auth (AS-REP Roasting targets), privileged account access from unusual IPs or times, and RC4 encryption type requests (potential downgrade attack). Correlate with Event 4769 for Kerberoasting detection.
Decision guide
Use when
- You need to detect brute-force attacks, password spraying, or credential stuffing against AD.
- You want to monitor for AS-REP Roasting attempts against accounts without pre-authentication.
- Compliance requires an audit trail of all domain authentication attempts.
Avoid when
- You only need to track NTLM authentication (use Event 4776 instead).
- You only need logon success/failure without Kerberos detail (use Event 4624/4625).
Requirements
- Active Directory domain controllers running Windows Server 2008 or later.
- Audit Kerberos Authentication Service policy enabled for Success and/or Failure.
- Centralized log collection (WEF or SIEM) across all DCs for complete coverage.
Alternatives
- Event 4771 for Kerberos pre-authentication failures specifically.
- Event 4625 for logon failures across all authentication protocols (not just Kerberos).
- Event 4769 for tracking which services authenticated users access after getting a TGT.
Frequently asked questions
What's the difference between Event 4768 and 4769?
Event 4768 fires when a TGT is requested (the first step, AS-REQ to the KDC). Event 4769 fires when a service ticket is requested using an existing TGT (the second step, TGS-REQ). Together they trace the full Kerberos authentication flow: 4768 = who logged in, 4769 = what they accessed.
How do I tell if a 4768 event is a success or failure?
Check the Result Code field. 0x0 = success. Any other code = failure. Key codes: 0x6 (unknown username), 0x12 (account disabled/expired), 0x17 (password expired), 0x18 (wrong password / pre-auth failed), 0x25 (clock skew too great).
How do I enable Event 4768 logging?
Enable 'Audit Kerberos Authentication Service' under Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Account Logon. Set it to audit Success and/or Failure events. Apply to the Default Domain Controllers GPO.
What attack patterns can I detect with Event 4768?
Monitor for: repeated 0x18 from one IP (brute force), bursts of 0x6 (username enumeration), 4768 events for accounts with pre-auth disabled (AS-REP Roasting target), TGT requests for privileged accounts from unusual IPs or outside business hours, and high-volume failures across many accounts (password spray).
Is high 4768 volume normal?
Yes. Busy DCs can generate thousands per hour. Reduce volume by enabling failure-only auditing, forwarding to a SIEM, and increasing the Security log size. Success events are less critical for security but useful for compliance.
What is AS-REP Roasting and how does 4768 relate?
AS-REP Roasting targets accounts where Kerberos pre-authentication is disabled. Attackers request TGTs for these accounts (visible as 4768 events), then crack the encrypted AS-REP response offline. Monitor for 4768 success events where the pre-auth type indicates no pre-authentication was required.
Conclusion
Event ID 4768 logs every Kerberos TGT request on Active Directory domain controllers. It captures account name, client IP, encryption type, and result code for both successful and failed authentication attempts. The result code (0x0 success, 0x6 bad username, 0x18 wrong password, 0x12 disabled, 0x17 expired, 0x25 clock skew) drives both troubleshooting and security detection. The event requires the Audit Kerberos Authentication Service policy and fires only on DCs.
Main takeaway
Look into Event 4769 (TGS service ticket requests), Event 4771 (Kerberos pre-auth failed, the companion failure event), and Event 4625 (logon failure) to build a complete authentication monitoring strategy.
-640x640.webp&w=3840&q=75)