Групви политики в AD

Груповата политика е мощен инструмент управляващ множество домейни, потребители и компютри. Пример за групова политика е „Обновяване на Windows“, „Задаване фирмена картинка на десктопа на потребителя“, „Инсталиране/Триене на софтуер на станцията на потребителите“ и т.н. Има над 3000 типизирани групови политики. Няма човек как да ги знае наизуст, доста често се борави с някоя търсачка за решаване на проблема. Условието да работи груповата политика е, потребителя трябва да е член на домейна, защото те се изпълняват в домейна.

Как работи груповата политика

Администратора създава GPO (group police object - обект на групова политика). В това GPO се съдържат политики, които администратора иска да наложи на потребители, компютри или файлове. GPO съдържа в себе си самата политика, примерно смяна на снимката на работния екран. Съдържа в себе си и значението на политиката, примерно C:\Desktop\wallpaper.jpg, в случая пътя към снимката. Освен това с GPO има и параметри, като включена политика или изключена. За да наложим GPO, трябва да знаем на кого. Именно прилагането върху нещо се казва връзка (Link). Примерно правим връзка към някое OU. Да обобщим: Правим GPO и създаваме връзка към OU. OU съответно съдържа в себе си компютри и/или потребители и/или други OU. GPO се състои от: - Computer configuration: това са тези политики които се прилагат на компютри. Ако се приложат върху потребители, просто няма да работят. - User configuration: същото както горната политика. Прилага се върху потребители и не може да се приложи на компютри. Съответно тези две политики съдържат в себе си: a. Policies (политики): Дефинира политика която потребителя не може да смени. b. Preferences (предпочитания): Дефинира политика която потребителя може да смени.

Къде може да се прилага груповата политика.

Груповата политика (GPO) може да се прилага върху сайтове. Прилагайки тази политика в сайта тя се разпространява във всички потребители в дадения сайт. Групова политика може да се приложи и върху определен домейн. По аналогия на горния случай, всички потребители от домейна получават групова политика Трето ниво на прилагане това е върху OU (организационна единица). Пак по аналогия с горните случаи, потребителите дефинирани в OU ще получат групова политика Политиките имат приоритет. Ако наложим групова политика в сайта, то тази политика ще важи в домейна и в OU. В обратния случай, ако наложим групова политика на OU, то тя няма да важи за домейна или за сайта. Има и още една политика (local). Това е локална групова политика. Тя действа на локално ниво (локален компютър, локален потребител). За да е активна тази политика, не и трябва да е в домейна. Иначе казано компютър който не е в домейн може да има локална групова политика. Как се прилага груповата политика? Първо се прилага локалната политика, после на сайта, после на домейна, после в OU, ако в това OU има друго OU то се прилага в следващото OU. OU в OU могат да се правят много пъти. Сега да предположим, че имаме следните групови политики: - Local: картинка на десктопа 1.jpg - Site: картинка на десктопа 2.jpg - Domain: картинка на десктопа 3.jpg - OU: картинка на десктопа 4.jpg - OU1 картинка на десктопа 5.jpg Принципа на работа е следния. Първо се налага групова политика local. На работния плот ще се сложи картинка 1.jpg, Груповата политика от сайта ще забърши тази картинка и ще сложи картинка 2.jpg. Груповата политика от домейна ще забърши тази на сайта, а груповата политика на OU ще забърши тази на домейна. Накрая политиката на OU1 ще забърши тази на OU и ще сложи 5.jpg. Накрая на екрана ще стои картинка 5.jpg. Ако груповите политики бяха различни и не си противоречат, то тогава се сумират в указания ред.

Структура на груповата политика в домейна

GPO се съхранява в GP Container в AD. GP Container съдържа общи свойства, като версия, дата на създаване и от този род. Освен това GPO се съхранява и в GP Template (шаблони). GP Template се съдържа във файловата система в \\SYSVOL. Тук шаблоните са най-различни, като се започне от дефиниране на десктопа, обновяване на системата, та се стигне до супер сложни дефиниции. Освен това GPO е с клиент-сървърна архитектура. На домейн контролера се намира GPO частта. GP Client се намира на клиентската машина и отговаря за това да наложи груповата политика зададена от сървъра. Пример: Създаваме GPO, присъединяваме я към OU. В този OU примерно лежи компютър. Този компютър когато се зареди, GP Client-a проверява за нови политики или дали има промяна по старите политики. Ако има нова или промяна по стара, взема от папката \\SYSVOL нужната му политика и я предава на Client Side Extension (Разширение от страна на клиента). Това са различни агенти които налагат предадените им политики. Говорим за папката \\SYSVOL която е на домейн контролера. За репликация на тази папка между различните домейн контролери отговаря технологията DFS.

Версия на GPO

Говорихме за два типа версии. Едната се отнася за AD (GP Container), а другата за SYSVOL (GP Template). В зависимост от версиите, клиента разбира коя политика да приложи. При промяна на някое правило, версията нараства с +1. Пример: В DC-1 правим промени по груповата политика. Съответно версиите на AD и SYSVOL нарастват с 1. Правим нови промени версиите стават примерно AD=5 и SYSVOL=5. В същото време правим промени на другия домейн контролер DC-2. Променя се AD=7, а SYSVOL не се е репликирал и си остава 5. Тогава се генерира грешка. Този проблем ще го разгледаме малко по-надолу. GP Client от своя страна гледа промените в AD и ги сравнява със своите. Ако има такива ги прилага в клиентската машина. Освен тези версии има още Computer configuration и User configuration. Това означава, че клиента не трябва да тегли всички изменения.

Практика

Влизаме на TLan-DC-01

Забележете, много прилича на структурата на Active Directory Users and Computers. В случая липсват само контейнерите, защото върху тях не може да се прилага групова политика. OU обаче е налично, примерно като TLan, който създадохме преди. Това предполага, че върху OU може да се прилагат групови политики. Всичките групови политики се съхраняват в Group Policy Object. Както виждате вече има две създадени по подразбиране. Да създадем нова.

Груповата политика съдържа две части. A. Computer Configuration: Прилага политиката върху компютри, a. Policies: Политика която не може да се изменя от потребителя, o Software Settings: Управлява програмното осигуряване, o Windows Settings: Управлява общите настройки на Windows, o Administrative Templates: Настройки на компонентите на Windows и още неща с шаблони. Примерно да инсталираме Microsoft Office или обновяване каквото искаме да направим, b. Preferences: Политика която потребителя може да дефинира, o Windows Settings: o Control Panel Settings: B. User Configuration: Прилага политиката върху потребители, a. Policies: Политика която не може да се изменя от потребителя, b. Preferences: Политика която потребителя може да дефинира.

От тук може да се ползват готови шаблони, създадени от Microsoft за наше улеснение. Избираме Windows Update.

Configure Automatic Updates отговаря за обновяването като цяло.

Има няколко ключови момента. A. Not Configured: Политиката е приложена но не е конфигурирана как да работи. B. Enabled: Политиката прилага параметрите зададени в частта Options: C. Disabled: Политиката е деактивирана. В частта Options може да се укажат допълнителни параметри, като автоматично да се обновява, да предупреждава администратора преди да се обнови и т.н. Има и още един прозорец, Help, който пояснява кой избор до какво довежда. В случая не искаме да се обновяваме. Обновяването на Windows ще се прави ръчно.

И ако погледнем на екрана, ще видим, че политиката е изключена. Ако имате интерес може да разгледате и останалите политики, които са над 3000. След редакция нищо не се натиска за запомняне, просто се затваря екрана. Политиката автоматично е записана вече. Да разгледаме какво сме създали.

Груповата политика е активна, прилага се на компютри. Политиката е създадена но трябва да се приложи на някой обект. В демонстрациите имахме клиентска машина която беше вкарана в домейна.

Да приложим политиката върху този компютър. В случая обаче има проблем. Компютъра се намира в контейнер. Контейнера се казва Computers. Знаем, че там групова политика не може да се наложи. За решаване на тази задача има два варианта. - Преместваме компютъра в някое OU. Налагаме политиката върху това OU, - Да приложим политиката на TLan.Net, което автоматично ще приложи политиката надолу по всички компютри в домейна. Избираме първия вариант.

Предупреждава ни, че преместването на компютъра в друго OU, ще доведе до налагането на нови групови политики върху му.

Компютъра е в OU-то, което искахме. Сега вече може да наложим групова политика върху OU Computers на OU TLan. Отваряме управлението на груповите политики.

Има два способа да наложим политиката върху OU Computers. - Влачим с мишката политиката и я пускаме в OU Computers. - Втория способ е цъкаме с десен бутон на мишката върху OU Computers

Избираме политиката и натискаме OK.

Появи се препратка (link), към създадената групова политика. Така политиката която създадохме се наложи върху OU Computers, а от там и върху нашия компютър WIN81-E-X86 Има един по-кратък начин на създаване на групова политика към дадено OU и едновременно с това прилагане на политиката върху OU-то.

По този начин хем ще се създаде групова политика за OU Computers, хем ще я наложи върху OU-то. Сега да видим дали наистина се е наложила политиката на клиента. Прехвърляме се на WIN81-E-X86.

Изненадааа !!!. Уж имаме групова политика, правилно създадена, а не е наложена на компютъра. Това е така защото политиката е клиент-сървърна. Ние политиката я дефинирахме на сървъра но тя не е изтеглена от клиента. По подразбиране клиента тегли политиките от сървъра в различни интервали. За домейн контролерите този интервал е 5 мин. На самите клиенти политиката се обновява един път на 90 мин, може да стигне до 2 часа. За да не чакаме толкова време правим следното: Отваряме Command Prompt.

C:\Windows\system32>gpupdate /force Updating policy... Computer Policy update has completed successfully. User Policy update has completed successfully.

Ако бяхме ползвали само gpupdate без разширението, щеше да изтегли само изменението на политиката, а с разширението се теглят всички политики. Това принуждава клиента да наложи политиката веднага. Между другото, при рестарт компютъра също тегли всички групови политики и си ги зарежда.. Да пробваме наново.

Как да се обновяваме вече е недостъпно за нас. Значи груповата политика се е наложила и тя казва никога да не се обновяваме. Сега да се върнем на TLan-DC-01 и да задълбаем повече е груповите политики. Да създадем нова политика в OU Computers.

Забележете как създадохме политиката и как автоматично се създаде линк към нея. Да редактираме политиката.

На практика правим същата политика.

Правилата са малко по различни. Политиката е включена, и ще ни пита дали да инсталираме обновяванията.

Политиката я има, включена е и се налага върху компютри. Забележете, имаме две еднакви политики. TLan Update и TLan Update 2. Разликата е в това, че първата забранява обновяванията, втората ги разрешава. До сега знаем, че политиката се прилага в ред Sait > Domain > OU. Сега обаче имаме групова политика в едно и също OU. Да разгледаме по подробно.

И двете политики са присъединени. Значи са приложени към OU Computers. Гледаме Link Order. Колкото е по-високо политиката, толкова по-късно се прилага. Това значи, че политиката TLan Update ще се наложи последна и тя ще остане активна (Ще се забрани обновяването на Windows). Има и още един прозорец, наследяване на груповите политики

Тука се показва не само поредността на политиките, но и тези политики които действат косвено. Отново политиката 1 ще се наложи над останалите. Ако искаме да променим приоритетите.

Със стрелката нагоре вдигаме приоритета на избраната политика. Получава се:

Така второ-създадената политика ще се наложи над първата. Да проверим. Прехвърляме се на WIN81-E-X86. Отваряме Command Prompt.

C:\Windows\system32>gpupdate /force Updating policy... Computer Policy update has completed successfully. User Policy update has completed successfully.

Политиката е наложена. При обновяване на Windows, ще ни уведомява. Връщаме се на TLan-DC-01.

Сега да демонстрираме как групова политика наложена от домейна, да не се възприема от OU-то. Да махнем връзката на политиката TLan Update с OU Computers

Да наложим политиката TLan Update на домейна.

Влачим с мишката TLan Update до домейна TLan.Net.

Политиката е наложена и върху OU Computers, защото е присъединена към домейна. Сега искаме в OU Computers, да не се наследяват политики от по горно ниво. В случая по-горното ниво са политиките дефинирани в OU TLan и домейна TLan.Net.

Остана да важи само политиката която е присъединена към OU Computers. По този начин политики от по-горно ниво не се налагат в OU-то.

Свойства на груповата политика

Нека да разгледаме една групова политика по-обстойно. Започваме с първия раздел.

Display links in this location: TLan.Net - Груповата политика TLan Update се намира в домейна TLan.Net, The following sites, domains and OUs… - В този прозорец се показва къде е присъединена политиката. В случая е към OU Computers и домейна TLan.Net. Security Filtering - Указва на кого да се приложи политиката. В случая е Authenticated Users, това са всички потребители и компютри логнати в домейна. Може да махнем всички потребители и да приложим политиката на точно определен човек или компютър. Пример: прилагаме политика на дадено OU в което има и потребители и компютри. Ние искаме политиката да се отнася само за даден компютър. Тогава тук указваме компютъра върху който да се наложи правилото. WMI Filtering – Windows Management Interface с който може да управляват много параметри на Windows. Ако погледнете на картинката ще видите папка с името WMI Filters. В нея могат да се създават правила, които да се налагат с WMI Filtering. Другия раздел е Details.

Тук може да се указва състоянието на политиката. All settings disabled: Политиката е изключена, равносилно на премахване на всички връзки на политиката към когото и да е, Computer configuration settings disabled: Забраняваме прилагането към компютърни конфигурации, Enabled: Политиката е включена, User configuration settings disabled: Забраняваме прилагането към потрибители. Тук също може да се види кой е собственик на политиката, кога е създадена, кога е променена, версията на потребителя за AD и SYSVOL, разбира се и версията на компютъра. Още един раздел, Delegation

Прилича много на разрешенията на NTFS, но отнасящи се за груповата политика. Както при NTFS имаме четене, триене, модифициране и т.н. но върху груповата политика. Да изтрием всички групови политики които създадохме до тук, и да демонстрираме предпочитание в груповата политика.

Да променим дължината и сложността на паролата която изисква Windows по подразбиране.

Трябва да се получи следното:

Паролата може да е от един символ. Паролата вече не трябва да отговаря на сложността от големи малки букви, символи и т.н. Забележете: Политиката за пароли се налага само върху домейна. Ако искате да създадете подобна в OU, то тя няма да се наложи. Сега вече може да създадем потребител с проста парола. Но за да стане това, първо трябва да наложим правилото което създадохме. Отваряме Command prompt:

C:\Windows\system32>gpupdate /force Updating policy... Computer Policy update has completed successfully. User Policy update has completed successfully.

Сега да създадем потребителя, който ще е копие на администратора.

Потребител adm с минимална парола. В случая паролата е 1.

Готово потребителя е създаден. Сега да преместим потребителя в OU Users.

Влачим потребителя с мишката до OU Users.

Сега да се върнем на груповите политики.

Политика, да създадем папка в C:\ с име TLan. Папката да не е само за четене, да не е скрита, да не е архивна. Да видим какви бяха другите варианти при създаване на папка.

Create: Създава папка, Replace: Обновява досегашното правило, като първо изтрива старото правило и го създава наново. Пример: имали сме папка TLan, с правило само за четене. С replace създаваме наново папка TLan но в нея може и да се записва. Update: това правило просто обновява досегашното правило. Ако се върнем на горния пример, то тука пак ще имаме папка TLan и пак ще си остане само за четене. Delete: Трие папка. Тъй като до сега тази папка сме я нямали с правилото Update ще създадем папката. Трябва да се получи следното:

Поглеждайки на картинката виждаме, че имаме вече правило за създаване на папка. По принцип може в това правило да се дефинират създаване на множество папки, като последователността се определя от числото в Order. Order=1 се създава първа, Order=2 се създава втора и т.н. Да тестваме правилото. Излизаме от потребителя administrator@tlan.net и влизаме с adm@tlan.net

Папката съществува. Не наложихме правилото с gpupdate, но излязохме и влязохме наново. Това на практика зареди наново груповите политики. С това мисля да приключваме темата за груповите политики. Ако сме реалисти никой не може да знае всичките които са дефинирани като шаблони от Microsoft. За това има търсачки. Просто имате идея, търсите някакво подобно решение с търсачката и я прилагате за себе си. Това особено е актуално ако сте начинаещ в областта.