Authentication Policies & Authentication Policy Silos
Authentication Policies & Authentication Policy Silos چیست:
شرکت قدرتمند مایکروسافت💪، با معرفی Domain Functional Level 2012 R2، قابلیتهای جدیدی برای افزایش امنیت اکتیو دایرکتوری ارائه کرد. از جمله این قابلیتها، سیاستهای احراز هویت (Authentication Policies) و سیلوهای احراز هویت (Authentication Policy Silos) هستند.
ویژگی Authentication Policies & Authentication Policy Silos که در DFL 2025 نیز همچنان پشتیبانی می شود، به پیادهسازی مدل سطحبندی شده (Tiering) کمک کرده و امنیت دسترسیهای مدیریتی را افزایش میدهند. این ویژگیها دو هدف کلیدی را دنبال میکنند:
- کاهش زمان اعتبار TGT (Ticket Granting Ticket) برای حسابهای مدیریتی: این مقدار را میتوان به حداقل ۴۵ دقیقه کاهش داد که موجب کاهش ریسکهایی همچون Ticket Theft و Pass-the-Ticket میشود.
- محدودسازی دسترسی مدیران به سرورهای مشخصشده: این قابلیت امکان تعریف سرورهای مجاز برای ورود مدیران را فراهم میآورد، چه برای ورود محلی (Local Login) و چه ورود از راه دور (Remote Login). این امر، علاوه بر کاهش سطح حمله (Attack Surface)، کنترل بیشتری بر دسترسیها ایجاد میکند.
سیاستهای احراز هویت ،مجموعهای از قوانین هستند که تعیین میکنند چه حسابهایی به چه منابعی دسترسی داشته باشند. با استفاده از Authentication Policy Silos، میتوان گروهی از کاربران، کامپیوترها و حسابهای سرویس را در یک Silo قرار داده و قوانین احراز هویت مشخصی برای آنها تعریف کرد.
این قابلیت بهویژه در مدل Tiered Administration بسیار کاربردی است. برای مثال، حسابهای مدیریتی سطح Tier 0، مانند Domain Admins باید تنها به Domain Controllerها دسترسی داشته باشند و نباید امکان ورود به سرورهای Tier 1 یا Tier 2 را داشته باشند.
در این مقاله، اطلاعات بیشتر در مورد Active Directory Tiering، را مطالعه کنید.
-کاربرد در حسابهای سرویس و گروههای کامپیوتری:
این قابلیت تنها مختص حسابهای مدیریتی نیست، بلکه میتوان آن را برای حسابهای سرویس (Service Accounts) و گروههای کامپیوتری نیز به کار گرفت. به عنوان مثال، میتوان یک Silo ویژه برای حسابهای سرویس حساس ایجاد کرد و دسترسی آنها را فقط به سرورهای موردنیاز محدود نمود.
با بهرهگیری از Authentication Policies و Authentication Policy Silos، میتوان امنیت اکتیو دایرکتوری را به میزان قابل توجهی افزایش داده و از دسترسیهای غیرمجاز جلوگیری کرد.
پیاده سازی Authentication Policies & Authentication Policy Silos:
🔵 جهت فعال سازی این ویژگی، ابتدا نیاز هست که KDC از قابلیت های Kerberos armoring و Caliming پشتیبانی کنه و روی DC هامون فعال بشه:
برای اینکار، در Domain Controller، وارد کنسول گروپ پالیسی شده (gpmc.msc) و یک پالیسی جدید ساخته و به مسیر زیر میرویم:
Computer Configuration -> Policies -> Administrative Templates -> System -> KDC
و گزینه ی KDC support for claims, compound authentication and Kerberos armoring را به حالت Enabled در می آوریم.
Options را نیز روی مُد Supported قرار میدهیم.
نکته مهم: اگر خواستیم روی مد های دیگر قرار دهیم، باید مطمئن باشیم که در دومین ما سیستمی از پروتکل NTLM 1 استفاده نمی کند. در غیر این صورت پروسه ی احراز هویت دچار اختلال خواهد شد.
این پالیسی را بر روی DC های مان اجرا می کنیم.
🔵 در این مرحله باید کلاینت هایمان نیز KDC Armoring و Claim را ساپورت کنند.
برای این کار نیز یک پالیسی روی کلاینتهایمان تعریف میکنیم و برای تنظیمات آن از مسیر زیر :
Computer Configuration -> Policies -> Administrative Templates -> System -> Kerberos
Kerberos Client support for claims, compound authentication and Kerberos armoring را به حالت Enabled قرار میدهیم.
باید توجه کنیم که این پالیسی روی سیستم عامل ۸ به بالا ساپورت میشود. (خداییش دیگه پایین تر از این سیستم عامل استفاده نکنید!)
سپس برای سریعتر اعمال شدن این پالیسی ها از دستور gpupdate /force در CMD استفاده می کنیم.
🔵 سپس برای ایجاد Authentication Policy مورد نظرمان، به منوی Active Directory Administrative Center میرویم. (برای اینکار می توانیم در Run عبارت DSAC را تایپ کنیم)
در این کنسول، از منوی سمت راست، به مسیر زیر می رویم:
Authentication -> Authentication Policies
و با راست کلیک کردن و انتخاب گزینه ی New، یک Authentication Policy جدید ایجاد میکنیم.
- در بخش General کنسول باز شده، در قسمت Display Name، یک نام به پالیسی مون می دهیم و گزینه ی Enforce Policy Restrictions را انتخاب می کنیم.
- در بخش Service Sign On نیز، گزینه ی Specify Ticket Granting Ticket Lifetime for Services Accounts را انتخاب میکنیم و در قسمت Ticket Granting Ticket Lifetime، یک عدد به دقیقه، از ۴۵ تا ۲۱۴۷۴۸۳۶۴۷ ، برای طول عمر TGT اختصاص میدهیم.
🔵 در مرحله بعد:
از مسیر Authentication -> Authentication Policies Silo یک Authentication Policy Silo جدید ایجاد میکنیم.
در کنسول باز شده، در بخش General، یک نام به آن در قسمت Display Name می دهیم و گزینه ی Enforce Silo Policies را حتماً انتخاب میکنیم.
- در بخش Permitted Account، سیستم و اکانت هایی که میخواهیم پالیسی روی آنها اعمال بشه را انتخاب میکنیم.
توجه کنید که هم یوزرها (و سرویس اکانتها) و هم کامپیوتر اکانتهای مورد نظر را باید در این مرحله انتخاب کنیم.
- در بخش Authentication Policy، پالیسی ای که در مرحله قبل ایجاد کرده ایم را انتخاب میکنیم.
اگر برای Users، Service Account ویا Computer Account، پالیسی های جدا گانه ای نوشته بودیم، گزینه ی Use a Separate Authentication Policy for Each Type of Principal را انتخاب میکنیم و اگر مثل من در این مثال، تنها یک پالیسی کلی ایجاد کرده اید، گزینه ی Use Single Policy for All Principals that Belong to this Authentication Policy Silo را انتخاب میکنیم و در بخش The Authentication Policy that Applies to all accounts this Silo، پالیسی ای که در بخش قبل، ایجاد کرده ایم را وارد میکنیم.
🔵 در مرحله بعد، Authentication Policy Silo ای که ایجاد کرده ایم را به یوزرها و کامپیوتر اکانت هایی که انتخاب کرده بودیم، اعمال میکنیم:
برای این کار، درهمان کنسول ADAC (Active Directory Administrative Center)، از منوی سمت راست، وارد دومین شده و از آنجا یوزرها و کامپیوتر اکانتهای مورد نظر که در مرحله قبل انتخاب کردیم را انتخاب و با راست کلیک روی آن، گزینه ی Properties را انتخاب میکنیم.
و در پنجره باز شده با کلیک روی گزینه ی Silo از منوی سمت راست، در بخش Authentication Policy Silo، گزینه ی Assign Authentication Policy Silo را انتخاب کرده و Silo ای که در مرحله قبل ایجاد کرده ایم را در قسمت Authentication Policy Silo ، انتخاب میکنیم.
توجه کنید که تنظیمات این مرحله، هم برای یوزر ها و هم کامپیوتر های مورد نظرمان که در مراحل قبل انتخاب کردیم، باید اعمال شود.
- برای بررسی صحت عملکرد خود تا اینجا می توانیم مجدداً وارد Authentication Policy Silo ی ایجاد شده بشویم و در بخش Permitted Account مشاهده کنیم که Silo به درستی به اکانتهای مورد نظرمان اعمال و assign شده یا خیر.
🔵 در نهایت در این مرحله،
به Authentication Policy ای که ایجاد کرده بودیم برگشته و در بخش User Sign On، در قسمت Click Edit To Define Conditions برای تعریف یک شرط (Conditions)، روی Edit کلیک میکنیم و در پنجره باز شده، روی گزینه Add a Condition کلیک کرده و شرطی ایجاد میکنیم که Userهایی که AuthenticationSilo ی آنها برابر بود با نام Authentication Silo ای که ایجاد کردیم، مجاز لاگین روی آن کامپیوتر هاست.
قبل از رفتن به این مرحله اسم Authentication Policy Silo ای که ایجاد کرده بودیم را کپی میکنیم.
بعد از انجام مراحل ذکر شده برای اعمال سریعتر تغییرات از دستور gpupdate /force استفاده می کنیم و سپس سرور های DC را ریست میکنیم.
از دستور Klist purge، در کنسول CMD دومین کنترلر، میتوان برای حذف کلیه ی TGT ها نیز استفاده کرد و بعد DC را ریست کرد.
و تمام 🙂
حالا یوزرهایی داریم که فقط مجازهستند روی سیستم های خاصی که ما میخوایم، لاگین کنند.
نکته آخر هم اینکه اگر از Authentication Policy روی Service Account ها خواستید استفاده کنید حتما قبل از اعمال کلی، آن را تست کنید و Event Viewer را بررسی کنید، اگر حسابهای سرویس تحت Authentication Policy Silo محدود شوند و سروری که برنامه روی آن اجرا میشود در لیست مجاز نباشد، سرویس مربوطه ممکن است نتواند اعتبارسنجی کند و خطاهای زیر ممکن است رخ دهند:
Event ID 4769 (Kerberos Service Ticket Request Failure) در لاگ Security ثبت خواهد شد.
Event ID 4625 (An account failed to log on) نیز در صورت تلاش ناموفق لاگین ممکن است دیده شود.
شما هم اگر تجربه ی استفاده از این امکان قدرتمند و جالب مایکروسافت رو داشتید و یا نظری در این خصوص داشتید، خوشحال می شم که با من در میان بگذارید.
موفق باشید.🌸