ANAVEM
Languagefr
Windows domain controller security monitoring dashboard showing Event Viewer with security audit logs
Event ID 4713InformationMicrosoft-Windows-Security-AuditingWindows

Windows Event ID 4713 – Microsoft-Windows-Security-Auditing: Kerberos Policy Changed

Event ID 4713 fires when Kerberos authentication policy settings are modified on a domain controller, indicating changes to ticket lifetime, renewal settings, or other Kerberos security parameters.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 20269 min read 0
Event ID 4713Microsoft-Windows-Security-Auditing 5 methods 9 min
Event Reference

What This Event Means

Event ID 4713 represents a security audit event that Windows generates when Kerberos authentication policy undergoes modification within an Active Directory domain. This event occurs exclusively on domain controllers and captures comprehensive details about policy changes affecting the domain's authentication infrastructure.

The event triggers when administrators modify settings such as maximum ticket lifetime for user accounts, maximum ticket lifetime for services, maximum tolerance for computer clock synchronization, and maximum lifetime for user ticket renewal. These parameters directly control how Kerberos authentication operates across the domain, making their modification significant from both security and operational perspectives.

Windows records this event in the Security log with detailed information including the changed policy attributes, previous values, new values, and the security identifier of the account making the changes. The event also captures the computer name where the change originated and the process responsible for the modification.

From a security monitoring standpoint, Event ID 4713 serves as a critical indicator for tracking authentication policy changes that could affect domain security posture. Malicious actors with sufficient privileges might attempt to weaken Kerberos settings to facilitate attacks, making this event valuable for detecting unauthorized policy modifications.

Applies to

Windows Server 2019Windows Server 2022Windows Server 2025
Analysis

Possible Causes

  • Administrator modifying Kerberos policy through Group Policy Management Console
  • PowerShell cmdlets changing domain authentication settings using Set-ADDomainMode or similar commands
  • Direct modification of Kerberos settings through Active Directory Users and Computers
  • Automated scripts or configuration management tools updating authentication policies
  • Domain controller promotion or demotion processes affecting Kerberos configuration
  • Security compliance tools adjusting authentication parameters to meet organizational requirements
  • Third-party Active Directory management tools modifying Kerberos settings
  • Restoration of Group Policy objects containing Kerberos policy modifications
Resolution Methods

Troubleshooting Steps

01

Review Event Details in Event Viewer

Start by examining the complete event details to understand what Kerberos policy changed and who initiated the modification.

  1. Open Event Viewer on the affected domain controller
  2. Navigate to Windows LogsSecurity
  3. Filter for Event ID 4713 using the filter option
  4. Double-click the event to view detailed information
  5. Review the General tab for policy change details including:
    • Subject security identifier and account name
    • Changed policy attributes and their new values
    • Process name and ID responsible for the change
    • Source computer name
  6. Check the Details tab for XML view with complete event data
  7. Note the timestamp to correlate with other administrative activities

Use PowerShell to query multiple events efficiently:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4713} -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
02

Analyze Kerberos Policy Changes with PowerShell

Use PowerShell to extract and analyze specific Kerberos policy modifications from Event ID 4713 entries.

  1. Query events with detailed filtering:
$Events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4713; StartTime=(Get-Date).AddDays(-7)}
foreach ($Event in $Events) {
    $EventXML = [xml]$Event.ToXml()
    $EventData = $EventXML.Event.EventData.Data
    Write-Host "Time: $($Event.TimeCreated)"
    Write-Host "Subject: $($EventData | Where-Object {$_.Name -eq 'SubjectUserName'} | Select-Object -ExpandProperty '#text')"
    Write-Host "Policy Changed: $($EventData | Where-Object {$_.Name -eq 'PolicyChanged'} | Select-Object -ExpandProperty '#text')"
    Write-Host "New Value: $($EventData | Where-Object {$_.Name -eq 'NewValue'} | Select-Object -ExpandProperty '#text')"
    Write-Host "---"
}
  1. Export events to CSV for analysis:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4713} | Select-Object TimeCreated, Id, LevelDisplayName, UserId, ProcessId, MachineName | Export-Csv -Path "C:\Temp\Kerberos_Policy_Changes.csv" -NoTypeInformation
  1. Check current Kerberos policy settings:
Get-ADDomain | Select-Object MaxPwdAge, MinPwdAge, LockoutDuration, LockoutObservationWindow
03

Verify Group Policy Kerberos Settings

Investigate Group Policy objects to identify the source of Kerberos policy changes and verify current settings.

  1. Open Group Policy Management Console (gpmc.msc)
  2. Navigate to the domain and expand Group Policy Objects
  3. Right-click the Default Domain Policy and select Edit
  4. Navigate to Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAccount PoliciesKerberos Policy
  5. Review current settings for:
    • Maximum lifetime for user tickets
    • Maximum lifetime for service tickets
    • Maximum tolerance for computer clock synchronization
    • Maximum lifetime for user ticket renewal
  6. Check the Security tab to see who has permissions to modify the policy
  7. Use PowerShell to query Group Policy settings:
Get-GPO -All | Where-Object {$_.DisplayName -like "*Default Domain Policy*"} | Get-GPOReport -ReportType HTML -Path "C:\Temp\DomainPolicy.html"
  1. Generate Group Policy Results to see effective settings:
gpresult /h "C:\Temp\GPResult.html" /f
Pro tip: Use Get-GPPermission to check who can modify domain-level Group Policy objects that contain Kerberos settings.
04

Correlate with Administrative Actions

Cross-reference Event ID 4713 with other security events to build a complete picture of administrative activities.

  1. Search for related logon events around the same timeframe:
$StartTime = (Get-Date).AddHours(-2)
$EndTime = (Get-Date)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625,4648; StartTime=$StartTime; EndTime=$EndTime} | Where-Object {$_.Message -like "*administrator*" -or $_.Message -like "*domain admin*"}
  1. Check for Group Policy modification events (Event ID 5136):
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5136; StartTime=(Get-Date).AddDays(-1)} | Where-Object {$_.Message -like "*Kerberos*" -or $_.Message -like "*policy*"}
  1. Review process creation events (Event ID 4688) for administrative tools:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-4)} | Where-Object {$_.Message -like "*gpmc.msc*" -or $_.Message -like "*powershell*" -or $_.Message -like "*dsa.msc*"}
  1. Check Windows PowerShell operational log for cmdlet usage:
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" -MaxEvents 100 | Where-Object {$_.Message -like "*Set-AD*" -or $_.Message -like "*Kerberos*"}
  1. Generate a timeline report combining multiple event sources:
$Timeline = @()
$Timeline += Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4713,4624,4648,5136; StartTime=(Get-Date).AddDays(-1)}
$Timeline | Sort-Object TimeCreated | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-Table -Wrap
05

Implement Advanced Monitoring and Alerting

Set up comprehensive monitoring for Kerberos policy changes to detect unauthorized modifications in real-time.

  1. Create a scheduled task to monitor for Event ID 4713:
$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-Command Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4713; StartTime=(Get-Date).AddMinutes(-5)} | ForEach-Object {Send-MailMessage -To 'admin@company.com' -From 'dc@company.com' -Subject 'Kerberos Policy Changed' -Body $_.Message -SmtpServer 'mail.company.com'}"
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 5) -RepetitionDuration (New-TimeSpan -Days 365)
Register-ScheduledTask -TaskName "Monitor-KerberosPolicy" -Action $Action -Trigger $Trigger -RunLevel Highest
  1. Configure Windows Event Forwarding for centralized monitoring:
# On collector server
wecutil cs subscription.xml

# Create subscription.xml with Event ID 4713 filter
@"
<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
    <SubscriptionId>KerberosPolicyMonitoring</SubscriptionId>
    <SubscriptionType>SourceInitiated</SubscriptionType>
    <Query>
        <![CDATA[
        <QueryList>
            <Query Id="0">
                <Select Path="Security">*[System[EventID=4713]]</Select>
            </Query>
        </QueryList>
        ]]>
    </Query>
</Subscription>
"@ | Out-File subscription.xml
  1. Set up custom Event Viewer views for Kerberos policy monitoring:
# Create custom view XML
$CustomView = @"
<ViewerConfig>
  <QueryConfig>
    <QueryParams>
      <Simple>
        <Channel>Security</Channel>
        <EventId>4713</EventId>
        <RelativeTimeInfo>604800000</RelativeTimeInfo>
      </Simple>
    </QueryParams>
  </QueryConfig>
</ViewerConfig>
"@
$CustomView | Out-File "C:\Windows\System32\winevt\Logs\KerberosPolicyView.xml"
  1. Configure audit policy to ensure Event ID 4713 generation:
auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:enable
auditpol /get /subcategory:"Authentication Policy Change"
Warning: Excessive monitoring can generate significant log volume. Configure retention policies and storage accordingly.

Overview

Event ID 4713 generates when administrators modify Kerberos authentication policy settings on Active Directory domain controllers. This security audit event captures changes to critical authentication parameters including maximum ticket lifetime, renewal periods, clock skew tolerance, and enforcement settings. The event fires immediately when Group Policy changes affect Kerberos settings or when direct modifications occur through Active Directory Users and Computers or PowerShell cmdlets.

This event appears exclusively in the Security log on domain controllers and requires audit policy configuration for Policy Change events. Windows generates 4713 events for both successful policy modifications and failed attempts when insufficient permissions exist. The event provides detailed information about which specific Kerberos parameters changed, the previous and new values, and the security principal responsible for the modification.

Understanding Event ID 4713 is crucial for security monitoring since Kerberos policy changes can significantly impact domain authentication security. Unauthorized modifications to ticket lifetimes or enforcement settings could create security vulnerabilities or authentication failures across the domain environment.

Frequently Asked Questions

What does Event ID 4713 mean and when does it occur?+
Event ID 4713 indicates that Kerberos authentication policy has been modified on a domain controller. This event fires whenever administrators change settings like maximum ticket lifetime, renewal periods, clock skew tolerance, or other Kerberos parameters through Group Policy, PowerShell, or Active Directory management tools. The event provides detailed information about what changed, who made the change, and when it occurred.
Why am I not seeing Event ID 4713 in my Security log?+
Event ID 4713 requires specific audit policy configuration to generate. You must enable auditing for 'Authentication Policy Change' subcategory using the command 'auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:enable'. Additionally, this event only appears on domain controllers, not on member servers or workstations. Verify that audit policy is properly configured and that you're checking the correct domain controller's Security log.
How can I determine what specific Kerberos setting was changed in Event ID 4713?+
Event ID 4713 contains detailed information in its event data fields. Use PowerShell to parse the event XML and extract specific details: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4713} | ForEach-Object {[xml]$_.ToXml() | Select-Object -ExpandProperty Event}. Look for fields like 'PolicyChanged', 'OldValue', and 'NewValue' to see exactly what Kerberos parameter was modified and its previous and current values.
Should I be concerned about frequent Event ID 4713 occurrences?+
Frequent Event ID 4713 events warrant investigation, especially if they occur outside of planned maintenance windows. While legitimate administrative activities can generate these events, unauthorized or unexpected Kerberos policy changes could indicate security issues. Review the account making changes, verify the modifications align with organizational policies, and ensure proper change management procedures were followed. Consider implementing alerting for these events in production environments.
Can Event ID 4713 help detect security attacks on my domain?+
Yes, Event ID 4713 is valuable for detecting certain types of attacks. Malicious actors with sufficient privileges might attempt to weaken Kerberos settings to facilitate attacks like Golden Ticket or Silver Ticket scenarios. Monitor for changes that extend ticket lifetimes beyond organizational standards, reduce security requirements, or occur from unexpected accounts. Correlate these events with other security indicators like unusual logon patterns, privilege escalation attempts, or suspicious PowerShell activity to identify potential security incidents.
Documentation

References (2)

Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...