با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
پیام خطا را دقیق ثبت کن
متن کامل پیام، Code و زمان خطا را ثبت کن؛ بازنویسی از حافظه ممکن است مهمترین سرنخ را از بین ببرد Active Directory Domain Services یک Directory Service سلسلهمراتبی برای نگهداری Objectهایی مانند User، Computer و Group و ارائه Authentication و Authorization در دامنه است؛ Domain Controller نسخهای از Directory را نگه میدارد و سرویسهایی مانند DNS برای پیدا کردن سرویسهای دامنه اهمیت زیادی دارند؛ هنگام عیبیابی باید Name Resolution، زمان سیستم، سلامت ارتباط با DC، وضعیت Replication و عضویت درست Computer در Domain کنار هم بررسی شوند روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن
DNS Client به DNS داخلی اشاره کند
DNS نام را به اطلاعاتی مانند IP تبدیل میکند تا کاربر مجبور نباشد نشانی عددی سرویسها را حفظ کند؛ اگر IP مقصد کار میکند ولی نام نه، Query DNS را جداگانه آزمایش کن پاک کردن Cache ممکن است کمک کند اما جای بررسی Record، Resolver و مسیر DNS را نمیگیرد DNS سامانه نامگذاری توزیعشدهای است که نام را به دادههایی مانند IP مرتبط میکند و بسیاری از سرویسهای سازمانی به Name Resolution درست وابستهاند؛ خطای DNS ممکن است در ظاهر شبیه قطعی شبکه یا خرابی برنامه دیده شود، بنابراین باید جداگانه بررسی شود که Client به DNS Server درست اشاره میکند، Query پاسخ میگیرد، Zone و Record مورد نیاز وجود دارند و زمان و دامنه جستوجو با طراحی شبکه سازگارند Active Directory Domain Services یک Directory Service سلسلهمراتبی برای نگهداری Objectهایی مانند User، Computer و Group و ارائه Authentication و Authorization در دامنه است؛ Domain Controller نسخهای از Directory را نگه میدارد و سرویسهایی مانند DNS برای پیدا کردن سرویسهای دامنه اهمیت زیادی دارند؛ هنگام عیبیابی باید Name Resolution، زمان سیستم، سلامت ارتباط با DC، وضعیت Replication و عضویت درست Computer در Domain کنار هم بررسی شوند؛ وقتی به «DNS Client به DNS داخلی اشاره کند» میرسی، معیار یادگیری این است که بتوانی جای آن را در سناریوی «سناریو: ورود به Domain ناموفق است» مشخص کنی و علت رفتارش را توضیح بدهی
Time Client و DC را بررسی کن
در خطای Domain Login اختلاف ساعت Client و DC را ببین چون Kerberos به زمان حساس است؛ فقط ساعت نمایشی را نگاه نکن؛ Time Source و Zone را هم بررسی کن Active Directory Domain Services یک Directory Service سلسلهمراتبی برای نگهداری Objectهایی مانند User، Computer و Group و ارائه Authentication و Authorization در دامنه است؛ Domain Controller نسخهای از Directory را نگه میدارد و سرویسهایی مانند DNS برای پیدا کردن سرویسهای دامنه اهمیت زیادی دارند؛ هنگام عیبیابی باید Name Resolution، زمان سیستم، سلامت ارتباط با DC، وضعیت Replication و عضویت درست Computer در Domain کنار هم بررسی شوند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن
Lockout یا Disable حساب را کنترل کن
در خطای ورود Domain وضعیت Account را از نظر Lockout، Disable، Expiration و Password جدا بررسی کن؛ پیام عمومی Login همیشه علت دقیق را نشان نمیدهد 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 بررسی شوند در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن
Reachability و سلامت DC را بررسی کن
Client باید بتواند DNS و سرویسهای لازم DC را پیدا و به آن برسد. Ping بهتنهایی کافی نیست؛ DNS SRV، Portهای لازم و رویدادهای AD را هم بر اساس نشانه بررسی کن Active Directory Domain Services یک Directory Service سلسلهمراتبی برای نگهداری Objectهایی مانند User، Computer و Group و ارائه Authentication و Authorization در دامنه است؛ Domain Controller نسخهای از Directory را نگه میدارد و سرویسهایی مانند DNS برای پیدا کردن سرویسهای دامنه اهمیت زیادی دارند؛ هنگام عیبیابی باید Name Resolution، زمان سیستم، سلامت ارتباط با DC، وضعیت Replication و عضویت درست Computer در Domain کنار هم بررسی شوند در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود
فرض کن در سناریوی واقعی شرکت مشکلی گزارش شده و احتمال میدهی به سناریو: ورود به Domain ناموفق است مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای مرتبط با همان سناریو و مستندات شرکت بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- پاک کردن Cache ممکن است کمک کند اما جای بررسی Record، Resolver و مسیر DNS را نمیگیرد
- Client باید بتواند DNS و سرویسهای لازم DC را پیدا و به آن برسد. Ping بهتنهایی کافی نیست؛ DNS SRV، Portهای لازم و رویدادهای AD را هم بر اساس نشانه بررسی کن
- تغییر دادن تنظیمات مرتبط با سناریو: ورود به Domain ناموفق است قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با سناریو: ورود به Domain ناموفق است، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارهای مرتبط با همان سناریو و مستندات شرکت وضعیت مرتبط با سناریو: ورود به Domain ناموفق است را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با سناریو: ورود به Domain ناموفق است بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- پیام خطا را دقیق ثبت کن
- DNS Client به DNS داخلی اشاره کند
- Time Client و DC را بررسی کن
- Lockout یا Disable حساب را کنترل کن
- Reachability و سلامت DC را بررسی کن
- در هر مرحله فقط یک تغییر کنترلشده انجام بده تا اثر آن قابل تشخیص باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید پیام خطا را دقیق ثبت کنی و از کجا میفهمی نتیجه درست است؟
متن کامل پیام، Code و زمان خطا را ثبت کن؛ بازنویسی از حافظه ممکن است مهمترین سرنخ را از بین ببرد
این نکته را با یک مثال توضیح بده: DNS Client به DNS داخلی اشاره کند. بعد بگو در عمل چطور آن را بررسی میکنی.
DNS نام را به اطلاعاتی مانند IP تبدیل میکند تا کاربر مجبور نباشد نشانی عددی سرویسها را حفظ کند؛ اگر IP مقصد کار میکند ولی نام نه، Query DNS را جداگانه آزمایش کن
چرا باید Time Client و DC را بررسی کنی و از کجا میفهمی نتیجه درست است؟
در خطای Domain Login اختلاف ساعت Client و DC را ببین چون Kerberos به زمان حساس است. فقط ساعت نمایشی را نگاه نکن؛ Time Source و Zone را هم بررسی کن
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
