ساخت کاربر، گروه و OU در اکتیودایرکتوری

این مثال ادامهٔ نصب اکتیودایرکتوری روی Windows Server 2025 Standard با Desktop Experience است: کنترلر DC1 با IP برابر 192.168.50.10، دامین ad.example.com و نام کوتاه AD. برای آزمون ورود، یک Windows 11 Pro عضو همین دامین لازم است. نام‌ها نمونه‌اند و حساب‌های این تمرین نباید حساب واقعی کارکنان باشند.

ابزار Active Directory Users and Computers یا ADUC را از Server Manager → Tools باز کنید؛ روی سیستم مدیریت نیز می‌توان از ابزار RSAT مربوط استفاده کرد. ساخت حساب، گروه و OU به مجوز مناسب در همان محدوده نیاز دارد. حساب مدیرِ انجام‌دهندهٔ تغییر را از حساب عادیِ آزمون جدا نگه دارید. پیش از تغییر محیط موجود، محل حساب‌ها، عضویت‌ها و اختیارات فعلی را ثبت کنید.

در ADUC مطمئن شوید دامین ad.example.com انتخاب شده است. روی نام دامین راست‌کلیک کنید و New → Organizational Unit را بزنید؛ OU را Lab بنامید. همین کار را داخل Lab برای سه OU زیر انجام دهید. اگر این نام‌ها وجود دارند، ابتدا مالک و کاربردشان را بررسی کنید و صرفاً برای پیروی از مثال آن‌ها را جایگزین نکنید.

Users و Computers پیش‌فرض، Container هستند و نمی‌توان GPO را مستقیماً به آن‌ها Link کرد؛ برای این کار از OU مناسب استفاده کنید. انتقال حساب موجود به OU تازه می‌تواند سیاست‌های مؤثر بر آن را عوض کند. حساب DC1 را از Domain Controllers خارج نکنید و حساب‌های مدیریتی پیش‌فرض را وارد این تمرین نکنید.

• روی People راست‌کلیک کنید و New → User را انتخاب کنید. برای کاربر فروش نام نمایشی مشخص و User logon name برابر lab.sales با پسوند ad.example.com وارد کنید. نام ورود قدیمی را نیز کنترل کنید؛ در مثال AD\lab.sales خواهد بود.
• رمز موقت مطابق سیاست همین دامین تعیین کنید و برای حساب انسانی تازه، User must change password at next logon را فعال کنید. رمز را در توضیحات حساب یا فایل عمومی ننویسید و آن را از مسیر امن تحویل دهید. Password never expires را راه‌حل عمومی خطاهای رمز قرار ندهید.
• کاربر دوم را با نام lab.control در همان People بسازید. او برای مقایسهٔ دسترسی است و نباید عضو گروه فروش شود. هیچ‌یک از این دو حساب را عضو Domain Admins یا گروه مدیریتی محلی نکنید.

خواص هر حساب را باز کنید و نام ورود، فعال بودن حساب و محل آن را بررسی کنید. با کاربر عادی روی کلاینت عضو دامین وارد شوید و تغییر رمز اولیه را انجام دهید. خطای ورود را با افزایش سطح دسترسی دور نزنید؛ ابتدا نام دامین، رمز، وضعیت حساب و ارتباط کلاینت را بررسی کنید.

در OU برابر Groups، از New → Group دو گروه امنیتی بسازید. نوع Security برای کنترل دسترسی است؛ Distribution برای همین هدف مناسب نیست. Scope را آگاهانه انتخاب کنید:

Properties گروه GG-Sales-Users را باز کنید؛ در Members → Add کاربر lab.sales را وارد کنید، Check Names بزنید و ذخیره کنید. سپس در Members گروه DL-Sales-Modify، گروه GG-Sales-Users را اضافه کنید. اکنون فرد عضو گروه نقش است و گروه نقش عضو گروه مجوز. وجود این زنجیره هنوز به معنای داده‌شدن مجوز روی فایل‌سرور نیست.

برای بررسی عضویت مستقیم، Members همان گروه را ببینید. نمایش Member Of کاربر را فهرست کامل همهٔ عضویت‌های تودرتو فرض نکنید. Global در این مثال اعضای همان دامین را جمع می‌کند؛ Domain Local برای تخصیص مجوز به منبع در دامین خود استفاده می‌شود. برای ساختار چنددامینی، همین الگو باید با قواعد Scope و اعتماد بین دامین‌ها دوباره بررسی شود.

فرض کنید فایل‌سرور جداگانهٔ FS1.ad.example.com از قبل آماده است و اشتراک Sales دارد. مدیر فایل‌سرور باید مجوز Share و NTFS را متناسب با کار موردنظر برای DL-Sales-Modify تنظیم کند و مسیر دسترسیِ ناخواسته برای lab.control باقی نماند. این مرحله پیش‌نیاز آزمون است؛ ساخت پوشه و تنظیم جزئی مجوزها موضوع این آموزش هویت نیست.

\\FS1.ad.example.com\Sales

بعد از تغییر عضویت گروه، کاربر فروش باید کارهای باز را ذخیره کند، از ویندوز Sign out کند و دوباره وارد شود تا نشست تازه داشته باشد. در پنجرهٔ عادی همان کاربر، فرمان زیر گروه‌های موجود در توکن ورود فعلی را نشان می‌دهد؛ این فرمان پرس‌وجوی زندهٔ تمام عضویت‌های AD نیست.

whoami /groups

با lab.sales مسیر اشتراک را باز کنید و فقط در پوشهٔ آزمایشی، ساخت و ویرایش یک فایل نمونه را بسنجید. با lab.control نیز جداگانه همان مسیر مستقیم را امتحان کنید؛ در طرح این مثال نباید به محتوای فروش دسترسی بگیرد. اگر هر دو وارد می‌شوند، مجوزهای مؤثر و سایر عضویت‌ها را بررسی کنید. نبودن درایو شبکه در This PC، آزمون منع دسترسی محسوب نمی‌شود.

برای نمایش خودکار همین مسیر به شکل درایو S، مثال GPO و درایو شبکه را ادامه دهید. اگر مسیر باز نمی‌شود، عیب‌یابی پوشهٔ اشتراکی به تفکیک نام سرور، اعتبارنامه و مجوز کمک می‌کند.

اگر پشتیبان باید فقط رمز کاربران آزمایشی People را بازنشانی کند، در Groups یک گروه Security / Global به نام GG-Lab-Helpdesk بسازید و حساب عادی و مجزای lab.helpdesk را عضو آن کنید. این حساب را برای مدیریت حساب‌های ممتاز به کار نبرید.

• روی OU برابر People، گزینهٔ Delegate Control را باز کنید. گروه GG-Lab-Helpdesk را انتخاب کنید.
• از وظایف آماده، Reset user passwords and force password change at next logon را انتخاب کنید و جمع‌بندی Wizard را بخوانید. محدوده همین OU و اشیای مشمول زیر آن است، نه کل دامین.
• پس از ورود تازهٔ حساب پشتیبان، بازنشانی رمز یکی از حساب‌های آزمایشی People را با هماهنگی صاحب همان حساب بررسی کنید. برای سنجش محدودیت، تنها از حساب آزمایشیِ از قبل تعیین‌شده خارج این محدوده استفاده کنید؛ کاربر واقعی را موضوع آزمون قرار ندهید.

اختیار واگذارشده را با نام گروه، OU و وظیفه ثبت کنید. برای پس‌گرفتن اختیار یک پشتیبان، عضویت او در گروه و نشست‌های فعالش بررسی می‌شود. حذف کامل تفویض از OU نیازمند بازبینی و حذف همان مجوزهای ثبت‌شده در ACL است؛ حذف خود گروه یا اجرای دوبارهٔ Wizard، دکمهٔ بازگشت خودکار تفویض نیست.

هنگام تغییر واحد، گروه‌های قدیمی و جدید را بر اساس مسئولیت واقعی بازبینی کنید؛ انتقال OU به‌تنهایی عضویت گروه‌ها را عوض نمی‌کند. اگر تغییر آزمایشی اشتباه بود، فقط عضویت‌های افزوده‌شده و جابه‌جایی‌های ثبت‌شدهٔ همان حساب را برگردانید و سیاست و دسترسی حاصل را دوباره بسنجید.

برای کارمند خارج‌شده، حذف فوری حساب یا پوشهٔ پروفایل قدم اول نیست. غیرفعال‌سازی حساب نیز همهٔ نشست‌ها و دسترسی‌های جداگانه را همان لحظه پایان نمی‌دهد؛ چک‌لیست خروج کارمند را برای تحویل داده و بستن دسترسی‌ها دنبال کنید. در پایان این تمرین باید محل حساب‌ها، نقش هر گروه، اختیارات واگذارشده و نتیجهٔ آزمون دو کاربر روشن باشد.