با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
UNC Path را مستقیم تست کن
برای Shared Folder مسیر UNC مستقیم را تست کن تا مشکل Drive Map یا Shortcut را از خود Share، DNS و Permission جدا کنی نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
محدوده را کاربر یا Group مشخص کن
محدوده مشکل مشخص میکند چند کاربر، دستگاه، شبکه یا سرویس تحت تأثیر هستند؛ مقایسه یک نمونه سالم و خراب سریعترین راه کوچک کردن محدوده است قبل از دانستن محدوده سراغ تغییر سراسری نرو OU در Active Directory برای سازماندهی Objectها و اعمال مدیریت و Group Policy استفاده میشود و با Security Group نقش یکسانی ندارد؛ طراحی OU باید بر نیاز مدیریتی و محدوده اعمال Policy تکیه کند، نه صرفاً تقلید از چارت سازمانی؛ جابهجایی Object بین OUها میتواند مجموعه Policyهای اعمالشده را تغییر دهد، بنابراین قبل از تغییر باید Scope و Linkهای GPO بررسی شوند برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن
Group Membership را بررسی کن
Permission اغلب از عضویت Group میآید؛ علاوه بر AD Membership ممکن است کاربر برای دریافت Token جدید نیاز به Sign out/Sign in داشته باشد اگر فقط یک کاربر Access Denied دارد، Group Membership و Token او را با کاربر سالم مقایسه کن؛ تغییر Permission کل Share نباید اولین اقدام باشد OU در Active Directory برای سازماندهی Objectها و اعمال مدیریت و Group Policy استفاده میشود و با Security Group نقش یکسانی ندارد؛ طراحی OU باید بر نیاز مدیریتی و محدوده اعمال Policy تکیه کند، نه صرفاً تقلید از چارت سازمانی؛ جابهجایی Object بین OUها میتواند مجموعه Policyهای اعمالشده را تغییر دهد، بنابراین قبل از تغییر باید Scope و Linkهای GPO بررسی شوند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود
Share و NTFS را جدا کنترل کن
NTFS فایلسیستم رایج Windows است و مجوز، Auditing و قابلیتهای سازمانی را پشتیبانی میکند؛ Permission روی File/Folder با Share Permission ترکیب میشود مالکیت فایل با مجوز دسترسی یکی نیست در File Server ویندوز، دسترسی کاربر میتواند همزمان تحت تأثیر Share Permission و NTFS Permission باشد و برای تشخیص نتیجه باید هر دو لایه بررسی شوند؛ مدیریت دسترسی از طریق Security Group معمولاً قابل نگهداریتر از دادن Permission مستقیم به تعداد زیادی User است؛ Inheritance نیز تعیین میکند مجوزها چگونه به زیرپوشهها برسند و تغییر بدون بررسی میتواند دسترسیهای ناخواسته ایجاد کند؛ دسترسی مؤثر باید با یک حساب آزمایشی از دید کاربر هم تأیید شود در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود
Inheritance یا Deny را پیدا کن
Inheritance باعث میشود Permissionهای Parent به Child منتقل شوند تا مدیریت سادهتر شود؛ قبل از قطع Inheritance ببین چه Entryهایی inherited هستند استثناهای زیاد ساختار Permission را شکننده میکند برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود
فرض کن در سناریوی واقعی شرکت مشکلی گزارش شده و احتمال میدهی به سناریو: Shared Folder باز نمیشود مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای مرتبط با همان سناریو و مستندات شرکت بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- اگر فقط یک کاربر Access Denied دارد، Group Membership و Token او را با کاربر سالم مقایسه کن؛ تغییر Permission کل Share نباید اولین اقدام باشد
- تغییر دادن تنظیمات مرتبط با سناریو: Shared Folder باز نمیشود قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره سناریو: Shared Folder باز نمیشود فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با سناریو: Shared Folder باز نمیشود، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارهای مرتبط با همان سناریو و مستندات شرکت وضعیت مرتبط با سناریو: Shared Folder باز نمیشود را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با سناریو: Shared Folder باز نمیشود بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- UNC Path را مستقیم تست کن
- محدوده را کاربر یا Group مشخص کن
- Group Membership را بررسی کن
- Share و NTFS را جدا کنترل کن
- Inheritance یا Deny را پیدا کن
- در هر مرحله فقط یک تغییر کنترلشده انجام بده تا اثر آن قابل تشخیص باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید UNC Path را مستقیم تست کنی و از کجا میفهمی نتیجه درست است؟
برای Shared Folder مسیر UNC مستقیم را تست کن تا مشکل Drive Map یا Shortcut را از خود Share، DNS و Permission جدا کنی
چرا باید محدوده را کاربر یا Group مشخص کنی و از کجا میفهمی نتیجه درست است؟
محدوده مشکل مشخص میکند چند کاربر، دستگاه، شبکه یا سرویس تحت تأثیر هستند؛ مقایسه یک نمونه سالم و خراب سریعترین راه کوچک کردن محدوده است
چرا باید Group Membership را بررسی کنی و از کجا میفهمی نتیجه درست است؟
اگر فقط یک کاربر Access Denied دارد، Group Membership و Token او را با کاربر سالم مقایسه کن؛ تغییر Permission کل Share نباید اولین اقدام باشد
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
