خطای KRB_AP_ERR_SKEW در Windows Server یعنی اختلاف زمان سیستم درخواست‌کننده و سرویس احراز هویت، از محدوده مجاز Kerberos بیشتر شده است. در بسیاری از دامنه‌های Active Directory مقدار پیش‌فرض این تلرانس ۵ دقیقه است، اما Group Policy می‌تواند آن را تغییر دهد. راه‌حل امن، پیدا کردن منبع زمان نامعتبر و اصلاح همگام‌سازی Windows Time (W32Time) است؛ نه افزایش بی‌دلیل تلرانس Kerberos یا تغییر دستی ساعت همه Domain Controllerها.
سناریو و نشانه‌های خطای KRB_AP_ERR_SKEW
فرض کنید کاربر هنگام ورود دامنه‌ای، دسترسی به Share، سرویس مبتنی بر Kerberos یا اتصال به یک سرور عضو دامنه با خطای احراز هویت روبه‌رو می‌شود. در Event Viewer ممکن است پیام دارای KRB_AP_ERR_SKEW یا Clock skew too great دیده شود. این خطا را از KRB_AP_ERR_MODIFIED، مشکل SPN، خرابی Secure Channel یا قطع DNS جدا کنید؛ همه خطاهای Kerberos ناشی از ساعت نیستند.
اگر خطای اصلی The trust relationship between this workstation and the primary domain failed است، ابتدا راهنمای تشخیص و تعمیر Trust Relationship بدون خروج از دامنه را بخوانید؛ تغییر ساعت به‌تنهایی کانال امن خراب را ترمیم نمی‌کند.
پیش‌نیازها و هشدار محیط Production
برای بررسی، دسترسی Administrator به سرور مشکل‌دار و دسترسی مشاهده وضعیت Domain Controller یا NTP سرور لازم است. نام دامنه، FQDN کنترلر دامنه، ساعت دقیق وقوع خطا و تغییرات اخیر مجازی‌ساز، NTP، Firewall و Group Policy را ثبت کنید. نام‌های contoso.local و dc01.contoso.local در نمونه‌ها فرضی‌اند.
هشدار: ساعت Domain Controller، به‌خصوص PDC Emulator در دامنه ریشه Forest، را بدون شناخت سلسله‌مراتب زمان و هماهنگی نگهداری تغییر ندهید. تغییر ناگهانی ساعت می‌تواند Kerberos، زمان‌بندی Jobها و اعتبار رخدادهای امنیتی را مختل کند. از تنظیمات موجود خروجی بگیرید و تا جای ممکن ابتدا عملیات فقط‌خواندنی انجام دهید.
مرحله ۱: تأیید پیام خطا و شناسایی دو سیستم درگیر
در Event Viewer بخش Windows Logs → System و در صورت نیاز لاگ‌های Security و سرویس وابسته را در زمان رخداد بررسی کنید. نمونه دستور PowerShell برای دیدن رخدادهای اخیر Kerberos:
Get-WinEvent -FilterHashtable @{
LogName = 'System'
StartTime = (Get-Date).AddHours(-6)
} -ErrorAction SilentlyContinue |
Where-Object { $_.ProviderName -like '*Kerberos*' -or $_.Message -match 'KRB_AP_ERR_SKEW|Clock skew' } |
Select-Object TimeCreated, Id, ProviderName, Message -First 20نبود رخداد در System به معنی نبود مشکل نیست؛ بسته به نقش سرویس و نوع خطا، رخداد می‌تواند در کلاینت، سرویس مقصد یا Domain Controller ثبت شود. متن دقیق و نام سرور را برای مقایسه بعدی نگه دارید. در Kerberos، «اختلاف زمان» میان مبدأ و مقصد اهمیت دارد؛ صرف درست‌بودن ساعت یک دستگاه کافی نیست.
مرحله ۲: بررسی منبع زمان، وضعیت Sync و اختلاف با DC
در CMD یا PowerShell با دسترسی مدیریتی، ابتدا روی سرور مشکل‌دار دستورات زیر را اجرا کنید:
w32tm /query /source
w32tm /query /status
w32tm /query /peers
w32tm /query /configurationخروجی /source منبع جاری زمان را نشان می‌دهد؛ /status برای آخرین همگام‌سازی و وضعیت Clock مفید است. Local CMOS Clock یا نبود منبع معتبر می‌تواند نشانه مشکل Sync باشد، اما باید نقش ماشین (Domain Member، Domain Controller یا Standalone) را نیز در نظر بگیرید.
برای سنجش اختلاف با یک DC مشخص، بدون تغییر پیکربندی از دستور زیر استفاده کنید:
w32tm /stripchart /computer:dc01.contoso.local /dataonly /samples:5نام DC را با نام واقعی جایگزین کنید. خروجی شامل Offset نمونه‌هاست؛ اختلاف زیاد یا خطای دریافت پاسخ، مسیر بررسی را مشخص می‌کند. این تست از NTP استفاده می‌کند؛ اگر پاسخ نمی‌آید، نتیجه را با عدم دسترسی UDP/123، DNS و محدودیت‌های شبکه تطبیق دهید و فقط از یک خطای شبکه نتیجه «اختلاف ساعت» نگیرید.
مرحله ۳: بررسی سلسله‌مراتب زمان در Active Directory
در دامنه، اعضا معمولاً از سلسله‌مراتب زمانی Active Directory پیروی می‌کنند؛ کنترلرها و در نهایت PDC Emulator مرجع مهمی در این زنجیره‌اند. یکسان‌کردن همه اعضا با NTP عمومی می‌تواند ساختار موردانتظار دامنه را به هم بزند. روی سیستم دارای RSAT/ماژول AD می‌توان نقش PDC را با دستور زیر مشاهده کرد:
Get-ADDomain | Select-Object DNSRoot, PDCEmulatorاگر ماژول ActiveDirectory نصب نیست، از کنسول‌های مدیریتی موجود یا دستور netdom query fsmo در محیط دارای ابزار مربوط استفاده کنید. سپس منبع زمان PDC و DCهای مرتبط را با w32tm /query بررسی کنید. روی یک DC، زمان تأثیرپذیر از Hypervisor، Snapshot یا تنظیمات تداخلی Guest Time Synchronization را هم با سیاست سازمان کنترل کنید.
برای بررسی فهرست کنترلرها و اختلافشان، روی محیط دامنه‌ای مجاز می‌توانید اجرا کنید:
w32tm /monitor /domain:contoso.localهمچنین در Group Policy مسیر Computer Configuration → Windows Settings → Security Settings → Account Policies → Kerberos Policy، تنظیم Maximum tolerance for computer clock synchronization را بررسی کنید. مقدار پیش‌فرض رایج ۵ دقیقه است، نه یک عدد تضمین‌شده برای تمام سازمان‌ها. تلرانس را صرفاً برای عبور موقت از خطا افزایش ندهید.
مرحله ۴: اصلاح امن همگام‌سازی روی Domain Member
اگر دستگاه مشکل‌دار عضو معمولی دامنه است، نه DC یا PDC Emulator، و مشخص شد تنظیم قبلی آن را به منبع زمان نامناسب متصل کرده، ابتدا وضعیت فعلی را ذخیره کنید:
w32tm /query /configuration
w32tm /query /source
Get-Service W32Timeپس از اطمینان از سالم‌بودن منبع زمان دامنه، در PowerShell یا CMD ادمین می‌توان تنظیم Domain Hierarchy را اعمال کرد:
w32tm /config /syncfromflags:domhier /update
w32tm /resync /rediscover
w32tm /query /source
w32tm /query /statusاین دستورات روی Domain Controller یا سرور Standalone بدون بررسی نقش، دستور عمومی نیستند. اگر w32tm /resync پیام no time data was available نشان داد، از تغییر دستی تاریخ خودداری کنید و آموزش رفع خطای no time data was available در W32Time را برای DNS، منبع NTP و UDP/123 دنبال کنید.
اگر سرویس زمان پاسخ نمی‌دهد چه چیزی را بررسی کنیم؟
ابتدا وضعیت سرویس را بدون تغییر بخوانید:
Get-Service W32Time
Resolve-DnsName dc01.contoso.local
w32tm /query /peersاگر W32Time متوقف است، علت توقف و تنظیمات Policy را بررسی کنید و فقط با مجوز مدیریت سرویس آن را راه‌اندازی کنید. فایروال و ACLهای بین سیستم و منبع زمان باید ترافیک NTP روی UDP/123 را طبق سیاست شبکه عبور دهند. تست TCP با Test-NetConnection -Port 123 به‌تنهایی وجود یا عدم دسترسی NTP را ثابت نمی‌کند.
برای جلوگیری از دست‌کاری منبع زمان یا خطای ناشی از NTP نامطمئن، راهنمای ملاحظات امنیتی سرویس NTP در زیرساخت شبکه را نیز مطالعه کنید.
در Windows VPS چه زمانی باید زیرساخت را بازبینی کرد؟
اگر Windows Server شما روی VPS خودمدیریت اجرا می‌شود و محدودیت کنسول، همگام‌سازی ساعت ماشین مجازی، تنظیمات Firewall یا کنترل شبکه، عیب‌یابی را دشوار کرده است، هنگام مقایسه پلن‌های سرور مجازی وان‌سرور میزان دسترسی مدیریتی و شرایط واقعی سرویس را با نیاز Active Directory بسنجید. خرید یا انتقال VPS به‌خودی‌خود خطای Kerberos را برطرف نمی‌کند؛ ابتدا باید مسیر زمان و علت اصلی تشخیص داده شود. درباره قابلیت‌های مجازی‌ساز یا دسترسی خاص هر پلن پیش از تصمیم، از پشتیبانی تأیید بگیرید.
تأیید رفع مشکل (Verify)
پس از اصلاح منبع معتبر، روی کلاینت و سرور مقصد دوباره وضعیت زمان را بررسی کنید و همان درخواست Kerberos را تکرار کنید:
w32tm /query /source
w32tm /query /status
w32tm /stripchart /computer:dc01.contoso.local /dataonly /samples:5موفقیت یعنی اختلاف ساعت با مرجع قابل‌قبول شده، منبع زمان قابل اتکا باقی مانده و احراز هویت واقعی برنامه یا کاربر بدون رخداد تازه KRB_AP_ERR_SKEW انجام می‌شود. صرف خروجی موفق w32tm /resync اثبات قطعی سلامت Kerberos نیست. چنانچه خطا ادامه دارد، DNS، SPN، Ticketهای قدیمی و ارتباط DC را جداگانه بررسی کنید. از حذف گسترده Ticketها یا Restart هم‌زمان DCها بدون برنامه جلوگیری کنید.
Rollback و خطاهای رایج
پیش از هر تغییر، خروجی w32tm /query /configuration و تنظیمات GPO اعمال‌شده را نگه دارید. اگر پیکربندی domhier برای یک Domain Member با سیاست واقعی سازمان ناسازگار بود، با هماهنگی مدیر دامنه همان Policy یا منبع زمان قبلی را بازگردانید و پس از اعمال Policy مجدداً وضعیت /source و /status را بسنجید. روی PDC Emulator هیچ تغییر خودسرانه‌ای را Rollback یا Apply نکنید؛ بازیابی آن به طراحی Time Hierarchy سازمان وابسته است.
سه خطای پرتکرار عبارت‌اند از: اصلاح ساعت تنها روی یک ماشین بدون کنترل DC، اشتباه‌گرفتن Time Zone با اختلاف UTC واقعی، و تنظیم همه اعضای دامنه روی NTP عمومی بدون توجه به PDC. برای راهنمای فنی اصلی، مستند عیب‌یابی Kerberos در Microsoft Learn مرجع مناسب است.