در این مقاله میخوایم ساختار اکتیو دایرکتوری رو بررسی کنیم و بگیم چه اجزائی داره
شناخت این موارد برای نفوذ به اکتیو دایرکتوری و کارهایی مثل ارتقا سطح دسترسی و حرکات جانبی بسیار لازمه
نکته : یک سری از مفاهیمی که بررسی میکنیم مربوط به بحث Windows Internals هستن و اگر سطح بالا به نظر امدن باید برای درک بیشترشون کتاب Windows Internals رو مطالعه بکنید ، من هرچقد بتونم ازش میگم که شما نیاز نداشته باشید 🤝😁
نکته2 : اکثر این مفاهیم بصورت منطقی باید گفته بشه و فرض بشه و چون مثال فیزیکالی براش نیست یکم درکش سخته و به مرور با کار عملی میتونید درکشون کنید پس اولش تو درک زیاد سخت نگیرید
نکته3: این مقاله با دید امنیتی و مختص بچه های امنیت شبکه نوشته شده ، ولی دید کاملی از اکتیو دایرکتوری بهتون میده
نکته4: اکثر این مواردو شما فقط باید بفهمید و نیاز نیست حتما درک کنید
نکته5 : هرچیزی که براتون مبهم بود حتما بپرسید 😉
منظور از forest یه قضاییه که ما توش بقیه چیز ها مثل دامین و ... رو قرار میدیم ، forest درواقع یک مرز امنیتی هست که یه فضای منطقی یا همون Logical هست برای دامین ها و بقیه اشیا در شبکه، مثلا ما در شکل بالا یه forest داریم که سه تا دامین داره ، دامین اول که اسمش هست apple.com ، دامین دوم که اسمش هست sub1.apple.com و دامین سوم که اسمش هست sub2.apple.com
دامین هم یک فضایی هست که ما اشیا خودمون رو توش قرار میدیم ، همون forest ولی کوچیک تر ، ما داخل forest یک یا چندین domain داریم که داخل اون ها ما اشیا مون رو داریم
ما مفهوم parent-child یا والد و فرزندی هم داریم ، به apple.com میگن والد یا HQ(Head Quarters) و به sub1 و sub2 میگن فرزند ، پس ما سه تا مرض و گروه جدا داخل شبکه بالا داریم یا سه تا دامین
توی هر دامین هم ما سخت افزار ها و دارایی های سازمان مثل همون پرینتر و یوزر ها و فایل هارو داریم (سمت راست کادر نارنجی)
اشیا همون منابع شبکه ما هستن ولی به صورت مجازی ، اشیا درواقع یک فایله که حاوی یوزر ها و گروه ها ، فایل سرور ، دیتابیس سرور و... است
به سروری گفته میشه که اشیا داخلش باشن ، این سرور تنظیمات active directory رو داره و گردن کلفت محسوب میشه 😅 و سطوح دسترسی رو هم توش تعریف میکنن
اگر هرچیزی داخل دامین ها بخوان باهم ارتباط برقرار بکنن باید بینشون trust برقرار باشه ، همون اتصال خودمونه و یک لینک ارتباطی امنیتیه که امکان و سطح دسترسی رو تعیین میکنه (لینکای مشکی که خط خطین و بین دامین ها وصلن)
یه فضاییه برای مدیریت بیشتر :))) همش که شد فضا !! جلوتر که بریم بیشتر درک میکنید !! ولی همینقدر بدونید که به هرچیزی که یه فضاییه برای دسته بندی کردن و گروه کردن چیزهایی که داخل دامین داریم مثلا در داخل دامین ما چه واحد هایی داریم ؟ DC - Users - Groups و...
سایت به معنای مکان هست ، تا حالا هرچیزی گفتیم مفهوم Logical و منطقی داشت ولی این مفهوم Physical هست ، مثلا فکر کنید دامین والد توی انگلیس هست و دو دامنه فرزندمون در امریکا ، ما دوتا سایت داریم ، یکیه برای انگلیس که حاوی یک دامینه و یکی هم برای امریکا که حاوی دو دامینه (سایت های برای مدیریت و نظم بیشتر هستن)
نکته : یک site میتونه حاوی چندین domain باشه ولی یک domain نمیتونه به بیشتر از یک site تعلق داشته باشه ( برای درک بیشتر شما site رو کشور فرض کن و domain رو آدم ، یک کشور میتونه چند تا ادم داشته باشه ولی یک ادم نمیتونه متعلق به چند کشور باشه)
برای اینکه ی این مواردی که گفته شد رو بیشتر درک کنید این ساختار رو نگاه کنید :
Apple.com
│ └───GPO
├───sub1.apple.com
│ ├───OU
│ ├───Employees
│ ├───Computers
│ └───Users
├───sub2.apple.com
...
در ادامه ما میاییم و میگیم که ما دوتا forest داریم ، یک مقدار مباحث جدید ما داریم :
در بحث شبکه این متداوله که ما چند تا Domain و یا Forest داشته باشیم که با trust به هم وصل شده باشن ولی این ها جهت دارن که در شکل بعد خلاصه توضیح میدم ولی شکل بالا رو اوردم که دیدی از forest داشته باشید
در اینجا به صورت خلاصه مبحث trust رو باز میکنیم و جلوتر کامل و جامع بررسیش میکنیم :
نکته : در این شکل کادرهایی که رنگ کرم دارن forest هست و ایکون های سرور نماد دامین هستن
دلیل وجود trust این هست که دامین های مختلف میخوان به محتوا های دامین های دیگه دسترسی داشته باشنو نمیخوان اون دامین رو مجدد بسازن ، چه از نظر داده و چه از نظر منابع فیزیکی
ارتباطات trust و دامین ها یکم پیچیدس و جلوتر بررسی میکنم ولی عکس بالا به صورت مقدماتی اینو داره میگه :
ارتباطی که بین دوتا forest شرکت dell و apple هست به صورت دو طرفه هست(به فلش دقت کنید) یعنی دامین والد dell و apple جفتی به منابع هم دسترسی دارن ، ولــــــی فرزنداشون اینطوری نیستن
فرزند ها به اطلاعات دامین والد خودشون یا فرزند های دیگر در forest خودشون دسترسی ندارن
و فرزندان هیچ forest ای به فرزندان forest دیگر دسترسی ندارن
مثال : واحد فروش شرکت apple به هیچ یک از واحد های دیگه شرکت apple دسترسی نداره و هیچ واحدیم بهش دسترسی نداره ( نه در forest خودش نه در forest شرکت dell)
واحد مالی شرکت dellهم به هیچ واحد دیگه ای دسترسی نداره و برعکس ، نه تو forest خودش نه تو forest شرکت apple
ولی والد ها به اطلاعات فرزندانشون دسترسی دارن ، والد apple به کل اطلاعات والد و فرزند های شرکت dell و والد dell هم به کل اطلاعات خود والد و فرزندان شرکت apple دسترسی داره
منطقیم هست ، هر کسی اطلاعاتی بخواد از والد یا فرزند دیگه باید به والدش اطلاع بده تا براش trust ساخته بشه
این مبحث در اخر مقاله موشکافانه تر بررسی میشه
هر object در اکتیو دایرکتوری قصه ما یک سری مشخصات و ویژگی ها داره ، با استفاده از این ها میشه اون شئی رو پیدا کرد و طبقه بندی کرد ، مثلا شئی computer ویژگی هاش اینان : hostname ، DNS name و..
همه این attribute ها هم یک نام مترادف در LDAP دارن واسه اینکه اگر ما query زدیم به LDAP بتونیم با استفاده از این نام ها اطلاعات بدست بیاریم مثلا شما نام کاملتو میدی و با displayName مچ میشه در یه entry و سرچ میشه یا نامتو میدی و با give name مچ میشه و قابل جستجو هست
| Value | Entry |
| Full Name | displayName |
| First Name | given name |
ما یه چیزی داریم به اسم Group Policy که میاییم و توش خط مشی و قوانین تعریف میکنیم ، و به صورت شئی ذخیره میکنه (این شئی که گفتم با شئی ای که توی اکتیو دایرکتوری در موردش صحبت میکنیم متفاوته)
هرجا اینو شنیدید میشه یه نقشه کلی از شبکه AD ای که داریم ، یه شکل کلی که همه چی توش معلوم باشه
در این نقشه نوع اشیا مشخص شده و attribute های مربوط به هر شئی در اون موجوده و برای هر شئی کلاس خاصی در نظر گرفته میشه طبق اون چیزی که اون شئی در اکتیو دایرکتوری هست مثلا :
| AD Object | Corresponding Class in schema |
| users | user |
| computer | computer |
یک مفهوم خیلی مهمه که اگر اینو یاد نگیرید بعدا به مشکل میخورید :
برای مثال اگر ما بگیم "computer RDS01" این object اکتیو دایرکتوری یک instance هست از کلاس Computer که توی schema بود چون از روی class خاص computer ساخته شده
ما در کل دو نوع شئی داریم در اکتیو دایرکتوری ، یکی اشئایی که خالین و چیزی نمیتونه داخلشون بره ، یکی اشیایی که داخلشون چیزی هست
نکته : فرق بین OU و Container چیه ؟ جفتشون کانتینر هستن ولی GPO فقط به OU اعمال میشه سر همینه که اکثرا از OU استفاده میشه
مثال : فرض کنید شما مدیر دومین asia.mycorp.com هستید و 500 تا کاربر و 500 تا کامپیوتر در شبکه (دامین) دارید ، شبکه شما رفت و امد زیاد دارد ، یعنی افراد زیادی روزانه ثبت نام میکنن و روزانه اخراج میشوند ، حالا میخواید این شبکه رو بدست یه سنیور بدید تا مدیریت بکنه ، امکان ساخت دومین جدیدی هم نیست !! شما میایید و تو همون دامین که دارید یک Organizational Unit میسازید به اسم دلخواه مثلا Manufacturing OU ، و به اون سنیور دسترسی و مجوز ادیت GPO رو میدید ، و در اینجا دسترسی ای که اون فرد سنیور داره روی Manufacturing OU هست نه روی کل شاخه و خود asia.mycorp.com
صحبت از درخت شد ، یه اصطلاح داریم به اسم درخت که به صورت شاخه وار میگه چه چیزی زیر مجموعه چه چیزی هست ، بالاتر شکلشو کشیدم و یه یبار
├───Root Domain
│ ├───child Domain
│ │ ├───Computers
│ │ └───Users
│ └───child Domain
├───Root Domain
│ ├───child Domain
نکته : این نکته مهمه و قبلش حتما Global Catalog رو بخونید تا این نکته رو بفهمید ، تمامی دامین ها که در tree هستن یک standard global catalog مشترک رو به اشتراک میگذارند که تمامی اطلاعات object های مربوط بهtree رو داخلش داره
Domain Controller که اول گفتم رو خاطرتون هست ؟ اگر نیست یه بار دیگه بخونیدش ، GC یه نوع DC هست که اطلاعات تمام object های یک forest رو ذخیره میکنه و ازشون کپی میگیره ، به این صورت هم کپی میگیره که از دامین متعلق به خودش یه کپی کامل (Full Copy) و از دامین های دیگه تو forest یک کپی ناقص (Partial Copy) میگیره
نکته : GC محتوا فقط خواندنی داره و مستقیما آپدیت نمیشه !
نکته : فرق بین DC و GC چیست ؟ DC فقط محتوا اشئا داخل دامین خودشو داره ولی GC علاوه بر محتوا دامینی که توشه محتوا دامین های دیگه رو هم داره
کاربر ها و برنامه ها با استفاده از کوئری زدن به GC میتونن اطلاعات هر شئی رو در هر کدوم از دامین ها بدست بیارن (داخل Forest)
GC دوتا کار میکنه :
یک رکن بسیار مهم هست ، GUID یک مقدار 128 بیتی منحصر بفرد و تکرار نشدنیه برای هر شئی که ساخته میشه ، تکرار میکنم هر شیئی تو شبکه که توسط اکتیو دایرکتوری ساخته میشه این شناسه رو میگیره و مثل MAC Address یکتا و منحصر بفرده ، این مقدار توی attribute ای ذخیره میشه به نام ObjectGUID
ما میتونیم توسط پاورشل کوئری بزنیم و ObjectGUID رو سرچ کنیم و شئی مورد نظر رو پیدا کنیم ،
سرچ توسط GUID دقیق ترین روشه مخصوصا که اگر ما کوئری زده باشیم به GC و چند مورد مشابه ببینیم و ندونیم کدوم مد نظرمونه و این مقدار تو تست نفوذ و فاز Enumerate بسیار بدردمون میخوره
نکته : تا وقتی شئی مد نظر ما در اکتیو دایرکتوری هست این مقدار ObjectGUID یا همون GUID شئی عوض نمیشه و به شئی دیگری تخصیص نمیگیره تا وقتی که اون شئی از اکتیو دایرکتوری ما خارج بشه !
برای سرچ کردن در اکتیو دایرکتوری ما گزینه های متفاوتی داریم از قبیل SID-GUID-SAM Account name-DN که جلوتر بهش میپردازیم
به مسیر کامل یه object میگن DN در اکتیور دایرکتوری ، مثلا تو مثال کامپیوتر خودم الان یه یوزر هست به نام محمد حسن پزشکیان که توی دامینیه به اسم mamad.com
قبل دیپ شدن یه مثال بزنم : فرض کنید میگن ادرستون کجاست ؟ میگید شهر اراک ، خیابون ملک ، کوچه فریدی ، ساختمان اجر سه سانتی ، پلاک 2 ، محمد حسن پزشکیان
هر کدوم از این بلاک ها با یه attribute مشخص میشن، مثلا DC="خیابان ملک" و... پس اینطوری یه object در AD پیدا میشه !
ما سه نوع Attribute داریم برای نام گذاری :
معمولا اکثرا از CN استفاده میشه ولی فورم درستش به این صورته :
| CN=bill gates,CN=Users,DC=microsoft,DC=com |
اینجا microsoft.com دامین ما هست که با DC نمایش داده شده و users ابجکت یوزر ماست که با CN نمایش داده شده و درواقع users واسه این با CN امده چون یه Container object هست (بالاتر توضیح دادم) و توش کلی اسم ذخیره میشه و جناب بیل گیتسم که اسم کامل فرد هست و نام ابجکت ماست
نکته : اگر شئی از یک DC منتقل بشه به DC دیگه DN اش عوض میشه
این مفهوم خیلی کلکیه ! خوب و با دقت بخونید :
RDN یک جزء از DN هست که اون object رو منحصر به فرد میکنه
فرض کنید شما توی یه OU دوتا کاربر دارید به اسم محمد (عکس سمت چپ) و این دوتا دقیقا DN یکسانی دارن ! یعنی مسیرشون همینطوری زیر شاخه خورده تا رسیدن به OU منابع انسانی ، حالا ما که نمیتونیم دوتا محمد یکسان داشته باشیم ! فقط یک محمد
نکته : اگر دوتا اسم یکسان بود خب دوتا فامیلی که یکسان نیست ؟ مثلا تو عکس سمت چپ سناریویی ک داریم دوتا اسم یکسانه ولی خب دوتا فامیلی متفاوته پس مشکلی نیست
نکته : اگر اسم و فامیلی جفتشون یکی بود چی ؟ یکیشون باید یک مشخصه داشته باشه که اون یکی نداره ، مثلا یکیشون سنش 27 عه و دیگری 31 ، خب فقط کافیه یه cn=34 اضافه کنیم به یکیشون و اونوقت این یکی یه RDN متفاوت داره پس توی یه OU میتونه کنار اون یکی باشه !
نکته : RDN میتونه اسم باشه ، یا OU باشه یا سن باشه یا قد باشه یا جنسیت باشه یا یه شماره خاص باشه یا .. فقط یه وجه تمایز باید باشه
نکته : هر جزئی از DN یک RDN هست ، یا به عبارتی چندین RDN کنار هم یک DN تشکیل میدهند
کلید : حداقل یکی از RDN ها در یک OU یا همون Container باید منحصر به فرد باشند ، یعنی تکراری نباشد ، اگر همشون تکراری بودند باید در Container های مختلف باشند(در Cotainer مختلف یعنی در مکان های مختلف ، یعنی DN مختلف) !
یک مثال اینجا اوردم ، ما یک شئی داریم در users به نام استیو جابز که دامینشم apple.com هست ، اینجا ما تو خط دوم یه کاربر دیگه با اسم steve jobs میاریم و اکتیو دایرکتوری این اجازرو به ما نمیده ! پس دوتا کار میتونیم بکنیم ، توی همون مسیر یه RDN دیگه تعریف کنیم ، مثلا سومی براش یه مشخصات تعریف کردیم که عدد 27 هست و سنشه ! یا میتونیم مثل گزینه اول مسیرشو عوض کنیم و یدونه RDN بهش اضافه کنیم که ما بردیمش تو sales و اینطوری DN عوض شد (نسبت به اصلی)
قبل پرداخت به کانسپت های امنیتی یکم با مبحث Access Token و SID اشنا بشیم
Access Token یک شئی داخل کرنله که به Porcess یا Thread تعلق میگیره و سطح دسترسی و گروه و... های دیگشو تعیین میکنه ، این موارد امنیتین ، یک توکن خالی که به process یا thread خاصی تعلق نداره ارزشی نداره !
thread ها هم معمولا از process شون به ارث میبرن token و دسترسی هارو !
یک نمونه توکن :
| ffffc4097ba54060 |
درواقع یک شناسس برای شناسایی یوزر ، گروه و یا دامین و سطح دسترسیش ، درواقع از دیدگاه امنیتی به هر کدوم یه عدد اختصاصی داده میشه که بشه تشخیص دادشون
در اکتیو دایرکتوری DC این شناسه رو تولید میکنه برای هر شئی و اونو تو دیتابیس خودش ذخیره میکنه
هر SID فقط یکبار حق استفاده داره و بعد دلیت کردن Security principals هم حتی اون SID حق استفاده شدن نداره
نکته : چه زمانی مقدار SID یه شئی میتونه عوض بشه ؟ زمانی که منتقل بشه به یک DC دیگه !
نکته : تغییر مقادیر در هر object هیچ موقع SID شو عوض نمیکنه
نکته : اگر یک object توی یک دامین یک مقدار SID داشته باشه این مقدار SID در دامین دیگه برای همین object مورد قبول نیست
مقدار SID یک object که توی یک دامین بوده و منتقل شده به یه دامین جدید میره توی sIDHistory و به اون object یه SID جدید توی دامین جدیدی که امده توسط DC تعلق میگیره
نکته : از دیدگاه امنیتی این قسمت اگر درست کانفیگ نشده باشه میتونه مورد سوء استفاده قرار بگیره و یک object جدید ایجاد بشه و SID قدیمی اون object ای رو بگیره که منتقل شده به یه دامین دیگه ! و این خطرناکه ، برای جلوگیری از این حمله باید SID Filtering فعال باشه
یک مقدارم درمورد اجزا سطح دسترسی :
در عکس بالا subject رو بگیرید یک برنامه که یه کاربر اجرا کرده و این برنامه سعی داره یک object (این object مال ویندوزه و با اونی که توی اکتیو دایرکتوری تا الان گفتیم یکی نیست !) مثلا Share folder رو بخونه و بهش دسترسی بگیره
اینجا اون شئی یه سری سطح دسترسی ویندوز براش تعریف کرده که هرکسی میخواد بهش دسترسی داشته باشه باید اون حد از دسترسی رو حداقل داشته باشه ، و اینجا یوزری که میخواد به این object دسترسی داشته باشه هم یه سطوح دسترسی ای داره (همون access token ای که گفتم) و حالا اینجا ویندوز میاد این دوتارو باهم مقایسه میکنه ، اگر سطوح دسترسی برنامه در حد اون object بود میتونه ازش استفاده کنه
یکم فنی تر توضیح بدم میشه اینکه اون object یه سری لیست دسترسی داره که بهش میگن ACE که تک تک اون ها با Access Token فرد تطابق داده میشن تا یک مورد Match پیدا بشه
مثال : فرض کنید شما میخواید وارد سینما بشید وسینما یه لیست داره از افرادی که میتونن وارد بشن ، وقتی شما میرید اونجا از باجه دم در یه بلیط یا Access Token میخرید ، روی اون بلیط شماره صندلی شمارو هم نوشته که مثلا 52 (مثلا ما فرض میکنیم اینطوریه) و وقتی شما میخواید از در رد بشید کارمند اونجا اول تو ذهنش میگه خب چه کسی حق داره از اینجا رد بشه ؟ یه لیست داره :
| افرادی که حق عبور دارند : |
| مدیر سینما |
| مسئول فنی |
| فروشنده بلیط مستقر در باجه |
| نظافتچی و سایر کارکنان |
| مشتری دارای بلیط |
و وقتی شمارو میبینه میگه خب شما گزینه اخر هستی ، یعنی 4 گزینه اول رو رد میکنه و وقتی به اخر میرسه میبینه سطح دسترسی شما با اون اخری Match شده و اصطلاحا اجازه عبور شمارو میده
این مکانیزم دقیقا تو ویندوز هست ، و اسم اون لیست در ذهن فرد دم در همون ACE هست که پایین میخوایم بهش بپردازیم :
هر چیزیه که سیستم عامل بتونه احراز بکنه ، شامل یوزر ها ، اکانت ها ، گروه ها یا حتی Process ها و Thread ها که در چارچوب یوزر اجرا میشن ! مثلا اگر ما Tomcat رو داشته باشیم و اجرا بشه حتی Security principals اونم احراز میکنه !
در اکتیو دایرکتوری ها این Security principals ها object هایی هستن که متعلق به دامین هستن و سطح دسترسی کاربرا و .. رو به منابع تعیین میکنن ، ما ارکان دیگه ای هم برای تعیین سطح دسترسی مثل local user accounts و یا security groups داریم که توسط SAM مدیریت میشن و سطح دسترسی رو کنترل میکنن
نکته : کنترل سطح دسترسی کلا مقوله ایه که به چندین عامل وابستس ، مثلا شما وقتی گوشیتونو به ضبط ماشین وصل میکنید که آهنگ پخش کنید ، اگر صدا ضبط تا ته زیاد باشه و صدای گوشیتون خیلی خیلی کم باشه ، اهنگ صداش کمه و برعکس ، پس به همه عوامل بستگی داره ، مثال واقعی تر بخوام بزنم مثل NTFS Permission و Share Permission هست ، اگر هر هرکدوم مجوز ندن و اون یکی بده ، تا زمانی که یکیشون مجوز کم تعیین بکنه همون مجوز کم اعمال میشه !
یک لیستی هست از سطح دسترسی هایی که به یه Object اعمال میشن
وقتی یک object به دامین دیگری منتقل میشه ACL از روی SID اون object که تو لیستش داشته دسترسی بهش میداده و وقتی اون object توی sIDHistory نیاد ثبت کنه که من منتقل شدم و SID قدیمیش اونجا ثبت نباشه ، ACL مجوز بهش نمیده ! چون SID جدیدش جایی ثبت نشده ، ولی وقتی بیاد و SID قدیمیشو تو sIDHistory ثبت کنه و بره SID جدید بگیره ACL رهگیریش میکنه و مجوز های SID قبلی اون شئی رو روی SID جدیدش ست میکنه !
یک Entry و مقداریه و مجوزی که به هر Object توی دامین چه دسترسی ای میشه داشت برای Trustee ها (Trustee همون اکانتای یوزر هاست ، یا گروه ها )
تعریف میکنه که چه اصول امنیتی و قوانینی روی یک object اعمال و تعریف میشه
لاگ برداری خودمونه ، که چه زمان چه یوزری سعی کرده به چه Object ای دسترسی بگیره
برای درک کامل این موارد عکس بالا رو ببینید که با رنگ نارنجی و مشکی مشخص کردم ، یکم با بحث سطح دسترسی ها در ویندوز کار کرده باشید دستتون میاد این موارد
برای درک این موارد یکبار عکس نارنجی و ابی ای که بالا گذاشتم رو ببینید !
این هم همینجا بگم ، وقتی یک شئی ای در اکتیو دایرکتوری ایجاد میشه برای بحث security principal منتها مروبط به forest دیگه ای هست (external forest یعنی forest خارجی)
فرض کنید از یک forest دیگه یک شئی مثلا یک کامپیوتر اضافه شده به دامین ما توی forest ما ، بلافاصله باید براش FSP تهیه بشه ، در این FSP یک چیز مهم یعنی SID اون شئی که تو forest خارجی بود هم ذخیره میشه و اگر ویندوز بخواد این شئی رو از طریق SID اش پیداش بکنه از طریق trust میره و از forest مبدا شئی میپرسه
این FSP ها در کانتیر خاصی قرار میگیرن "ForeignSecurityPrincipals" و RN شونم اینطوریه :
cn=ForeignSecurityPrincipals,dc=mamad,dc=com.
این درواقع اسمیه که کاربر باهاش وارد میشه و logon میکنه ، این اسم باید منحصر بفرد و یکتا باشه و کمتر از 20 کاراکتر باشه
(فلش صورتی)
اینم یه روش دیگس برای اینکه کاربرا رو بشه پیدا کرد ، یک attribute که یک پیشوند داره که همون اسم یوزره و پسوند که دامینه
(تو عکس بالا با فلش بنفش مشخصه)
ساده بگم کاربرا در اکتیودایرکتوری با استفاده از SPN میتونن سرویس هارو تو اکتیو دایرکتوری پیدا کنن ، اگر واسه یه سرویسی SPN نباشه نه کاربرا میتونن پیداش کنن نه Kerberos
SPN درواقع یک Instance از سرویس هست ، SPN ها توسط Kerberos استفاده میشن که یک logon account رو به Service Instance تخصیص بده ؛ یعنی به یه اپلیکیشن (Client Side Application) ، اجازه میده که به یه سرویس درخواست بزنه که احراز بشه بدون اینکه نیاز باشه اسم اکانت رو بدونه
(این مفهوم الان یکم براتون شاید گنگ باشه ، وقتی Kerberos و توضیح دادم اونجا کامل درکش میکنید)
(این مفهوم تو بحث Persist و Priv Esc در اکتیو دایرکتوری خیلی بدردتون میخوره !)
Replication یا تکرار زمانی اتفاق میفته در اکتیو دایرکتوری قصه ما که اشیاء ما Update میشن و و از یه DC به DC دیگه منتقل میشن
وقتی به AD ما یه DC اضافه میشه ، بین DC ای که از قبل بوده و DC جدید یه لینک ارتباطی صورت میگیره که بهش میگن "connection objects" و کل اشیاء از DC قبلی کپی میشن میرن DC جدید
در هر DC در اکتیو دایرکتوری یه سرویسی هست به نام Knowledge Consistency Checker (KCC) که یه برنامس به زبان ساده و مسئولیتش همین Replication هست و این لینک ارتباطی که خط بالا گفتم "connection objects" رو اون ایجاد میکنه و مسئول انتقال Object هاست
دلیل وجود replication اینه که اول مطمئن بشیم دیتا ها به صورت منظم و کامل در کل DC ها وجود داره و همه یه نسخه از اون دیتا رو دارند و درواقع اگر یه DC به مشکل خورد ما بکاپ داشته باشیم
نکته : Replication فقط بین DC های یک Forest صورت میگیره
sysvol یک پوشس (folder) یا میتونه (share) هم باشه ، که فایل های public روی توی دامین رو ذخیره میکنه و کپی میگیره ازشون ، مثل system policies - Group Policy settings - logon/logoff scripts و..
همچنین شامل تمامی اسکریپت هایی میشه که تو AD اجرا شدن تا task خاصی رو انجام بدن
دیتاهای sysvol هم برای سایر DC های دیگه Replicate میشه ولی توسط یه چیز دیگه به اسم "File Replication Services (FRS)"
\Sysvol
|____
| |____Policies
| |____Scripts
| |____ DO_NOT_REMOVE_NtFrs_PreInstall_Directory
| |____ NtFrs_PreExisting___See EventLog
|
|____Enterprise
| |____Policies
| |____Scripts
|
|____Staging
| |____Domain
| |____Enterprise
|
|____Staging Areas
| |____Enterprise (junction> = Sysvol\Staging\Enterprise)
| |____Your Domain Name (junction> = Sysvol\Staging\Domain)
|
|____Sysvol
| |____Enterprise (junction> = Sysvol\Enterprise)
| |____Your Domain Name (junction> = Sysvol\Domain)
یک نوع خاص از DC هست که اطلاعاتش فقط خواندیه و database اش در حالت read-only هست، هیچگونه پسورد هیچ حسابی در AD در RODC نمیمونه (Cache نمیشه) { البته بجز پسورد خود اکانت RODC و پسورد های RODC KRBTGT}
هیچ تغییراتی روی این RODC صورت نمیگیره ، روی نمیشه AD database یا SYSVOL یاحتی DNS سرورشو تغییر داد چون Read only هست ! و تغییرات sysvol از به بقیه DC ها منتقل نمیشه !
نکته : برخلاف اکانت های AD ، ما نمیتونیم به صورت مستقیم و تعاملی به اکانت krbtgt لاگین کنیم و باهاش تعامل داشته باشیم ، چون یه اکانت Built-in هستش و نام krbtgt هم نمیشه عوض کرد !
نکته : به رخش نگاه نکنید که خیلی امنه ، میزنیم میترکونیمش :)
نکته : این مفاهیم اگر براتون گنگه باید حتما Kerboros و ساختارشو یادبگیرید تا اینا براتون جا بیفته !
خب خب ، بشینید میخوام براتون قصه بگم :
یکی بود یکی نبود ، توی AD کبود ، مشکلی بود بین DC ها بر سر مدیریت و فرمان دهی ، لوس بازی بسه
در اوایل شکل گیری AD یه مشکلی بود بر سر اینکه کدوم DC تصمیم بگیره و تغییراتو اعمال کنه ، مایکروسافت امد و یه حرکتی زد ، گفت قانون "last writer wins" رو بیام بنویسم که میگه هرکی اخر همه نوشت اون اعمال بشه ، که خب مشکلش این بود که اگر اخری تغییرات اشتباهی میخواست بده چی؟ سازمان باید به فنا میرفت ؟
مایکروسافت امد گفت خب اولین DC دامینتون که root level هم هست (والد همه هست) بیاد تصمیم بگیره ، درواقع حالت master - slave ایش کرد و خب مشکلی که داشت این بود که اگر اون DC از دسترس خارج میشد کل سازمان به مشکل میخورد ! و مشکل SPF (Single Point of Failure) رو داشت
مایکروسافت امد گفت ، خـب حالا ما بیاییم وظایف رو بین DC ها تقسیم کنیم و امد Flexible Single Master Operation (FSMO) رو ساخت
این قوانین به DC ها اجازه میده که بدون تداخل باهم دیگه کاربران رو احراز بکنن
این 5 قانون به این صورتن :
Schema Master and Domain Naming Master (یدونه برای کل forest), Relative ID (RID) Master (یدونه برای هر دامین), Primary Domain Controller (PDC) Emulator (یدونه برای هر دامین), and Infrastructure Master (یدونه برای هر دامین)
تمامی قوانین به اولین DC توی forest ما اعمال میشه و اگر دامین جدیدی به forest ما اضافه بشه ، به DC اش فقط سه تا قانون اضافه میشه : RID Master، PDC Emulator و Infrastructure Master
این قوانین به کار کردن صحیح و روان شبکه کمک میکنن ، ترافیک replication رو هم کنترل میکنن و...
این قانون کل عملیات های read / write و copy رو در اکتیو دایرکتوری مشخص میکنه ، یعنی میشه تمامی attribute هایی که اعمال میشه به یه object در AD
Domain Naming Master : مدیریت نام دامنه ها رو انجام میده و مطمئن میشه که توی یک forest دوتا دامین با نام یکسان نداریم
قبل اینکه اینو بگم بزارید RID رو بگم :
درواقع rid قسمتی از sid هست که باعث منحصر به فرد شدنش میشه
حالا RID Master چیکار میکنه ؟ یه مشت از این RID ها میده به DC که هر شئی امد تو شبکه بهش اختصاص بده و کار اصلی RID ام منحصر به فرد کردنه یعنی اگر Domain identifier چند شئی یکی شد از لحاظ RID متفاوت باید باشن
این دوست عزیز وظیفش چیه ؟
اگر هاستی یا همون کامپیوتری این قانون بهش اعمال بشه توی دامین ، یک DC معتبر میشه و میتونه احراز هویت ها و اعمال مربوط به امنیت مثل تعویض پسورد ، احراز هویت ، GPO و... رو انجام بده
(زمان هم دست این دوست عزیزمونه)
این قانونم وظیفه تقسیم GUID - SUID - DN رو دامین ها داره (توی یک forest) و نشونه خرابی این قانونم وقتیه که ACL بجای اینکه نام کامل یک شیئو نشون بده SID شو نشون بده ! اونوقته که باید این Infrastructure Master درست بشه
نوبتیم که باشه نوبت سطح آشغاله :)
اما کاربردش چیه ؟ اگر در AD قصه ما Recycle Bin فعال باشه و ما شئی را پاک کنیم میره توش و اگر بخوایم برش گردونیم نیاز به بکاپ نیست ، برای مدت خاصیم اون شئی رو نگه میداره تو خودش و بعدش کامل پاکش میکنه
زمانش دست خودتونه و اگر ست نکنید پیشفرض 60 روز نگه میدار
این هم یک مکانیه در اکتیو دایرکتوری قصه ما که اشیاء حذف شده رو نگه میداره
وقتی شئی پاک میشه اگر Recycle bin فعال نباشه میاد اینجا و تمام فلگ هاش پاک میشه و فلگ isDeleted مقدارش True میشه و مثل recycle bin مدت زمان داره که بهش میگن Tombstone Lifetime که اگر بگذره دیگه فایلو کامل پاک میکنه
نکته : فرق بین Recycle Bin و Timbstone چیه ؟ اگر شئی بره توی Recycle bin تمام attribute هاش حفظ میشه ولی اگر بره تو Tombstone تمام attribute هاش پاک میشه
به نام کامل میگن FQDNو ساختارش اینطوریه :
[host name].[domain name].[tld]
و برای این بکار میره که مکان یه شئی رو در DNS پیدا کنیم ، کاربرد FQDN اینه که بدون دونستن آیپی یک شئی اون رو در AD پیدا کنیم ، دقیقا مثل google.com که شما ایپیشو نمیدونید ولی نامشو میزنید و سایت میاد
سمپلشم اینطوریه :
Ali01.mamad.com
و ali01 نام hostname هستش ، برای کاربر علی ! حالا 01 میتونه هرچی باشه عدد سن باشه هرچی!
برنامه گرافیکی ADUC برای مدیریت AD ، البته با پاورشل هم میشه باهاش ارتباط گرفت
یه برنامه گرافیکی برای مدیریت اشیاء در AD ، تفاوتش با ADUC اینه که میشه attribute هارو مدیریت کرد و روی تک تک اشیاء کنترل کامل داشت
این داداشمون یک شیء هست که برای مدیریت ACLs های اعضا داخل گروه ( built-in groups in AD ) که سطح دسترسی بالاییم دارن در AD وجود داره
درواقع مثل مفاهیم دیگه یه فضایی هست که سطح امنیتی اعضایی که جزو گروه محافظت شده ( protected groups ) هستن رو چک میکنه
خب ما یه پردازش هم داریم به اسم SDProp (SD Propagator) که روی نظم (هر یک ساعت یکبار) اجرا میشه و میاد سطوح دسترسی داخل شئی AdminSDHolder رو با سطوح دسترسی داخل روی یکی از قوانین RODC ای که بالاتر معرفی کردم (PDC Emulator Domain Controller)
فک کنید یه مهاجم رفته و یک ACL entry آلوده ایجاد کرده که مجوز های دسترسی یک یوزر خاص رو بگیره ، که این یوزر صد در صد چون سطح دسترسیش بالاعه جزو Domain Admins group هست
اگر تنظیمات دیگه ای در AD رو هم عوض نکنه و فقط به این بسنده کنه ، وقتی SDProp process قصه ما اجرا بشه و سطح دسترسی هارو چک کنه ، پرتــــش میکنه بیرون
(ما با این دوست عزیز تو تست نفوذ اکتیو دایکتوری خیلی کار داریم)
dsHeuristics در واقع یک رشتس (string) که روی service object ها اعمال میشه و تنظیمات و Configuration رو تعیین میکنه در کل یک forest
اگر AdminSDHolder بالا رو خونده باشید شاید یکم گیج بشید که چرا گفتی built-in groups بعد گفتی protected groups ، جریان چیه ؟
یکی از این تنظیمات اینه که بیاد و built-in groups رو از Protected Groups جدا کنه (exclude) ، خاطرتون هست که گفتم گروه های Protected توسط شئی AdminSDHolder و پردازش SDProp محافظت میشن و بعد یه مدت خاص هر تغییری که توی protected groups انجام توسط SDProp برمیگرده به حالت اولش؟ حالا اگر ما بیاییم یک گروه رو جدا کنیم از Protected Groups ، یعنی بهش یک dsHeuristics attribute بزنیم دیگه SDProp به اون گروه کاری نداره و هر تغییری که اعمال شه داخل اون گروه دیگه SDProp برش نمیگردونه به حالت قبل و اولش !
یک attribute داریم در AD به نام adminCount که میاد میگه آیا SDProp process از یه user محافظت میکنه یا ن
اگر مقدار این attribute عدد 0 بود یا مشخص نشده بود "not specified" پس یعنی SDProp process از اون کاربر محافظت نمیکنه
اگر مقدارش value بود یعنی محافظت میکنه
الان شاید براتون سوال بشه که مقدار "1" چی پس ؟ اگر مقدار 1 بود یعنی اون اکانت هم ازش محافظت میشه هم سطح دسترسی خیلی بالایی داره
و مهاجما خیلی به این حساب ها علاقه دارن چون اگر بخوره میتونه منجر به دسترسی به کل دامین بشه
مهم ترین فایل توی اکتیو دایرکتوری این فایله ، توی هر DC ما این فایلو داریم در مسیر
C:\Windows\NTDS\
و درواقع همون دیتابیسه ما هست که کل کل اشیاء و عضویت ها و.. همه چیو تو خودش ذخیره میکنه
و مهم تر از همه پسورد های هش شده کل کاربران اون دامین 🤩
و دیگه میدونید که میتونید کرک کنید یا pass-the-hash بزنید ، و درضمن اینم بگم که اگر توی تنظیمات "Store password with reversible encryption" فعال باشه پسورد cleartext هم ذخیره میشه توش که بعیده (یعنی اون شبکه احرازش مبتنی بر kerberos نباشه و مبتنی بر پسورد cleartext باشه (😑 مگه میشه ؟)
در اکتیو دایرکتوری ما سه نوع trust داریم :
در اولی خب معلومه هر دو سر rtust ما بهم متصلن و ارتباط دارن
در دومی که ورودی یک طرفه هست ، در عکس بالا قسمت پایینش میبینید یک لینک ارتباط وارد شده به لنوو از ایسوز ، به این حالت میگن one-way incoming trust از ایسوز پس کاربران لنوو میتونن توی شرکت ایسوز احراز بشن (اینو پایین تر توضیح میدم)
در سومی باز همون لینکه ولی اینبار از دید ایسوز اگر نگاه کنیم داره one-way outgoing trust میزنه به لنوو و یعنی کاربران لنوو میتونن احراز بشن در ایسوز
دقت کنید اگر incoming trust باشه مجوز دسترسی میشه outgoing access (لنوو داره trust از سمت ایسوز میگیره ولی به ایسوز دسترسی گرفته) و اگر outgoing trust باشه هم دسترسی incoming trust میشه ( ایسوز داره به سمت لنوو trust میفرسته ولی این لنوو عه که دسترسی میگیره به ایسوز)
نکته : trust هارو معمولا خوب تنظیم امنیتی نمیکنن سر همین ممکنه مشکل ساز بشه حملا و بهش حمله بشه و چون دسترسی هارو به دامین های دیگه باز میکنه خیلی خطرناک و گوگولیه :)
در مثال با لا به asus میگن trusting که داره دسترسی رو باز میکنه و اجازه میده که لنوو وارد بشه و به لنوو که دسترسی داره به ایسوز میگه trusted یا مورد اطمینان واقع شده
فرق بین transitive و non-transitive :
در اکتیو دایرکتوری ما forest داریم که چندین دامین توش داره که این دامین ها به صورت پیشفرض بهم trust دارن
فرض کنید مثال بالا ما apple داریم و dell که dell فقط یدونه root domain هست ولی apple رو با دوتاتا child پایینش یعنی sales و tech در نظر بگیرید ، وقتی بین apple و dell یه trust داریم از نوع forest (مثلا فرض کنید چون توی عکس اینطوری نیست) ، dell نه تنها به خود اون apple دسترسی داره بلکه به child هاشم دسترسی داره ، به این میگن transitive trusts یعنی سطح دسترسی تا child ها و اشئیاشون ادامه داره ! و این یه ویژگیه برای هر trust و Non-transitive trusts فقط بین خود اون دوتا دامین یا هرچیزیه و مجوز دسترسی به child ها داده نمیشه !
انواع trust
بین دامنه های درون یک forest هست و بین child ها و parent هست ، رابطه دو طرفه و transitive هست (معنیشو پایین تر میگم)
بین child هاست ، معمولا برای افزایش سرعت احراز هویته
بین دو دامین مختلف در forest های مختلفو جدا که قبلا توسط forest trust بهم وصل نشدن ، این نوع از فیلتر SID استفاده میکند و این ارتباط non-transitive هست
یک ارتباط دو طرفه transitive هست بین root domain یک forest و یک tree root domain جدیدو وقتی یک tree میسازیم این ارتباط شکل میگیره
یک ارتباط transitive بین دوتا forest root domain
بهتون حتما توصیه میکنم یکباره دیگم این مقاله رو بخونید تا کامل جا بیفته ، با یکبار خوندن کامل نمیفهمیدش !
نکته: نصف بیشتر موارد بالا که گفته شد مفهوم هستن و شما نباید توقع داشته باشید عملی کار کنید تا یادشون بگیرید ، چیز عملی ای درکار نیست ، مفهومو درک کنید و دنبال یادگیری از طریق کار عملی نباشید
تقریبا تمـامـی عکس های این مقاله رو خودم درست کردم و کپی فقـط با ذکر منبع جایزه !
رفرنس اکثر مطالب این مقاله کتاب Active Directory, 3rd Edition و کتاب Mastering Active Directory,3rd Edition و داکیومنت های خود مایکروسافت هست
اگر سوالی چیزی بود در خدمتم ، یاعلی :)