درس ۵ از ۱۴

کاربر، Group و Computer Account

در این بخش می‌خواهیم کاربر، Group و Computer Account را به زبان ساده یاد بگیریم؛ به‌جای حفظ کردن چند اصطلاح، می‌بینیم هر بخش چه اثری در محیط Windows Server و Active Directory دارد، از کجا قابل مشاهده است و وقتی نتیجه غیرعادی بود چه چیزی را باید بررسی کرد در این درس موضوع را در چارچوب Windows Server و سرویس‌های سازمانی بررسی می‌کنیم؛ Server معمولاً به DNS، Time، Identity، Network و Storage وابسته است و تغییر در یک Role می‌تواند روی چند سرویس اثر بگذارد؛ هدف این است که پیش‌نیازها، وابستگی‌ها، روش بررسی سلامت و راه بازگشت را بشناسی و صرف موفق شدن یک Wizard را پایان کار ندانی

این درس برای مطالعه کامل نوشته شده است

با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست

کاربر هویت شخص یا سرویس است

در Active Directory یک کاربر Account می‌تواند نماینده یک انسان یا حساب اجرای سرویس باشد؛ حساب سرویس باید هدف مشخص، کمترین مجوز لازم و مدیریت رمز مناسب داشته باشد و نباید مثل حساب شخصی استفاده شود OU در Active Directory برای سازمان‌دهی Objectها و اعمال مدیریت و Group Policy استفاده می‌شود و با Security Group نقش یکسانی ندارد؛ طراحی OU باید بر نیاز مدیریتی و محدوده اعمال Policy تکیه کند، نه صرفاً تقلید از چارت سازمانی؛ جابه‌جایی Object بین OUها می‌تواند مجموعه Policyهای اعمال‌شده را تغییر دهد، بنابراین قبل از تغییر باید Scope و Linkهای GPO بررسی شوند نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که Windows Server باید بر اساس Role و نیاز سازمان آماده شود؛ نام Server، IP ثابت، DNS درست، Time، Update، Storage و Remote Management پیش‌نیازهایی هستند که قبل از اضافه کردن Roleهای حساس باید کنترل شوند؛ نصب Role بدون آماده‌سازی این پایه‌ها می‌تواند خطاهایی ایجاد کند که بعداً به اشتباه به خود Role نسبت داده شوند نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که در Active Directory، DNS بخشی جدایی‌ناپذیر از پیدا کردن سرویس‌هاست و زمان نیز برای Authentication اهمیت دارد؛ قبل از Promote کردن Server یا Join کردن Client، Name Resolution و IP Plan را تثبیت کن؛ بعد از تغییر، Event Log و ابزارهای سلامت AD باید بررسی شوند تا صرف موفق بودن Wizard به‌عنوان پایان کار در نظر گرفته نشود

Security Group برای تخصیص Permission مناسب است

Security Group مجموعه کاربران و رایانه‌ها برای دادن Permission یا Policy است؛ دسترسی را به Group بده و عضویت کاربر را مدیریت کن Permission مستقیم به تک‌تک کاربرها در مقیاس سازمانی نگهداری را سخت می‌کند OU در Active Directory برای سازمان‌دهی Objectها و اعمال مدیریت و Group Policy استفاده می‌شود و با Security Group نقش یکسانی ندارد؛ طراحی OU باید بر نیاز مدیریتی و محدوده اعمال Policy تکیه کند، نه صرفاً تقلید از چارت سازمانی؛ جابه‌جایی Object بین OUها می‌تواند مجموعه Policyهای اعمال‌شده را تغییر دهد، بنابراین قبل از تغییر باید Scope و Linkهای GPO بررسی شوند در File Server ویندوز، دسترسی کاربر می‌تواند هم‌زمان تحت تأثیر Share Permission و NTFS Permission باشد و برای تشخیص نتیجه باید هر دو لایه بررسی شوند؛ مدیریت دسترسی از طریق Security Group معمولاً قابل نگهداری‌تر از دادن Permission مستقیم به تعداد زیادی User است؛ Inheritance نیز تعیین می‌کند مجوزها چگونه به زیرپوشه‌ها برسند و تغییر بدون بررسی می‌تواند دسترسی‌های ناخواسته ایجاد کند؛ دسترسی مؤثر باید با یک حساب آزمایشی از دید کاربر هم تأیید شود

Computer Account هویت سیستم عضو Domain است

Domain یک محدوده مدیریتی و هویتی در Active Directory است که Objectها و Policyهای مشترک دارد؛ Client برای Join و Login باید DNS مناسب Domain را پیدا کند نام Domain را بدون طراحی و دلیل تغییر نده Computer Account هویت رایانه عضو Domain است و برای رابطه اعتماد بین Client و Domain استفاده می‌شود؛ خرابی این اعتماد می‌تواند Login یا دسترسی Domain را مختل کند Active Directory Domain Services یک Directory Service سلسله‌مراتبی برای نگهداری Objectهایی مانند User، Computer و Group و ارائه Authentication و Authorization در دامنه است؛ Domain Controller نسخه‌ای از Directory را نگه می‌دارد و سرویس‌هایی مانند DNS برای پیدا کردن سرویس‌های دامنه اهمیت زیادی دارند؛ هنگام عیب‌یابی باید Name Resolution، زمان سیستم، سلامت ارتباط با DC، وضعیت Replication و عضویت درست Computer در Domain کنار هم بررسی شوند OU در Active Directory برای سازمان‌دهی Objectها و اعمال مدیریت و Group Policy استفاده می‌شود و با Security Group نقش یکسانی ندارد؛ طراحی OU باید بر نیاز مدیریتی و محدوده اعمال Policy تکیه کند، نه صرفاً تقلید از چارت سازمانی؛ جابه‌جایی Object بین OUها می‌تواند مجموعه Policyهای اعمال‌شده را تغییر دهد، بنابراین قبل از تغییر باید Scope و Linkهای GPO بررسی شوند

Permission مستقیم به کاربران زیاد نگهداری را سخت می‌کند

دادن Permission مستقیم به ده‌ها کاربر نگهداری را سخت می‌کند؛ بهتر است کاربرها عضو Security Group شوند و مجوز به Group داده شود تا اضافه و حذف افراد بدون دستکاری ACLهای متعدد انجام شود OU در Active Directory برای سازمان‌دهی Objectها و اعمال مدیریت و Group Policy استفاده می‌شود و با Security Group نقش یکسانی ندارد؛ طراحی OU باید بر نیاز مدیریتی و محدوده اعمال Policy تکیه کند، نه صرفاً تقلید از چارت سازمانی؛ جابه‌جایی Object بین OUها می‌تواند مجموعه Policyهای اعمال‌شده را تغییر دهد، بنابراین قبل از تغییر باید Scope و Linkهای GPO بررسی شوند در File Server ویندوز، دسترسی کاربر می‌تواند هم‌زمان تحت تأثیر Share Permission و NTFS Permission باشد و برای تشخیص نتیجه باید هر دو لایه بررسی شوند؛ مدیریت دسترسی از طریق Security Group معمولاً قابل نگهداری‌تر از دادن Permission مستقیم به تعداد زیادی User است؛ Inheritance نیز تعیین می‌کند مجوزها چگونه به زیرپوشه‌ها برسند و تغییر بدون بررسی می‌تواند دسترسی‌های ناخواسته ایجاد کند؛ دسترسی مؤثر باید با یک حساب آزمایشی از دید کاربر هم تأیید شود

Disable حساب خروجی معمولاً از حذف فوری امن‌تر است

برای کاربری که شرکت را ترک کرده Disable کردن حساب معمولاً دسترسی را فوری قطع می‌کند ولی Object، عضویت Group و تاریخچه را برای بررسی و انتقال نگه می‌دارد؛ حذف را بعد از فرایند مشخص انجام بده OU در Active Directory برای سازمان‌دهی Objectها و اعمال مدیریت و Group Policy استفاده می‌شود و با Security Group نقش یکسانی ندارد؛ طراحی OU باید بر نیاز مدیریتی و محدوده اعمال Policy تکیه کند، نه صرفاً تقلید از چارت سازمانی؛ جابه‌جایی Object بین OUها می‌تواند مجموعه Policyهای اعمال‌شده را تغییر دهد، بنابراین قبل از تغییر باید Scope و Linkهای GPO بررسی شوند در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: Windows Server باید بر اساس Role و نیاز سازمان آماده شود؛ نام Server، IP ثابت، DNS درست، Time، Update، Storage و Remote Management پیش‌نیازهایی هستند که قبل از اضافه کردن Roleهای حساس باید کنترل شوند؛ نصب Role بدون آماده‌سازی این پایه‌ها می‌تواند خطاهایی ایجاد کند که بعداً به اشتباه به خود Role نسبت داده شوند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در Active Directory، DNS بخشی جدایی‌ناپذیر از پیدا کردن سرویس‌هاست و زمان نیز برای Authentication اهمیت دارد؛ قبل از Promote کردن Server یا Join کردن Client، Name Resolution و IP Plan را تثبیت کن؛ بعد از تغییر، Event Log و ابزارهای سلامت AD باید بررسی شوند تا صرف موفق بودن Wizard به‌عنوان پایان کار در نظر گرفته نشود

مثال محیط واقعی

فرض کن در محیط Windows Server و Active Directory مشکلی گزارش شده و احتمال می‌دهی به کاربر، Group و Computer Account مربوط باشد. قبل از تغییر، وضعیت فعلی را با Server Manager، ADUC، DNS Manager، gpresult و Event Viewer بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است

اشتباهات رایج

این اشتباه‌ها را تکرار نکن

  • در Active Directory یک کاربر Account می‌تواند نماینده یک انسان یا حساب اجرای سرویس باشد. حساب سرویس باید هدف مشخص، کمترین مجوز لازم و مدیریت رمز مناسب داشته باشد و نباید مثل حساب شخصی استفاده شود
  • تغییر دادن تنظیمات مرتبط با کاربر، Group و Computer Account قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
  • نتیجه‌گیری درباره کاربر، Group و Computer Account فقط از روی یک نشانه و بدون انجام تست نهایی
تمرین عملی

حالا خودت انجام بده

  1. در یک نمونه آزمایشی مرتبط با کاربر، Group و Computer Account، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
  2. با Server Manager، ADUC، DNS Manager، gpresult و Event Viewer وضعیت مرتبط با کاربر، Group و Computer Account را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
  3. یک خطای فرضی مرتبط با کاربر، Group و Computer Account بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند

نکته‌هایی که باید با خودت ببری

  • کاربر هویت شخص یا سرویس است
  • Security Group برای تخصیص Permission مناسب است
  • Computer Account هویت سیستم عضو Domain است
  • Permission مستقیم به کاربران زیاد نگهداری را سخت می‌کند
  • Disable حساب خروجی معمولاً از حذف فوری امن‌تر است
  • روی Domain Controller تغییر آزمایشی و بدون Backup انجام نده
خودسنجی

قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده

این نکته را با یک مثال توضیح بده: کاربر هویت شخص یا سرویس است. بعد بگو در عمل چطور آن را بررسی می‌کنی.

در Active Directory یک کاربر Account می‌تواند نماینده یک انسان یا حساب اجرای سرویس باشد. حساب سرویس باید هدف مشخص، کمترین مجوز لازم و مدیریت رمز مناسب داشته باشد و نباید مثل حساب شخصی استفاده شود

این نکته را با یک مثال توضیح بده: Security Group برای تخصیص Permission مناسب است. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Security Group مجموعه کاربران و رایانه‌ها برای دادن Permission یا Policy است؛ دسترسی را به Group بده و عضویت کاربر را مدیریت کن

این نکته را با یک مثال توضیح بده: Computer Account هویت سیستم عضو Domain است. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Computer Account هویت رایانه عضو Domain است و برای رابطه اعتماد بین Client و Domain استفاده می‌شود؛ خرابی این اعتماد می‌تواند Login یا دسترسی Domain را مختل کند

مطالعه درس همیشه عمومی است

برای ذخیره پیشرفت، دوره را رسمی شروع کن

با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود

ثبت‌نام و شروع رسمی