31-05-2021, 05:29 PM
مکانیزم احراز هویت ماشین ها و کاربران در اکتیودایرکتوری تا حدود زیادی شبیه به هم و یکسان است. کلاینت ها از طریق DNS سرور و فرآیند DCLocator متوجه می شود که که سرور RODC ای که در همان سایت وجود دارد عملیات احراز هویت را باید اتجام دهد و در اصطلاح فنی تر DCLocator تشخیص می دهد که RODC وظیفه Authoritative Authentication را بر عهده دارد. همانطور که در تصویر زیر مشاهده می کنید در اولین گام کلاینت درخواست احراز هویت خودش را به سمت سرور RODC ارسال می کند.
در گام دوم سرور RODC به پایگاه داده خود که فایلی به نام NTDS.DIT است نگاه می کند تا ببیند آیا نام کاربری و رمز عبور کلاینت مورد نظر را بصورت ذخیره شده در پایگاه داده موجود دارد یا خیر ؟ با توجه به اینکه اطلاعات احراز هویت این کلاینت در پایگاه داده فعلی RODC قرار ندارد بنابراین RODC گام سوم را شروع می کند. در مرحله سوم RODC درخواست احراز هویت کلاین را از طریق لینک شبکه WAN به سمت سرور DC اصلی هدایت می کند و طبیعتا می داند که در آنجا باید اطلاعات در پایگاه داده وجود داشته باشد.
در گام چهارم RWDC ما از پایگاه داده خود اطلاعات مربوط به احراز هویت را بررسی می کند و با توجه به اینکه در این قسمت اطلاعات در پایگاه داده وجود دارد در گام پنجم پاسخ را به سمت سرور RODC هدایت می کند که حاکی از صحت اطلاعات درخواستی احراز هویت می باشد. در گام ششم که مرحله بعدی است درخواست کلاینت سرویس دهی شده است و کلاینت می تواند در فایل سرور احراز هویت و Login کند اما طبیعتا از این موضوع خوشحال نیست که چرا خودش احراز هویت را انجام نداده است .
برای اینکه مجددا شرمنده کلاینت ها نشود اینبار اطلاعات احراز هویتی کلاینت که کامپیوتر یا کاربر است در پایگاه داده RODC بصورت Cache شده نگهداری می شود تا در درخواست های احراز هویت بعدی کلاینت به جای سئوال کردن از سرور RWDC از اطلاعات خودش برای احراز هویت استفاده کند. برای اینکار ابتدا RWDC بررسی می کند که آیا Password Replication Policy خودش قابلیت Cache کردن پسوردها به RODC را داده است یا خیر ، اگر این اجازه داده شده بود ، اطلاعات احراز هویت آن کاربر در پایگاه داده RODC از این به بعد وجود خواهد داشت.
در گام دوم سرور RODC به پایگاه داده خود که فایلی به نام NTDS.DIT است نگاه می کند تا ببیند آیا نام کاربری و رمز عبور کلاینت مورد نظر را بصورت ذخیره شده در پایگاه داده موجود دارد یا خیر ؟ با توجه به اینکه اطلاعات احراز هویت این کلاینت در پایگاه داده فعلی RODC قرار ندارد بنابراین RODC گام سوم را شروع می کند. در مرحله سوم RODC درخواست احراز هویت کلاین را از طریق لینک شبکه WAN به سمت سرور DC اصلی هدایت می کند و طبیعتا می داند که در آنجا باید اطلاعات در پایگاه داده وجود داشته باشد.
در گام چهارم RWDC ما از پایگاه داده خود اطلاعات مربوط به احراز هویت را بررسی می کند و با توجه به اینکه در این قسمت اطلاعات در پایگاه داده وجود دارد در گام پنجم پاسخ را به سمت سرور RODC هدایت می کند که حاکی از صحت اطلاعات درخواستی احراز هویت می باشد. در گام ششم که مرحله بعدی است درخواست کلاینت سرویس دهی شده است و کلاینت می تواند در فایل سرور احراز هویت و Login کند اما طبیعتا از این موضوع خوشحال نیست که چرا خودش احراز هویت را انجام نداده است .
برای اینکه مجددا شرمنده کلاینت ها نشود اینبار اطلاعات احراز هویتی کلاینت که کامپیوتر یا کاربر است در پایگاه داده RODC بصورت Cache شده نگهداری می شود تا در درخواست های احراز هویت بعدی کلاینت به جای سئوال کردن از سرور RWDC از اطلاعات خودش برای احراز هویت استفاده کند. برای اینکار ابتدا RWDC بررسی می کند که آیا Password Replication Policy خودش قابلیت Cache کردن پسوردها به RODC را داده است یا خیر ، اگر این اجازه داده شده بود ، اطلاعات احراز هویت آن کاربر در پایگاه داده RODC از این به بعد وجود خواهد داشت.