Доверие и групова безопасност в AD

Доверие между гори и домейни в AD

За начало да определим какво е това доверие в AD. Това е отношение между различните домейни. Така потребителите на един домейн могат да ползват ресурси от друг домейн. Пример: Нека да имаме два домейна А и В. В домейна В има два потребителя, User1 и User2. Домейна А се доверява на В, тогава потребителите от В могат да ползват услугите на домейна А, примерно споделени файлове и папки. Така казано потребителите от В се удостоверяват на домейн контролера В, а защото има доверие с А, то те могат да ползват позволените им услуги от А.

Направление на доверителните отношения

Доверителните отношения имат направление. Пример: Домейн А се доверява на домейн В. Тогава потребителите от В могат да ползват услугите на А. Обратния случай обаче не е валиден. Потребителите на домейн А няма да могат да ползват услугите на В, защото това направление няма доверие. Доверието може да бъде и двустранно. Тогава потребителите на двата домейна могат взаимно да си споделят и ползват услуги. Друго разделение на доверието е транзитивно и нетранзитивно. TRANSITIVE TRUST: Пример: Имаме три домейна, А, В, С. Имаме доверие двустранно транзитивно А-В и В-С. Това автоматически прави доверие двустранно и между А-С. Да припомним топологията на активната директория. Гора -> Домейн (един или няколко в гората) -> Домейн-контролер (един или няколко в домейна). Когато се създава гора (Forest), автоматично създаваме и първи домейн. След време вкарваме втори домейн в гората. Това по подразбиране прави доверителни отношения между двата домейна. Тези отношения са двустранни и транзитивни. Това значи всички домейните в една гора имат двустранни транзитивни отношения. NON-TRANSITIVE TRUST: Пример: Имаме три домейна, А, В, С. Имаме доверие двустранно нетранзитивно А-В и В-С. Тогава доверие между А-С няма в нито една посока Доверието ще си остане само между А-В и В-С

Типове доверителни отношения.

Пример: Имаме две гори А и В. В гората А имаме домейни А1, А2 и А3. Между домейните има двустранни транзитивни отношения по-подразбиране. В гората В имаме домейн В1. Да речем, че потребителите на домейн В1 искат да ползват ресурси на някой от домейните на гората А. Имаме няколко варианта: Първи вариант. Прави се доверие на горите (Forest-trust). Това е транзитивно двустранно доверие. Така потребителите на гората А със всичките домейни е нея, могат да ползват ресурсите на гората В със всичките домейни в нея. Правилото важи и за обрания случай. И ако се върнем на горната задача, потребителя на домейн В1 може да се върже на някой от домейните в гората А. Втори вариант. Доверие между домейни от различни гори. Използва се External Trust (външно доверие). Това е нетранзитивно доверие. Това доверие не е между горите, а между отделни домейни от различни гори. Примерно може да направим доверие между домейни А3 и В1. Това доверие може да е двустранно или едностранно, но нетранзитивно. Трети вариант: Shortcut Trust (доверие на пряк път). Когато имаме много домейни в една гора, примерно А1, А2, А3, А4 ….АХ и потребител от А2 иска да достигне до АХ, то той трябва да премине много път, примерно А2 до А1, после до А3, А4 и т.н. докато стигне до АХ. За да се избяга този дълъг път се прави доверие на пряк път. Това е пряко доверие между А2 и АХ. Отношението може да е едностранно или двустранно и е транзитивно. Това позволява на потребителите да намалят времето за влизане в домейна. Четвърти вариант: Realm Trust. Това са отношения между други служби, не е активна директория. Примерно доверие с някаква служба на Linux. Може да се достъпи до някой файлов ресурс в гората от Linux потребител, използвайки Realm Trust, но това не става през активната директория. В реалността е много рядък случай, но все пак е предвиден.

Типове защитени групи в активната директория

1. Distribution: Група от потребители не явяващи се обект на безопасност 2. Security: Група от потребители явяващи се обект на безопасност. Тези потребители имат определени разрешения (permission) и когато се удостоверят могат да ползват определени ресурси. Security Group се делят на: - Domain Local: - Global - Universal Domain Local и Global се съхраняват в домейн контролер от същия домейн. Пример имаме домейн група Test, която се намира в домейн DomainX. В тази група има няколко субекта. Тогава информация за другите субекти за членство за безопасност от тази група ще се съхранява на всички домейн контролери в дадения домейн. Сега ако някой от домейна DomainY има доверителни отношения с DomainX, то DomainY може да разбере има ли субект с определени права на безопасност в DomainX. Всичките тези примери се отнасят за групите Domain Local и Global. Universal, за разлика от предишните се съхранява само на домейн контролери които играят роля на глобален каталог. Това е разликата в репликацията между отделните групи.

Universal Group Caching

Имаме два глобални каталога примерно на два домейна (GC-X и GC-Y). За да се избавим от зависимостта на глобалните каталози Universal Group Caching кешира универсалната група на другите домейн контролери в домейна.

Едно ръководство във вид на таблица за групи и довереност. За съжаление е на английски. При желание може да се преведе.

Добавяне на потребители в групите

Има две стратегии за разпределяне на групите. Наричат се AGDLP и AGUDLP. Първата група се ползва когато има един домейн, а втората когато имаме гора с много домейни в нея. Да видим какво значат тези наименования. Започваме с AGUDLP A - Account G - Global group U - Universal group DL- Domain local group P - Permission Когато на някой потребител А(Account) имаме цел да създадем защитен принцип P(Permission), обикновената стратегия разбива потребителя на G (Global group), добавя G в DL (Domain local group) и DL дава разрешение. Много объркващо, но да поясним с практически случай. Имаме два отдела, продажби и счетоводство. Съответно членовете на тези отдели се слагат в отделни глобални групи с някакви права. Когато дойде нов човек в отдела той се вкарва в съответната група и получава правата и ограниченията на групата. Представете си сега, че човека го преместват в друг отдел. Просто прехвърляме човека в другата група и той получава правата и ограниченията на новата група. Задълбахме много в теория. Малко практика за нагледност. Започваме с постановката на която ще работим.

В предишната статия разгледахме работата на домйени в една гора. Тука ще създадем нова гора Forest 2. Двете гори ще имат доверителни отношения. В Forest 2, ще има домейн kolo.bok с домейн контролер. За да има доверителни отношения между TLan.Net и kolo.bok, то те трябва да знаят един за друг. Знаем информацията за домейн контролерите се получава от DNS-a. Това налага зоните в отделните домейни да се разрешат един за друг. Значи DNS-а на TLan-DC-01 трябва да разреши на kolo.bok. Съответно домейн контолера DC-TR на kolo.bok трябва да разреши DNS-a на TLan-DC-01. Всичко това ще го направим по два начина. В TLan-DC-01 ще направим stub зона или казано зона капак. В DC-TR ще направим направление с условие. В картинката е показано двустранно доверяване, а ние ще направим следното доверяване, за да проиграем няколко варианта. Изходящо доверяване от kolo.bok към TLan.Net, за да видим, че ресурсите са достъпни в противоположна посока. Предварителна подготовка. Влизаме на машината DC-TR. Машината е виртуална и пак е клонирана. За да нямаме предишните проблеми от клониране, в командния ред изпълняваме:

C:\Windows\system32>Sysprep\sysprep.exe

Машината се рестартира и правим необходимите първоначални настройки, като регион, лицензии и локална администраторска парола. Следващите стъпки са да дадем име на хоста, IP, както и да инсталираме гората kolo.bok. IP=192.168.0.254/24 DNS=127.0.0.1 Забележете, TLan-DC-01 и DC-TR са в една и съща мрежа.

И ако сте получили горната картинка, значи сте изпълнили всичко както трябва. Да се заемем със самата задача която сме си поставили. Преминаваме на TLan-DC-01 Ако се сещате трябва да се занимаем с DNS. Ще създадем Forward Stub Zone.

Даваме име на домейна за която зоната ще отговаря.

Тука трябва да укажем DNS сървъра, който ще съдържа зоната. В случая DNS сървъра съвпада с домейн контролера на kolo.bok.

Указваме IP адреса на DNS сървъра. Натискаме Enter.

Получава се горната картинка. Next > за продължение.

Забележете, зоната е създадена, но не активна. За целта:

За ръчно ускоряване на процеса.

Всичко е наред. Имаме заредена stub зона. Да проверим дали работи DNS-a. Отваряме Command prompt.

C:\Windows\system32>nslookup.exe kolo.bok Server: localhost Address: 127.0.0.1 Name: kolo.bok Address: 192.168.0.254

Супер, записа е разрешил достъп до kolo.bok Отиваме на машината DC-TR

Натискаме Enter

Забележете, IP-то не е разрешено. Това е нормално. Натискаме OK и продължаваме.

Имаме дефинирана зона. Указано е към кое IP да се препращат заявките.

IP-то вече е активно. Това е бъг който се знае. Така вече домейна е валидиран. Да проверим разрешение към някакво име. Отваряме Command prompt.

C:\Windows\system32>nslookup.exe tlan.net Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name: tlan.net Addresses: 192.168.0.2 192.168.10.2

Това означава, че разрешението между домейните е настроено. Условието DNS-да са дефинирани сме го изпълнили. Да се заемем с доверието между горите.

Тука се вижда довереността между домейните. Когато се прави двустранно доверие то се описва в два отделни прозореца. В горния прозорец е за изходящото доверие, а долния за входящото. Да създадем нов изходящ. Натискаме на бутона New Trust….

Вкарваме домейна с който ще правим доверителни отношения.

Тъй като дефинирахме правилно DNS-ите (направихме взаимно доверяващи се), то ни допусна до този екран. Иначе щеше да даде грешка. На горния екран има два варианта, External trust и Forest trust. Избираме доверие между горите.

Доверието ще е изходящо. Това означава че ще допускаме до ресурси на kolo.bok. (ние се доверяваме на…, той може да ползва наши ресурси).

Следва да укажем къде ще създадем доверие. Ако изберем This domain only, то трябва да изградим входящо доверие и в TLan.Net. Ако изберем Both this domain and the specified domain, създаваме едновременно две доверия, но трябва да ги потвърдим в TLan.Net.

Иска да се удостоверим в TLan.Net.

Да укажем типа удостоверяване. - Forest-wide authentication: Удостоверява се всичко автоматично - Selective authentication: Иска да се удостоверяваме за всеки ресурс поотделно.

Тука може да проверим доверието. За сега няма да го правим.

Създаде се изходящо доверие. Избираме Properties….

Валидираме доверието, като натиснем върху бутона Validate.

Доверието е валидирано.

Тука указваме какво да въвеждаме след @. Примерно въвеждаме administrator@tlan.net. Тука може да укажем да не е tlan.net a примерно test.net. Тогава ще се удостоверяваме на tlan.net с administrator@test.net. До тука разгледахме изходящото доверяване което създадохме. Да видим сега какво се е получило на TLan-DC-01

Имаме входящо доверие. Защото избрахме да се създадат двете доверия автоматично. Дайте да видим сега как ще достъпим ресурсите както сме дефинирали доверието. За теста ще създадем папка и ще я споделим.

Няма да можем да я споделим, защото дефинирахме доверието да е изходящо и едностранно. Виждат се само потребителите от домейна TLan.Net. Няма как да споделим папката на потребители от другия домейн. Да проверим това, като натиснем на бутона Add….

Locations…

Нямаме доверен друг домейн, защото доверието е еднопосочно. Същата операция ще я направим в домейна kolo.bok. Прехвърляме се на DC-TR.

Създаваме нова папка.

Появи се домейн на който може да се доверим. Избираме го.

Името се разреши. ОК за продължение.

Даваме разрешение на администратора на домейна TLan.Net да достъпи папката. Може да укажем какъв контрол да има върху папката. В случая даваме пълен контрол.

Да споделим папката.

Готови сме. Да се върнем на TLan-DC-01 за тест.

Натискаме Enter.

Папката е споделена и може да се работи в нея. По този начин се прави просто доверяване между домейни. Ползвайки текущата логика, може да се изгради и двустранно доверяване, като цяло всички варианти.