بررسی امکان غیرفعال سازی LDAP Simple bind (بر اساس Microsoft Security Advisory ADV190023)

شرکت مایکروسافت اخیراً در حال آماده سازی برای اجباری نمودن LDAP Channel Binding و LDAP Signing از طریق یک بسته امنیتی است که در March 2020 ارائه خواهد نمود. از آنجا که این تغییر بدون انجام عملیات پیشگیرانه، باعث بروز اختلالات و مشکلاتی در اکثر شبکه های مبتنی بر مایکروسافت خواهد شد در این مستند به برخی از مفاهیم، تهدیدات و راهکارهای موجود خواهیم پرداخت.

شرح مسئله:

تصور کنید یک برنامه سازمانی مانند اتوماسیون اداری دارید که از طریق نام کاربری تعریف شده در اکتیو دایرکتوری به آن متصل می شوید. در صورتیکه این ارتباط رمزنگاری نشده باشد ( که در بسیاری از برنامه های قدیمی و جدید که خوب develop نشده اند و هنوز در بسیاری از سازمان ها استفاده می شوند) نام کاربری و رمز عبور شما به صورت clear text ارسال خواهد شد و به سهولت قابل کشف می باشد. شرکت مایکروسافت اخیراً در حال آماده سازی برای اجباری نمودن LDAP Channel Binding و LDAP Signing از طریق یک بسته امنیتی است که در March 2020 ارائه خواهد نمود. این تغییر، امکان برقراری ارتباطات رمزنشده با ldap server را غیرفعال خواهد نمود. از این رو امکان از کار افتادن برنامه هایی که از simple bind برای ارتباط بهره می برند قطعی می باشد. در ادامه به توضیحات بیشتری در این زمینه می پردازیم.

LDAP یک پروتکل لایه هفت جهت دستیابی به دایرکتوری ها (ازقبیل OpenLDAP یا Active Directory) می باشد. Binding مرحله ای است که LDAP server در آن اجازه انتقال اطلاعات authentication را به کلاینت داده و سپس با استفاده از آن اطلاعات، کلاینت را احراز هویت می نماید و در صورتیکه این پروسه موفقیت آمیز باشد، اجازه دسترسی به سرور را بر اساس privilege های کلاینت صادر می نماید. LDAP بر خلاف ارتباطاتی مثل http، دارای یک ارتباط connection-oriented است. یعنی احراز هویت صورت می گیرد (در فرهنگ لغت ldap آن را bind می نامند) و تمامی عملیات پس از آن، در سطح دسترسی هایی که در حین binding مشخص شده است صورت می گیرد. در طی یک ارتباط شما می توانید بارها binding انجام داده و identity خود را بدلیل تغییر دسترسی ها عوض کنید. اینکه کاربر با یک بار authenticate شدن می تواند به چندین سرویس مختلف دسترسی پیدا کند از ویژگی Single sign-on نشأت می گیرد. اعطای دسترسی به هر منبعی، طی دو مرحله Authentication (بررسی هویت کاربر) و Authorization (بررسی میزان دسترسی کاربر) صورت می گیرد.

Authentication حداقل از دو بخش تشکیل شده است: شناسایی اینکه چه شخصی یا چه چیزی احرازهویت می شود، و ارائه ی مدرکی دال بر اثبات آن هویت (چیزی که فقط آن کاربر می داند یا دارد مانند نام کاربری و رمزعبور، certificate، توکن های نرم افزاری و سخت افزاری، اثر انگشت و …). در برخی از سرورها امکان وجود مراحل بیشتری نیز وجود دارد مانند بررسی وضعیت password policy یا محدودیت های دیگری که می بایست برای موفقیت آمیز بودن Binding، رعایت شوند. دستیابی به دیتابیس اکتیودایرکتوری توسط Directory System Agent (DSA) کنترل می شود که در فایل Ntdsa.dll روی DC ها قرار دارد و بعنوان بخشی ازLocal Security Authority(LSA) تحت نام پراسس Lsass.exe اجرا می شود. در LDAP Bind request احرازهویت می تواند به دو صورت Simple authentication یا SASL authentication انجام شود. (روش سومی بنام Sicily نیز وجود دارد که بر مبنای NTLM بوده و برای سازگاری با سیستم های قدیمی است که از بحث این مستند خارج می باشد).

Simple Authentication: در این روش اکانتی که قرار است authenticate شود توسط Distinguished name (DN) که در اکتیو دایرکتوری تعریف شده، شناسایی می شود (فرمت آن به شکل CN=Ali Ahmadi,OU=Tadarokat,DC=Domain,DC=IR است) و اثبات آن هویت نیز توسط رمزعبور خواهد بود. این رمز عبور بصورت clear text و بدون هیچ تغییر شکل یا رمزنگاری انتقال می یابد و اکیداً توصیه می شود که این نوع احراز هویت فقط بر روی ارتباطات رمزنگاری شده استفاده شود (حالا که خود رمز عبور رمزنگاری نمی شود حتماً در یک ارتباط رمزنگاری شده منتقل شود). یک Anonymous simple bind را می توان به راحتی و با قراردادن یک رشته خالی در بخش DN بعنوان bind DN و رشته خالی بعنوان رمزعبور ایجاد نمود. البته در LDAPv3 فقط رمزعبور قابلیت خالی بودن را داراست و خود این موضوع عامل ایجاد مشکلات امنیتی زیادی در گذشته بوده است و بسیاری از برنامه ها و سرورها رمزعبور خالی را فقط زمانی میپذیرند که DN نیز خالی باشد.

SASL Authentication  :(Simple Authentication and Security Layer) یک روش (یا به عبارت بهتر یک دسته بندی) احراز هویت برای پروتکل های connection-based مانند LDAP است که پروتکل های احراز هویت مختلفی مثل GSS_SPNEGO، GSSAPI، EXTERNAL، DIGEST-MD5 را پشتیبانی می کند. از این رو مکانیزم های احراز هویت مختلفی در این روش می تواند وجود داشته باشد. بعنوان مثال GSS_SPNEGO از Kerberos یا NTLM بعنوان پروتکل اصلی احراز هویت و GSSAPI از Kerberos بعنوان پروتکل احراز هویت استفاده می نمایند. در این روش ممکن است نیاز باشد کلاینت و سرور چندین مرحله اطلاعات را بین هم مبادله کنند (طی چندین bind request و bind response) تا پروسه ی احرازهویت تکمیل شود. در حقیقت مکانیزم SASL می تواند متفاوت باشد اما در هر صورت در این روش از credential های کدگذاری شده استفاده می شود.

در SASL Authentication در مورد نوع رمزنگاری و integrity verification بعنوان بخشی از تراکنشها، توافق صورت می گیرد. این نوع احراز هویت را بعنوان sing and seal ( sign برای verification/integrity و seal برای encryption) نیز می نامند. اکثر کنسولهای MMC مایکروسافت بر اساس sign and seal کار می کنند.

به طور کلی LDAP bind request شامل سه جزء می باشد:
  • LDAP protocol version که کلاینت از آن استفاده خواهد نمود و نسخه 3 آن در حال حاظر آخرین نسخه است. کلاینت های خیلی قدیمی ممکن است از LDAPv2 استفاده کنند.
  • DN مربوط به کاربر برای احرازهویت. این مورد برای anonymous simple authentication و برای SASL باید خالی باشد.
  • Credential کاربر برای احرازهویت. برای simple authentication یک رمز عبور برای کاربر مشخص شده و برای SASL یک مقدار کدگذاری شده که شامل نام مکانیزم SASL و credential می باشد.

مایکروسافت به مدیران شبکه توصیه نموده است که تغییرات امنیتی را که در مستند ADV190023 بیان نموده است را انجام دهند تا از حملات man-in-the-middle که تنظیمات پیش فرض، احتمال وقوع آن را بسیار افزایش می دهند پیشگیری شود. در آپدیت ای که در ماه های آینده توسط مایکروسافت انجام خواهد شد تنظیمات سرور LDAP به گونه ای تغییر خواهد یافت که Simple Authentication و Security Layer (SASL) bind که درخواست signing در آنها وجود ندارد و یا simple bind هایی که به صورت clear text اتجام می شوند و از certificate ها جهت رمزگذاری نمودن ارتباط استفاده نمی شود تماماً Reject شوند. از این رو بسیاری از Application های مورد استفاده در سازمانها که بدلایلی از قبیل قدیمی بودن یا عدم پشتیبانی از مفاهیم صدور ticket در Kerberos و یا سهولت develop و رفع اشکال از simple authentication استفاده می کنند، پس از این به روز رسانی قادر به ارتباط با اکتیودایرکتوری نخواهند بود و ارتباطات آنها Reject خواهد شد. مایکروسافت قویاً توصیه نموده که تا تاریخ مارچ 2020 و زمان انتشار این به روز رسانی نسبت به تست و بررسی و اعمال تغییرات در ساختار تحت مدیریت خود اقدام نمائیم.

Binding از دید برنامه نویسی

در برنامه نویسی application ها، تابعی بنام ldap_connect وظیفه برقرار نمودن ارتباط با LDAP را بر عهده دارد. بعنوان مثال در C++ با دستور WINLDAPAPI ULONG LDAPAPI ldap_connect(…) این ارتباط برقرار می شود. توسط توابعی که همراه با این تابع فراخوانی میشوند و پارامترهای همراه آنها می توان نوع ارتباط LDAP را تعیین نمود (به چه دومین ای، یا چه لیستی از hostها و روی چه پورت هایی، چه مدت زمانی برای timeout و …). اگرچه یک کلاینت برای ارتباط با LDAP، اجباری برای فراخوانی این تابع ندارد ولی اینکار یک عملیات خوب برنامه نویسی است که می تواند در موقع develop شدن برنامه ها در آنها گنجانده شود. اگر تابع ldap_connect موفق به برقراری ارتباط شود (LDAP_SUCCESS را درپاسخ برگرداند)، کلاینت بعنوان یک anonymous user به سرور LDAP متصل می گردد و تا زمانیکه یک تابع binding فراخوانی نشده anonymous باقی می ماند.

Binding مرحله ای است که LDAP server در آن اجازه انتقال اطلاعات authentication را به کلاینت داده و سپس با استفاده از آن اطلاعات، کلاینت را احراز هویت می نماید و در صورتیکه این پروسه موفقیت آمیز باشد، اجازه دسترسی به سرور را بر اساس privilege های کلاینت صادر می نماید.

تا اینجا متوجه شدیم که ابتدا اتصال به اکتیو دایرکتوری انجام می شود و سپس binding برای احراز هویت شدن صورت می گیرد. این موارد را در کنسول ldp.exe می توانید مشاهده کنید. برای اتصال فقط به نام سرور مقصد و پورت نیاز دارید سپس برای binding می بایست اطلاعات بیشتری مانند دومین مقصد، نام کاربری و رمز عبور و نوع binding و … را مشخص کنید تا سرور اکانت مد نظر شما را authenticate کند.

برای انجام عمل binding توابع مختلفی وجود دارند. در صورتیکه از تابع ldap_connect برای اتصال به سرور LDAP استفاده نشده باشد مرحله binding خودش وظیفه این تابع را نیز انجام خواهد داد. در مراحل انجام binding، پس از انجام وظیفه دو تابع ldap_init یا (ldap_sslinit در صورتیکه پارامتر secure مورد نیاز باشد) و ldap_connect ارتباط برقرار می گردد. سپس در صورتیکه SASL binding مدنظر است عملیات encryption (اگر از TLS/SSL استفاده می کنیم) و integrity verification (پروسه حصول اطمینان از اینکه پیغام در طول مسیر دستکاری نشده و تغییری نکرده است) انجام خواهد شد.

یک سری توابع نیز در کتابخانه LDAP سمت کلاینت وجود دارند که در صورت قطع ارتباط در راستای اتصال دوباره تلاش خواهند نمود و اگر سرور در بازه زمانی timeout تعریف شده پاسخگو نباشد (پیش فرض 2 دقیقه) سرور را ping خواهد نمود تا زمانی که پاسخ مناسبی از ping دریافت نموده و دوباره برای برقرای ارتباط تلاش کند.

در کل چهار تابع وجود دارد که کلاینت توسط آنها درخواست ارتباط و احرازهویت خود را از طریق آنها به سرور ارسال می کند. دو تا از این توابع synchronous دو دو تا asynchronous هستند. دو تابع ldap_bind_s و ldap_simple_bind_s به صورت همگام و ldap_simple_bind و ldap_bind ناهمگام هستند. از بین این 4 تابع دو تابع ldap_simple_bind و ldap_simple_bind_s نام کاربری و رمزعبور را در شبکه به صورت رمزنگاری نشده و plain text ارسال می کنند و قابلیت شنود در بین راه باعث نا امن بودن این ارتباط است. مگر اینکه Session ای که برقرار می گردد توسط TLS/SSL امن شده باشد که این مورد را در بخش های بعدی بررسی می نمائیم. دو تابع دیگر به نام های ldap_bind و ldap_bind_s که کلمه simple در آنها وجود ندارد اشاره به این مطلب دارد که credential کلاینت به صورت plain text ارسال نمی شود. نوع credential استفاده شده در این نوع binding ها بستگی به authentication method ای دارد که بین کلاینت و سرور توافق شده است و هر دو از آن پشتیبانی می کنند. بعنوان مثال بین کلاینت های ویندوزی و سرور اکتیو دایرکتوری که هر دو توسط شرکت مایکروسافت Develop شده اند مکانیزم احراز هویت کربروس است مگر اینکه در مواقعی خاص از NTLM استفاده شود. در هر صورت هر دو این مکانیزمها روش خاص خود را برای ارسال credential دارند که از قبل بر روی آن توافق شده است.

توسط تابع ldap_init سه عملیات authentication (شناسایی هویت کلاینت و سرور)، Message integrity (پیغام در طول مسیر دچار تغییر یا دستکاری نشده باشد) و privacy (پیغام توسط فرد بدون مجوز قابل خواندن نباشد) را می توان پیاده سازی نمود. پروتکل SASL authentication روشی برای افزودن قابلیت پشتیبانی از احرازهویت در پروتکل های connection-based است (روشهای connection-less نیز برای برقرای ارتباط با ldap وجود دارند که بجای tcp از udp بهره می برند اما SASL authentication مربوط به آن روشها نیست). یکی از مزایای استفاده از SASL عدم نیاز آن به certificate است. در SASL پس از اینکه session را برقرار نمودید (توسط تابع ldap_init)، توسط تابع ldap_set_option می توانید کلاینت را authenticate نموده، پیغام ها را sign کرده و آنها را توسط option هایی که در SASL پشتیبانی می شود و تابع در اختیارتان می گذارد رمزنگاری نمائید. برقراری یک ارتباط امن از طریق فراخوانی تابع ldap_set_option طبق روال کلی زیر صورت می گیرد: (این انواع را در جدول صفحه 4 هم مشاهده می کنیم)

  • تابع ldap_bind_s فراخوانی می شود و option ای بنام ldap_auth_negotiate به آن پاس داده می شود. در این حالت بین NTLM و kerberos توافق انجام می شود و در هر صورت احرازهویت کلاینت به صورت ایمن صورت می گیرد ولی باقی پیغام ها همچنان به صورت plain text منتقل می شوند.
  • توسط option دیگری بنام ldap_opt_sign پیغام ها sign می شوند و اگر در طول مسیر تغییری در آنها ایجاد شده باشد، در سمت مقصد شناسایی خواهد شد ولی هنوز هم پیغام ها به صورت plain text در حال ارسال هستند.
  • برای حفاظت از privacy پیغام ها، option دیگری بنام ldap_opt_encrypt مورد استفاده قرار می گیرد که باعث رمزنگاری شدن تمامی پیغامهای ارسالی خواهد بود.

راهکارها:

  • تغییر تنظیمات به SASL authentication

اصولی ترین ولی پرهزینه ترین روش این است که ساختار دامین خود را بررسی و لیستی از تمامی موجودیت هایی که از طریق simple authentication احراز هویت می شوند تهیه نموده و آنها را طوری تغییر دهیم که از این پس احرازهویت را از طریق SASL Authentication را انجام دهند.

شناسایی برنامه ها و کلاینت هایی که ارتباط نا ایمن برقرار می کنند
ساده ترین راهی که برای بدست آوردن این لیست وجود دارد از طریق Event هایی است که در هر 24 ساعت توسط اکتیو دایرکتوری با شماره های 2886 و 2887 ایجاد شده و در بین لاگ های DC ذخیره می شوند. به صورت پیش فرض این event شامل تعداد simple authentication ها و SASL authentication های بدون نیاز به signing است که در طی 24 ساعت اخیر توسط اکتیودایرکتوری پاسخ داده شده است. همانطور که در تصویر زیر مشاهده می کنید این event هر 24 ساعت یکبار ایجاد می شود و تعداد bind ها را در دو دسته نشان می دهند (درون کادر قرمز رنگ): دسته اول تعداد Simple bind های انجام شده بدون استفاده از SSL/TLS و دسته دوم تعداد SASL bind های انجام شده بدون signing. این دو دسته دقیقاً هدف مایکروسافت در به روزرسانی مذکور می باشند.

موضوع دیگری که از تصویر فوق استنباط می شود این است که اسامی موجودیت هایی که این نوع bind ها را انجام می دهند را شامل نمی شود و صرفاً تعداد آنها بیان شده است. این به این دلیل است که اکتیو دایرکتوری به صورت پیش فرض فقط event های critical و error را در directory service log ذخیره می نماید. برای ذخیره سازی انواع دیگر لاگ ها که منجر به بدست آوردن لیست موجودیت هایی که simple bind انجام می دهند خواهد شد، می بایست logging level را توسط ویرایش رجیستری افزایش دهیم. با افزایش مقدار LDAP Interface events از صفر به 2 این عمل انجام خواهد شد و کافیست دستور زیر را اجرا نمائیم:

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

پس از اجرای این دستور و افزایش logging level دومین کنترلرها، به ازای هرSASL bind” بدون “signing یا simple bind” بدون ”SSL/TLS شروع به لاگ نمودن event هایی با شناسه 2889 خواهند نمود. همانطور که تصویر زیر نشان می دهد نام و IP آدرس کلاینت ای که پس از این آپدیت دچار مشکل خواهد شد در این لاگ قابل مشاهده است. بهتر است پس از بدست آوردن لیست و رفع bind های ناایمن، وضعیت logging level را به حالت قبل بازگردانیم. برای این کار کافیست بار دیگر دستور فوق را اجرا نموده و فقط عدد آخر را به صفر تغییر دهیم.

در صورتیکه تعداد DC ها در ساختار زیاد باشد بررسی یک به یک این لاگ ها به صورت دستی از منطق به دور است. بدین منظور Script ای بنام Query-InsecureLDAPBinds.ps1 به ضمیمه این مستند ارسال می گردد که با کمک آن می توان لیست تمامی event ID های 2889 را در هر DC تهیه نمود. تصویر زیر نشان دهنده نوع اجرای این Script بوده و خروجی در یک فایل اکسل در مسیری که اسکریپت در آن قراردارد ایجاد خواهد شد.

اعمال تنظیمات برای الزام LDAP server signing

برای الزام LDAP server signing در ارتباط کلاینت ها با اکتیو دایرکتوری بر روی DC در کنسول GPMC.MSC بر روی default domain policy گزینه edit را انتخاب می کنیم. سپس در computer configuration> policies> windows settings> security settings> local policies> security options برای Domain controller: LDAP server signing requirements در برگه security policy settings گزینه define this policy settings را در حالت فعال قرار داده و require signing را از لیست انتخاب می نمائیم. حالت پیش فرض این تنظیم معادل گزینه none است و به این معناست که برای انجام عمل bind نیازی به signing وجود ندارد ولی اگر کلاینتی درخواست data signing داشته باشد سرور آن را پشتیبانی خواهد کرد. در صورتی که بر روی گزینه require signing تنظیم شود بدین معناست که اگر از TLS/SSL استفاده نشده باشد گزینه های LDAP data signing می بایست بین سرور و کلاینت توافق شود.
توجه کنید که ارتباط خود ویندوزهای کلاینتی با DC به صورت Simple bind نیست و این تنظیم بر روی آنها تاثیری نخواهد داشت.

پس از اعمال تنظیمات بر روی DC ها نیاز داریم که کلاینت ها نیز ارتباط خود با اکتیودایرکتوری را همراه با signing انجام دهند تا ارتباطشان reject نشود. بر همین اساس پالیسی دیگری در همان مسیر مذکور با نام Network security: LDAP client signing requirements وجود دارد که نقش آن تعیین سطح Data signing در درخواست های LDAP bind است که به اکتیو دایرکتوری ارسال می کنند. پس از فعال سازی گزینه define this policy settings گزینه های پیش رو none، negotiate signing و require signing هستند که پیش فرض بر روی negotiate signing قرار دارد. زمانیکه بر روی none تنظیم شده باشد درخواست LDAP bind با ویژگی هایی که caller (مانند برنامه ای که با اکتیو ارتباط برقرار می کند) مشخص کرده است صادر می شود. عملکرد گزینه negotiate signing نیز به این ترتیب است که اگر از TLS/SSL در ارتباط استفاده نشود، درخواست های LDAP bind با در نظر گرفتن ویژگی هایی که caller مشخص نموده با گزینه های LDAP data signing آغاز خواهد شد. ولی اگر از TLS/SSL استفاده شده باشد درخواست LDAP bind فقط با ویژگی هایی که caller مشخص نموده صورت می گیرد. گزینه نهایی یا require signing نیز همان negotiate است با این تفاوت که اگر در سمت سرور require signing انتخاب نشده باشد به caller پیغام خطا ارسال خواهد شد. نکته مهم در این تنظیمات این است که اگر در سمت سرور require signing را فعال کرده باشیم در سمت کلاینت نیز این تنظیم می بایست انجام شود، در غیر این صورت ارتباط کلاینت با سرور قطع خواهد شد. برای اعمال این تنظیمات هم از طریق رجیستری و هم group policy می توان اقدام نمود. در این سناریو ما هم سرور و هم کلاینت را از طریق تنظیمات GPO بر روی require signing قرار می دهیم.

نکته مهمی که در اعمال این تنظیم می بایست مورد توجه قرار بگیرد این است که در صورتیکه require signing فعال شود و کلاینت هایی در این بین وجود داشته باشند که خاموش باشند و یا ارتباط شبکه آنها قطع باشد و یا به هر نحوی پالیسی را دریافت نکنند، پس از اتصال مجدد به شبکه و تلاش برای اتصال به اکتیو دایرکتوری نماید عملیات bind صورت نخواهد گرفت.

  • LDAPS/StartTLS

در صورتیکه اجرای روش اول بدلیل هزینه بالا و یا عدم پشتیبانی Application ها از SASL authentication، برای ما مقدور نمی باشد گزینه دیگری بنام LDAPS پیش روی ما قرار دارد. در این مکانیزم از SSL یا TLS برای ایمن سازی ارتباطات simple authentication بین کلاینت و سرور استفاده می گردد. اکتیو دایرکتوری نیازی به ارتباطاتی که از طریق SSL/TLS رمزگذاری شده باشند ندارد ولی آن را پشتیبانی می نماید تا simple bind ها را حتی الامکان رمزگذاری و ایمن نمائیم. دو شیوه برای این کار می توان بکار برد:

  • استفاده از LDAPS بر روی پورت 636 (روی DC) یا پورت 3269 (روی GC) که در این شیوه ارتباط را از طریق certificate ایمن می نمائیم و در مورد SSL/TLS باید قبل از مبادله هر اطلاعاتی با LDAP مذاکره و توافق صورت بگیرد.
  • استفاده LDAP از StartTLS روی پورت 389 (روی DC) یا 3268 (روی GC) که در آن عملیات StartTLS به منظور برقراری ارتباطات امن مورد استفاده قرار می گیرد. موضوعی که در این شیوه اهمیت دارد این است که از پشتیبانی کلاینت برای عملیات StartTLS اطمینان حاصل کنیم. از آنجا که پشتیبانی برنامه ها و کلاینت ها از این روش محدود می باشد در پروسه راه اندازی ما شیوه اول و سرویسدهی روی پورت 636 را انتخاب می نمائیم.

هر دو شیوه فوق نیاز به وجود یک certificate معتبر برای برقرای ارتباط دارند. توجه نمائید که اکتیو دایرکتوری برای مقاصد مختلفی پورتهای موجود در دو شیوه فوق را در دسترس قرار داده است. از این رو در انتخاب شیوه پیاده سازی و پورت مورد نظر می بایست دقت شود:

  • برای ارتباط با DC از طریق StartTLS پورت 389 روی DC
  • برای ارتباط با DC از طریق LDAPS پورت 636 روی DC
  • برای دسترسی به دومین های دیگر با استفاده از GC پورت 3268 روی GC
  • برای ارتباط StartTLS و پورت 3269 روی GC برای ارتباط LDAPS

پیاده سازی این روش طی سه فاز شناسایی و ترمیم و اعتبار سنجی صورت می گیرد:

در فاز شناسایی ابتدا می بایست ارتباطات نا ایمن ساختار خود را شناسایی نمائیم. برای شناسایی این ارتباطات همان روشی را که در راهکار 1 اعلام کردیم را بکار برده و از طریق لاگ های اکتیو دایرکتوری ارتباطات نا ایمن را لیست می کنیم.

در فاز ترمیم دو عملیات صورت می گیرد:

بخش اول از مرحله ترمیم:
برقراری ارتباط امن روی پورت 636

ارتباطات از طریق SSL یا TLS و نصب یک certificate صادر شده از CA داخلی سازمان یا CA خارجی ایمن می شوند. برخی application ها در پروسه اتصال به اکتیو دایرکتوری، نیاز به اعتبار سنجی این certificate و CA صادر کننده آن خواهند داشت. از این رو استفاده از یک certificate روی همه DC ها باعث سهولت تنظیمات و کاهش سربار مدیریتی خواهد شد. برخی از application ها فقط قابلیت تعریف یک LDAP سرور را درون خود دارند اگر چنین برنامه ای در ساختار خود دارید با استفاده از قراردادن load balancer در جلوی DCها می توانید بر این مشکل غلبه کنید.

نصب certificate

هیچ user interface ای برای اعمال تنظیمات LDAPS وجود ندارد و می بایست تنظیمات آن را به صورت دستی و با نصب certificate بر رویDC ها انجام داده و از این طریق به DC اجازه بدهیم به ارتباطات SSL گوش داده و به صورت اتوماتیک آن را، هم برای ترافیک LDAP و هم برای ترافیک Global Catalog قبول کند.
شرایطی که certificate باید داشته باشد:

  • Private key متناظر با Certificate باید در local computer store وجود داشته باشد و strong private key protection هم فعال نباشد.
  • Enhanced Key Usage extension باید شامل گزینه Server authentication با OID (1.3.6.1.5.5.7.3.1) باشد.
  • FQDN مروبط به DC باید یا در قسمت CN یا در SAN مربوط به Certificate اضافه شده باشد. ( به شکل DC01.domain.com)
  • CA ای که certificate را تولید می کند باید هم برای DC ها و هم کلاینت ها trusted باشد.
  • باید از CSP برای تولید کلید استفاده شود.

ایجاد request و نصب certificate:

برای درخواست یک Server Authentication certificate که مناسب استفاده در LDAPS است مراحل زیر را انجام دهید: متن زیر را در فایلی با پسوند .inf کپی نموده و فقط بخش subject را تغییر داده و FQDN مربوط به DC خود را وارد نمائید. در صورتیکه از این certificate می خواهید برای تمام DC ها استفاده کنید می توانید از Wildcard و یا subject alternative name در درخواست خود بهره ببرید.

; ----------------- request.inf ----------------- 
[Version]
Signature="$Windows NT$
[NewRequest]
Subject = "CN=" ; replace with the FQDN of the DC
KeySpec = 1
KeyLength = 1024
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
;-----------------------------------------------
  1. با اجرای دستور زیر در CMD فایل inf خود را به یک فایل req تبدیل نمائید.
    certreq -new request.inf request.req
  2. فایل req را در CA server، submit نمائید.
  3. Certificate ای را که توسط CA، Issue شده را باز نموده، copy to file را انتخاب کرده و سپس با پسوند cer ذخیره کنید. دقت کنید که با فرمت base64 ذخیره شده باشد.
  4. فایل cer را به DC منتقل نموده، در فولدری که فایل req قرار دارد کپی نمو.ده و با اجرای دستور زیر private key را به Certificate ای که توسط CA، Issue شده است لینک نمائید:
    certreq -accept certnew.cer

در نهایت بررسی نموده و مطمئن شوید که certificate در مسیر local computer\personal نصب شده است و server authentication نیز در بخش purpose آن مشاهده می شود.

نکته: می توانید بجای اینکه certificate صادر شده را در personal certificate store (local machine) اضافه کنید، در personal certificate store (service > ADDS) قرار دهید و در محتوای personal در local machine که برای AD Web Service استفاده می شود تغییراتی ایجاد نکنید. محتوای personal در service به محتوای personal در local machine اولویت دارد و بالاتر از آن انتخاب می شود. از این طریق با ایجاد یک wildcard certificate یا SAN-based certificate ای که “ldaps.domain.com” هم بعنوان alternative name در آن افزوده شده باشد می توانید آن را برای مقاصدی که فقط LDAPS از آن استفاده می کند بکار بگیرید.

بخش دوم از مرحله ترمیم:
جلوگیری از ارتباطات نا امن روی پورت 368 برای DC و3268 برای GC

امنیت سرور AD با reject نمودن SASL LDAP bind هایی که درخواست signing صادر نمی کنند و LDAP Simple bind هایی که بدون SSL/TLS انجام می شوند به طور چشمگیری افزایش می یابد. زمانیکه نیاز به LDAP signing در ارتباط با دومین کنترلرها وجود دارد گزینه های data-signing می بایست بین کلاینت و سرور توافق شود مگر اینکه TLS/SSL مورد استفاده قرار گرفته باشد که در این صورت تاثیری بر روی Simple bind هایی که از طریق SSL و پورت 636 انجام می شود نخواهد داشت، فقط Simple bind های بدون SSL روی پورت 389 reject خواهند شد. به این منظور همانطور که در راهکار 1 اشاره گردید می بایست نسبت به فعالسازی Require LDAP signing از طریق GPO اقدام نمود.

مرحله اعتبار سنجی:

اطمینان از صحت عملکرد

در نهایت پس از تمامی اعمال فوق می بایست از دو مورد اطمینان حاصل نمود:

  1. LDAPS همانطور که انتظار می رود در حال فعالیت می باشد
  2. LDAP bind های نا ایمن reject می شوند

برای بررسی مورد اول، از ldp.exe استفاده می نمائیم (بر روی کلاینت RSAT را دانلود و نصب نموده سپس در run عبارت ldp.exe را تایپ نموده اجرا می کنیم).
کنسول ldp را باز نموده و به ldaps.domain.com بر روی پورت 636 و انتخاب SSL متصل می شویم

چهار گزینه برای binding پیش روی ماست که دو گزینه اول از کربروس استفاده می کنند، گزینه سوم simple bind است و گزینه چهارم نیز به ما امکان انتخاب مکانیزم authenticate را میدهد و زمانی که پس از انتخاب آن بر روی advance کلیک کنیم موارد موجود را مشاهده می کنیم. ما برای بررسی اینکه simple bind دیگر کار نمی کند نیز به ترتیب شکل زیر عمل می کنیم:

توجه نمائید که simple bind بر روی LDAPS و پورت 636 همچنان کار می کند اما تهدیدات امنیتی گذشته را نخواهد داشت زیرا توسط SSL/TLS کلیه ارتباط در حال رمزنگاری شدن می باشد ولی simple bind بر روی LDAP و پورت 389 یا 3289 از کار افتاده است.

نکته: برای حصول اطمینان از اینکه تمام DC ها از یک certificate برای LDAPS در حال استفاده هستند می توانید از تابع پاورشلی که به همین منظور نوشته شده با نام Get-ADDomainControllerCertificate استفاده کنید. ( این فایل پاورشل با نام LDAPS-cert.ps1 به ضمیمه مستند ارائه گردیده است)

ادامه با روش ناایمن فعلی

در صورتیکه application هایی داریم که امکان تغییر نوع درخواست های binding آنها وجود ندارد و یا SSL را پشتیبانی نمی کنند، راه دیگری نیز وجود دارد که باعث می شود تغییراتی را که مایکروسافت قرار است در آپدیت مارچ 2020 اعمال نماید را بی اثر کنیم. برای اینکار کافیست بر روی DC در کنسول GPMC.MSC بر روی default domain policy گزینه edit را انتخاب کنیم. سپس در computer configuration> policies> windows settings> security settings> local policies> security options برای Domain controller: LDAP server signing requirements در برگه security policy settings گزینه define this policy settings را در حالت فعال قرار داده و none را از لیست انتخاب می نمائیم. حالت پیش فرض این تنظیم معادل گزینه none است (درحالت فعلی و قبل از نصب آپدیت) و به این معناست که برای انجام عمل bind نیازی به signing وجود ندارد ولی اگر کلاینتی درخواست data signing داشته باشد سرور آن را پشتیبانی خواهد کرد.

البته این روش در صورتی قابل انجام است که مایکروسافت آپدیت را به گونه ای ارائه نماید که امکان تغییر از طریق GPO را حذف ننماید. با اینکه احتمال این موضوع اندک می باشد منتها بدلیل عدم وجود مستندی در این رابطه تا زمان اعلام رسمی، نظر قطعی در این مورد نمی توان ارائه نمود.

تهیه کنندگان: مهندس قاسم شمس G.shams@outlook.com – مهندس مهدی تهرانی Tehrani.mahdi@outlook.com

دانلود فایل مورد نیاز: لینک دانلود

مراجع:

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-update-now/ba-p/921536

https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

100%
Awesome
  • Design
3 دیدگاه
  1. علی رضا says

    تشکر

  2. مهدی پور says

    بسیار عالی

  3. شایان صمدپور says

    دمتون گرم خیلی کامله فقط یه سوال : سرتیفیکیت رو حتما باید CA داخلی داشته باشیم براش؟

دیدگاه

آدرس ایمیل شما منتشر نخواهد شد.