در توسینسو تدریس کنید

و

با دانش خود درآمد کسب کنید

مکانیزم کاری RODC به زبان ساده – قسمت دوم

در مقاله قبلی در خصوص نحوه ساده ترین احراز هویت در ساختار RODC صحبت کردیم و متوجه شدید که به صورت کلی RODC چگونه کار می کند و پسوردهای ما چگونه ذخیره می شوند. اما آیا همه چیز در شبکه دامین و اکتیودایرکتوری برای احراز هویت همین پسورد است ؟ در پاسخ به شما باید بگوییم خیر ، پسورد قسمتی از مسئله است و مسئله بعدی در احراز هویت و دسترسی به سرویس های ما مجوز دسترسی یا Ticket احراز هویت و دسترسی است. همانطور که قبلا هم در ITPRO گفته ایم ، پروتکل اصلی احراز هویت در اکتیودایرکتوری Kerberos است ، هرگاه شما بخواهید به یک سرویس در شبکه اکتیودایرکتوری متصل شوید و از آن استفاده کنید بایستی برای خودتان یک Ticket دسترسی داشته باشید. به این بلیط یا Ticket دسترسی به سرویس ها Ticket Granting Ticket یا TGT گفته می شود. این Ticket توسط یک سرویس به نام Key Distribution Center یا KDC ایجاد و صادر می شود که همیشه سرور Domain Controller ما در شبکه نقش KDC را بر عهده دارد و مدیریت Ticket های دسترسی هم بر عهده همین DC است.

ما فقط باید آنها را درخواست بدهیم ، در این مثال ما یک Ticket دسترسی را باید درخواست بدهیم که بتوانیم از سرویس File Server موجود استفاده کنیم. ما برای درخواست سرویس از فایل سرور نیاز به یک Ticket سرویس داریم ، زمانیکه این Service Ticket را دریافت کردیم می توانیم به سمت فایل سرور برویم و از آن درخواست سرویس کنیم. فایل سرور یا هر سرویسی که قرار است به ما سرویس بدهد با توجه به Ticket ای که به آن ارائه می کنیم به ما اجازه می دهد که به منابع دسترسی پیدا کنیم و یا اصلا اجازه دسترسی به ما نخواهد داد. اما این فرآیند زمانی است که شما در شبکه RWDC دارید ، زمانیکه شما در شبکه از RODC استفاده می کنید قضیه کمی متفاوت تر خواهد بود ، به تصویر زیر دقت کنید ، مراحل اضافه ای که باید در RODC برای انجام همین کار طی شود را مشاهده می کنید :

RODC چگونه کار می کند RODC چیست

تصور کنید که یک کاربر قرار است تغییراتی بر روی یک فایل متنی که درون فایل سرور قرار گرفته است ایجاد کند. برای اینکه بتواند اینکار را انجام بدهد بایستی یک Ticket سرویس برای فایل سرور تهیه کند. در گام اول کاربر درخواست Ticket خودش را به سمت RODC ارسال می کند. با توجه به مثال بالا و مقاله قبلی فرض می کنیم که در گام دوم هنوز RODC کاربر را نمی شناسد و باید اون را احراز هویت کند ، با توجه به اینکه RODC تیکت کاربر را ندارد که بخواهد آن را احراز هویت کند در گام سوم درخواست Ticket را به سمت RWDC ارسال می کند. RWDC تیکت مورد نظر را در گام چهارم بررسی می کند و در مرحله پنجم با توجه به صحت داشتن اطلاعات کاربر Ticket دسترسی را صادر و به سمت RODC ارسال می کند ، اگر یک DC معمولی در اینجا داشتیم ، اینجا همان زمانی بود که کاربر Ticket را دریافت می کرد اما در اینجا ما یک RODC داریم. در اینجا RODC متوجه می شود که یک Ticket دسترسی به صورت موفقیت آمیزی ایجاد شده است و پسورد کاربر مورد نظر نیز در پایگاه داده RODC وجود دارد حالا RODC یک حقه کوچک را بکار می برد. در مرحله ششم RODC به کاربر مورد نظر اعلام می کند که Ticket درخواستی شما نامعتبر است و اشتباه وارد شده است.

در همین حین کاربر همه درخواست های قبلی خودش را کنار می گذارد و همه موارد را از ابتدا شروع می کند که این مرحله هفتم از کار می شود. اینبار در مرحله هشتم کاربر مجددا درخواست Ticket می دهد اما اینبار RODC او را احراز هویت می کند و به وی Ticket دسترسی را ارائه می کند. با توجه به اینکه کاربر همچنان درخواست دسترسی به فایل سرور را دارد مجددا یک Ticket جدید ایجاد می کند و آن را به سمت RODC در مرحله نهم می فرستد. اینبار RODC توانایی خواندن Ticket احراز هویت کاربر مورد نظر را دارد و به سادگی توسط RODC احراز هویت می شود و Ticket دریافت می کند. البته توجه کنید که اینبار RODC محاسبات جدید Ticket را انجام می دهد و Ticket ای ویژه RODC تهیه و توزیع می کند که در مرحله دهم بصورت کامل قابل مشاهده است. حالا کلاینت Service Ticket خودش برای احراز هویت و استفاده از خدمات فایل سرور را دارد. خیلی راحت Ticket را بر می دارد و به سمت فایل سرور در مرحله یازدهم ارسال می کند و در نهایت دسترسی های لازم را دریافت می کند.

دچار ابهام شدید ؟ اشکالی ندارد این امر کاملا طبیعی است ، کمی صبر کنید و فکر کنید و مجددا مقالات را ابتدا مرور کنید ، سعی کنید این مقالات را با پارک ارم مقایسه کنید ، آنجا هم شما باید ابتدا بلیط خریداری کنید و بلیط ها را به مسئول دستگاه بدهید و از خدمات استفاده کنید. هر چیزی را می توانید با اینگونه مثال ها بهتر درک کنید. اما ای تقریبا کلیات روشی است که احراز هویت در RODC انجام می شود. البته تکنیک هایی وجود دارد که بتوانید برخی موارد احراز هویتی را به RODC بسپارید که از آن جمله می توان به Pre-Populate کردن آنها اشاره کنیم. به هر حال فراموش نکنید که RODC برای شعبات و نمایندگی های کوچکی که شما ریسک امنیتی نمی خواهید داشته باشید و از طرفی تیم پشتیبانی قوی ندارد یا اصلا هیچکس به این عنوان در محل حضور ندارد و یا در جاهایی که تعداد کلاینت ها بسیار کم است استفاده می کنید. امیدوارم مورد توجه شما قرار گرفته باشد. ITPRO باشید

نویسنده : محمد نصیری

منبع : جزیره سرویس های شبکه مایکروسافت وب سایت توسینسو

هرگونه نشر و کپی برداری بدون ذکر منبع و نام نویسنده دارای اشکال اخلاقی می باشد

#read_only_domain_controller_چیست #rodc_چیست #پروتکل_های_احراز_هویت #پروتکل_احراز_هویت_Kerberos #تفاوت_rodc_و_rwdc #ویژگیهای_rodc_و_additional_dc #ticket_granting_ticket_چیست #عدم_احراز_هویت_در_rodc #مکانیزم_عملکرد_پروتکل_kerberos #مکانیزم_کاری_rodc
عنوان
1 مکانیزم کاری RODC به زبان ساده – قسمت اول رایگان
2 مکانیزم کاری RODC به زبان ساده – قسمت دوم رایگان
زمان و قیمت کل 0″ 0
6 نظر
Mehdi Malmir

بسیار زیبا و قابل فهم بود.مرسی

بهزاد رحمانی

با سلام وتشکر از مقاله خوبتون

اعتبار یک TGT چند دقیقه است؟یعنی مثلا سرور فایل به یک TGT تا چه مدت اعتبار میدهد؟

محمد نصیری

بصورت پیشفرض در Default Domain Policy یک TGT دقیقا 600 دقیقه معادل 10 ساعت اعتبار داره و بعدش باطل میشه ، این موضوع ارتباطی به نوع سرویس نداره ، یک جور پایان دادن به Session هست برای جلوگیری از کرک شدن و بالا بردن امنیت Ticket ، شما می تونید این مقدار رو عوض کنید.

Ehsan Mousaei

سلام

توی RODC میتونیم تعیین کنیم کاربر به سرویس هایی ک ما میخوایم دسترسی داشته باشه ؟

محمد نصیری

بله هیچ تفاوتی در سطوح دسترسی نیست ... کاملا بعد از احراز هویت میشه کارهای متداول رو انجام داد

کامبیز ذوقی

من عادت دارم مقاله های خوب رو چند بار بخونم

مهندس نصیری من اینطوری متوجه شدم:

اگر کاربر قرار باشه احراز هویت بشه برای بار اول RODC چون در Cache خودش اطلاعاتی ندارد از RWDC اطلاعات را میگیرد و به کاربر میدهد تا کاربر بتواند احراز هویت کند.

حالا برای استفاده از سرویس ها کاربر باید درخواست Ticket بدهد که چون RODC تیکتی ندارد از DC اصلی میپرسد و یکبار به کاربر میگوید که اطلاعات یا درخواست شما اشتباهه و کاربر دوباره درخواست میده و این بار با توجه به تیکتی که RODC از DC اصلی گرفته و ذخیره کرده جواب کاربر را میدهد و برای او تیکت ارسال میکند درسته؟

آیا کاربر برای احراز هویت هم نیاز به تیکت داره یا خیر؟ یا تیکت فقط برای سرویس هاست؟

حالا اگر درست متوجه شدم بفرمائید وگرنه واضح تر مراحل رو میفرمائید.

عمر TGT رو فرمودید 10 ساعته بعد از این مدت دوباره برای استفاده از سرویس ها باید کاربر دوباره درخواست بده تا بتونه دسترسی پیدا کنه؟

نظر شما
برای ارسال نظر باید وارد شوید.
از سرتاسر توسینسو
تنظیمات حریم خصوصی
تائید صرفنظر
×

تو می تونی بهترین نتیجه رو تضمینی با بهترین های ایران بدست بیاری ، پس مقایسه کن و بعد خرید کن : فقط توی جشنواره پاییزه می تونی امروز ارزونتر از فردا خرید کنی ....