چک‌لیست جامع مهاجرت امنیتی از NTLM به Kerberos در اکتیو دایرکتوری مایکروسافت

مقدمه

پروتکل‌های احراز هویت سنگ بنای امنیت زیرساخت شبکه‌های ویندوزی مبتنی بر Active Directory Domain Services (AD DS) محسوب می‌شوند. سال‌هاست که کارشناسان امنیت سایبری بر مخاطرات جدی پروتکل کهنسال NTLM (NT LAN Manager) تاکید دارند. این پروتکل که ریشه در دهه‌های گذشته دارد، در برابر حملات مدرنی نظیر Pass-the-Hash، سرقت هش‌ها، حملات رله (NTLM Relay) و تکنیک‌های نفوذ Man-in-the-Middle به‌شدت آسیب‌پذیر است. مایکروسافت از سال ۲۰۲۳ رسماً بازنشستگی تدریجی NTLM را اعلام نموده و سازمان‌ها را به پذیرش کامل Kerberos فراخوانده است.

استفاده از این چک‌لیست برای مدیران شبکه و معماران امنیت سازمانی زمانی ضرورت پیدا می‌کند که قصد ارتقای سطح بلوغ امنیتی شبکه به استانداردهای Zero Trust و جلوگیری از تهدیدات گسترده نفوذگران را دارند. پیاده‌سازی Kerberos نه‌تنها متضمن امضای دیجیتال و رمزنگاری دوجانبه (Mutual Authentication) با استانداردهایی همچون AES-256 است، بلکه بلیت‌های احراز هویت را در مقابل شنود و جعل ایمن می‌سازد. در این مقاله جامع، چک‌لیستی عملیاتی و چهارمرحله‌ای برای کشف، استقرار، اعتبارسنجی و نگهداری امنیتی این گذار حیاتی گردآوری شده است.

---

بخش ۱: آماده‌سازی

پیش از هرگونه دستکاری در سیاست‌های سازمانی، شناخت کامل ترافیک احراز هویت فعلی شبکه الزامی است. اجرای شتاب‌زده محدودیت‌های NTLM می‌تواند سرویس‌های سنتی، پرینترها، سیستم‌های ذخیره‌سازی تحت شبکه (NAS) یا برنامه‌های legacy را مختل سازد. در فاز آماده‌سازی، هدف اصلی ثبت دقیق تمامی رخدادهای NTLM و فراهم‌سازی مقدمات فنی Kerberos در سراسر دامنه‌های سازمانی است.

• فعال‌سازی ممیزی NTLM از طریق Group Policy: نخستین گام، اعمال پالیسی Network security: Restrict NTLM: Audit NTLM authentication in this domain در سطح تمام Domain Controllerها است تا هرگونه تراکنش NTLM ثبت لاگ شود.
• تنظیم لاگ‌گیری کلاینت‌ها و سرورها: سیاست‌های Audit incoming NTLM traffic و Audit NTLM authentication in this domain را روی وضعیت Enable All قرار دهید.
• بررسی رخدادهای Event ID 8001 تا 8004: در مسیر لاگ‌های ویندوز Applications and Services Logs > Microsoft > Windows > NTLM > Operational، تمام ترافیک‌های فعال را ممیزی کنید.
• ارزیابی سلامت سرویس DNS: از تطابق کامل رکوردهای Forward و Reverse Lookup برای تمام سرورها و Domain Controllerها اطمینان حاصل نمایید؛ زیرساخت Kerberos شدیداً به صحت نام کامل دامنه (FQDN) وابسته است.
• بررسی هماهنگی ساعت شبکه (NTP): اطمینان حاصل کنید که اختلاف زمان تمام کلاینت‌ها و سرورها با ساعت سرورهای PDC Emulator کمتر از ۵ دقیقه (۳۰۰ ثانیه استاندارد کربروس) باشد.
• تهیه موجودی از برنامه‌های Legacy: کلیه نرم‌افزارهای تجاری سازمان، سرویس‌های متصل با آدرس IP خام و تجهیزات غیرویندوزی (لینوکس و مکینتاش) را مستندسازی کنید.

«مهاجرت موفق از NTLM صرفاً یک تنظیم پالیسی نیست؛ بلکه پروژه‌ای استراتژیک در مهندسی هویت سازمان است که در صورت پایش دقیق لاگ‌ها، بدون حتی یک ثانیه وقفه در کسب‌وکار قابل تحقق است.»

---

بخش ۲: اجرا

پس از ارزیابی کامل لاگ‌ها و شناسایی کلاینت‌هایی که همچنان به NTLM متکی هستند، فاز پیاده‌سازی و تقویت Kerberos آغاز می‌شود. در این مرحله باید مؤلفه‌هایی نظیر Service Principal Name (SPN) به درستی کانفیگ شوند و پروتکل‌های رمزنگاری ضعیف کنار گذاشته شوند.

1. ثبت دقیق و اختصاصی SPNها: برای هر سرویس تحت شبکه (مانند IIS، MSSQL یا فایل‌سرورها)، با استفاده از ابزار SetSPN نام یکتای شناسه سرویس را ثبت کنید تا از fallback به NTLM جلوگیری شود.
2. ارتقای رمزنگاری اکتیو دایرکتوری به AES: اطمینان حاصل کنید که الگوریتم‌های رمزنگاری RC4 و DES در سطح Kerberos غیرفعال شده و تنها استانداردهای AES-128 و AES-256 فعال باشند.
3. تنظیم سیاست‌های KDC در GPO: پیکربندی بیشینه طول عمر بلیت‌های تیکت (TGT) روی ۱۰ ساعت و تمدید مجدد روی ۷ روز را تثبیت کنید.
4. پیکربندی استثنائات موقت (Exceptions): در پالیسی Restrict NTLM: Add server exceptions in this domain نام سیستم‌هایی که فعلاً قادر به پشتیبانی از Kerberos نیستند وارد کنید تا از قطعی سرویس ممانعت شود.
5. مسدودسازی گام‌به‌گام NTLMv1: ابتدا NTLMv1 را به طور کامل قطع کرده و مقدار پالیسی LAN Manager authentication level را روی گزینه ۵ یعنی Send NTLMv2 response only. Refuse LM & NTLM تنظیم کنید.
6. اعمال تدریجی بلوکه کردن ترافیک خروجی NTLM: پالیسی Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers را روی سرورهای حساس فعال نمایید.

---

بخش ۳: اعتبارسنجی

اعتبارسنجی فرآیندی است که تضمین می‌کند سیستم‌ها واقعاً از تیکت‌های Kerberos استفاده می‌کنند و هیچ نشست مخفی یا تلاش برای دور زدن پروتکل امن وجود ندارد.

• بررسی صدور تیکت‌ها با Klist: با اجرای دستور klist tickets در سشن کاربران، از دریافت تیکت‌های Service Ticket و استفاده از الگوریتم Kerberos AES 256 اطمینان حاصل کنید.
• پایش Event ID 4624 در سرورها: ورودهای موفق کاربران در لاگ Security با کد Logon Type 3 را مانیتور کرده و تأیید کنید که در فیلد Authentication Package عبارت Kerberos درج شده باشد نه NTLM.
• مانیتورینگ پورت‌های اختصاصی Kerberos: از باز بودن پورت‌های ۸۸ (TCP/UDP) و ۴۶۴ (Kerberos Change Password) بین کلاینت‌ها و دامین کنترلرها با استفاده از فایروال اطمینان کسب کنید.
• تست احراز هویت با نام FQDN به جای IP: اطمینان یابید کاربران به جای اتصال از طریق فرمت \192.168.1.10\Share از ساختار استاندارد \Server01.domain.local\Share استفاده می‌کنند؛ اتصال مستقیم به IP همواره احراز هویت را به سمت NTLM سوق می‌دهد.
• تحلیل سشن‌های بدون لاگین NTLM: لاگ‌های رویداد ۸۰۰۲ و ۸۰۰۳ را فیلتر کنید تا مطمئن شوید ترافیک بلاک‌شده حاوی ترافیک بحرانی و کسب‌وکاری نبوده است.
• ارزیابی رفتار احراز هویت کلاینت‌های غیرویندوزی: ماشین‌های لینوکسی ملحق به دامنه از طریق SSSD یا Samba را از نظر تولید تیکت‌های TGT بررسی فرمایید.

---

بخش ۴: نگهداری

نگهداری و سخت‌سازی مستمر مستلزم پایش سلامت، محافظت در برابر تکنیک‌های نفوذ اختصاصی Kerberos مانند Kerberoasting و AS-REP Roasting و نهایتاً غیرفعال‌سازی قطعی و کامل مکانیزم fallback است.

امنیت پیشرفته حساب‌های کاربری

حساب‌های کاربری متصل به SPNها هدف شماره یک نفوذگران هستند. به همین منظور باید طول رمز عبور این حساب‌ها بیش از ۲۵ کاراکتر باشد یا به طور کامل به حساب‌های مدیریت‌شده گروهی (gMSA) منتقل گردند.

• حفاظت در برابر Kerberoasting: رمزهای عبور حساب‌های سرویس متصل به SPN را با استفاده از کاراکترهای پیچیده طولانی تقویت کرده و به صورت دوره‌ای تغییر دهید.
• فعال‌سازی ویژگی Protected Users Group: کاربران با دسترسی‌های ممتاز (Domain Admins) را عضو گروه امنیتی Protected Users کنید؛ عضویتی که به طور ذاتی استفاده از NTLM را برای آنها قدغن می‌کند.
• پایش مداوم کدهای خطا و ممیزی سالانه: تنظیم داشبوردهای تحلیلی در Microsoft Sentinel یا Splunk برای کشف مجدد هرگونه ترافیک NTLM ناخواسته.
• بررسی تمدید بلیت‌ها و زمان انقضا: بررسی تطابق مداوم تنظیمات تیکت‌ها در تمامی سایت‌های اکتیو دایرکتوری در سطح Domain Controllerها.
• توسعه gMSA (Group Managed Service Accounts): تبدیل اکانت‌های سرویس معمولی به اکانت‌های gMSA برای مدیریت خودکار رمزهای ۱۲۸ بیتی توسط ویندوز سرور.
• حذف نهایی استثنائات NTLM: بعد از گذشت دوره گذار ۳ تا ۶ ماهه، کلیه Exceptionهای تعریف‌شده را تک‌به‌تک حذف کرده و مسدودسازی سراسری ۱۰۰ درصدی را قفل نمایید.

---

جدول مقایسه فنی: تفاوت‌های بنیادین Kerberos و NTLM

در جدول زیر مهم‌ترین وجوه افتراق این دو پروتکل کلیدی را در محیط‌های مدرن مشاهده می‌کنید:

| شاخص امنیتی / فنی | NTLMv2 | Kerberos v5 | وضعیت توصیه مایکروسافت | | :--- | :--- | :--- | :--- | | احراز هویت متقابل (Mutual) | خیر (فقط سرور کلاینت را تایید می‌کند) | بله (کلاینت و سرور هر دو تایید می‌شوند) | الزامی برای محیط‌های Zero Trust | | الگوریتم‌های رمزنگاری | MD4 / MD5 / HMAC-MD5 | AES-128 / AES-256 / SHA-2 | منسوخ‌سازی قطعی MD4 و MD5 | | وابستگی به Domain Controller | در هر بار لاگین به ازای هر سرویس | تنها در زمان صدور اولیه TGT | کاهش بار کاری Domain Controllerها | | تکنولوژی تفویض اختیار (Delegation) | غیرممکن یا بسیار ناامن | پشتیبانی از Kerberos Constrained Delegation | محافظت قطعی در معماری چندلایه | | مقاومت در برابر Relay Attacks | به‌شدت آسیب‌پذیر بدون EPA | کاملاً مصون به واسطه معماری بلیت | توقف فوری حملات رله شبکه |

---

جدول چک‌لیست کامل مهاجرت

چک‌لیست زیر را می‌توانید به عنوان سند اجرایی در پروژه ارتقای امنیت شبکه سازمان خود پیاده‌سازی و کنترل کنید:

| بخش | شرح اقدام فنی | نوع اقدام | اولویت | وضعیت | | :--- | :--- | :--- | :--- | :--- | | آماده‌سازی | فعال‌سازی لاگ‌های NTLM Operational | سیستمی | بحرانی | [ ] | | آماده‌سازی | بازبینی سلامت FQDN در DNS Serverها | زیرساختی | بالا | [ ] | | آماده‌سازی | بررسی تلورانس زمان در سرویس W32Time | سیستمی | بحرانی | [ ] | | آماده‌سازی | ارزیابی لاگ‌های Event ID 8001 تا 8004 | نظارتی | بالا | [ ] | | آماده‌سازی | استخراج لیست تجهیزات و سرویس‌های Legacy | مستندسازی | متوسط | [ ] | | آماده‌سازی | تحلیل وابستگی احراز هویت پرینترها و NAS | تحلیلی | متوسط | [ ] | | اجرا | ثبت کلیه SPNهای مفقود با SetSPN | پیکربندی | بحرانی | [ ] | | اجرا | فعال‌سازی پشتیبانی از الگوریتم AES در دامین | امنیتی | بحرانی | [ ] | | اجرا | غیرفعال‌سازی قطعی NTLMv1 از طریق GPO | امنیتی | بالا | [ ] | | اجرا | ایجاد لیست Server Exceptions موقت در پالیسی | مدیریتی | بالا | [ ] | | اجرا | تنظیم بلیت‌های TGT و Kerberos Lifetime | پالیسی | متوسط | [ ] | | اجرا | اعمال محدودیت تدریجی NTLM Outgoing | امنیتی | بالا | [ ] | | اعتبارسنجی | بازرسی تیکت‌های کاربران با دستور Klist | مانیتورینگ | بالا | [ ] | | اعتبارسنجی | تایید کد پکیج Kerberos در Event ID 4624 | مانیتورینگ | بحرانی | [ ] | | اعتبارسنجی | اطمینان از باز بودن پورت‌های 88 و 464 | شبکه | بالا | [ ] | | اعتبارسنجی | بررسی اتصال کلاینت‌ها فقط از طریق نام دامنه | تست بالینی | متوسط | [ ] | | اعتبارسنجی | تست سرویس‌های شیرینگ و فایل‌سرورها | آزمون عملیات | بالا | [ ] | | اعتبارسنجی | صحه‌سنجی نشست‌های کلاینت‌های غیرویندوزی | مانیتورینگ | متوسط | [ ] | | نگهداری | انتقال ادمین‌های شبکه به Protected Users | سخت‌سازی | بحرانی | [ ] | | نگهداری | پیاده‌سازی حساب‌های gMSA برای سرویس‌ها | مهندسی | بالا | [ ] | | نگهداری | مقاوم‌سازی در برابر حملات Kerberoasting | ارزیابی آسیب‌پذیری | بحرانی | [ ] | | نگهداری | ایجاد سیستم پایش لحظه‌ای در SIEM | خودکارسازی | بالا | [ ] | | نگهداری | حذف تدریجی تک‌تک استثنائات ثبت‌شده | پالیسی | بالا | [ ] | | نگهداری | بلاک ۱۰۰ درصدی تمام تراکنش‌های NTLM | تثبیت امنیتی | بحرانی | [ ] |

---

ابزارهای کمکی

برای اجرای دقیق این چک‌لیست، استفاده از ابزارهای بومی ویندوز و خط‌فرمان‌های تخصصی ضروری است:

• SetSPN: ابزار رسمی خط فرمان برای نمایش، ثبت و حذف رکوردهای SPN اکانت‌ها. برای مثال، دستور setspn -L ServiceAccountName تمامی شناسه‌های اختصاص‌یافته را نشان می‌دهد.
• Klist: جهت مشاهده بلیت‌های صادرشده، نوع سشن و رمزنگاری Kerberos در سیستم کلاینت جاری، اجرای دستور klist و برای پاک‌سازی سشن‌ها دستور klist purge به‌کار می‌رود.
• PowerShell ActiveDirectory Module: ماژول رسمی برای جستجوی اکانت‌های با رمزهای ضعیف یا دارای SPN فعال. برای مثال:

Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName

• Wireshark / Network Monitor: برای تحلیل بسته‌های احراز هویت و بررسی وجود بسته‌های پروتکل NTLMSSP در برابر تبادلات AS-REQ و TGS-REQ کربروس.

---

خطاهای رایج هنگام اجرا

در فرآیند گذار به Kerberos، تیم‌های فناوری اطلاعات اغلب با چالش‌ها و خطاهای مشخصی مواجه می‌شوند:

۱. استفاده از آدرس‌های IP خام

یکی از رایج‌ترین اشتباهات، تلاش کاربران یا اسکریپت‌ها برای اتصال به منابع اشتراکی از طریق IP (مانند \10.0.0.5\Data) است. پروتکل Kerberos قابلیت ساخت بلیت برای IP خام را ندارد و در این صورت، ویندوز به طور خودکار به NTLM متوسل می‌شود؛ بنابراین الزام استفاده از FQDNها الزامی است.

۲. تداخل و ثبت تکراری رکوردهای SPN (Duplicate SPN)

اگر یک نام SPN روی دو حساب کاربری یا کامپیوتر مختلف تعریف شود، احراز هویت Kerberos بلافاصله با شکست مواجه می‌شود (خطای KRB_AP_ERR_MODIFIED). با فرمان setspn -X حتماً رکوردهای تکراری را شناسایی و حذف کنید.

۳. عدم تطابق زمانی کلاینت و سرور (Clock Skew Error)

اختلاف ساعت فراتر از ۵ دقیقه میان Domain Controller و کلاینت منجر به رد بلیت با خطای KRB_AP_ERR_SKEW خواهد شد. بررسی پیوسته همگام‌سازی زمان کلاینت‌ها با PDC Emulator این چالش را برطرف می‌سازد.

---

جمع‌بندی

توقف به‌کارگیری پروتکل فرسوده و مخاطره‌آمیز NTLM دیگر صرفاً یک پیشنهاد فنی نیست، بلکه یک گام بنیادین و حیاتی در ایجاد چارچوب معماری Zero Trust در زیرساخت‌های فناوری اطلاعات مدرن تلقی می‌شود. آسیب‌پذیری‌های ذاتاً مهارنشدنی NTLM راه را برای حملات خطرناکی چون جعل هویت و دسترسی غیرمجاز هموار می‌سازند. با به‌کارگیری ساختاریافته این چک‌لیست ۲۴ بندی، مدیران سیستم می‌توانند در مراحلی سنجیده، بدون هرگونه اختلال در فرآیندهای عملیاتی و سازمانی، به یک پیاده‌سازی سراسری و پایدار از پروتکل مدرن و مستحکم Kerberos نائل آیند.