ADDS

Прежде чем работать и детально изучать какую-то нам необходимо понимать ее суть, выучить и
опять же понять все основные термины, а самое главное разложить в голове по полочкам
концепцию. Сегодня мы предлагаем рассмотреть идеологию такой технологии как Active
Directory, а как показывает опыт даже системные администраторы, имеющие за плечами годы
администрирования AD зачастую «тонут» в терминах, встречающихся в документации. Посудите
сами «Лес Active Directory, Дерево Active Directory , Схема Active Directory, Сайт Active Directory
и.т.д» даже здоровая голова с непривычки закипит. На самом деле все очень просто, сейчас вы
сами в этом убедитесь.
Исторически сложилось так, что у вас существует два способа объединения компьютеров в сеть,
первый называется «Рабочая Группа», второй «Домен Active Directory». Эти термины описывают
логическое объединение ваших компьютеров сеть. Т.е раскиданы компьютеры могут быть по
десяти городам или более, это физическая структура вашей сети, но логически они будут
объединены в один домен Active Directory или в одну рабочую группу (что тоже встречается).
Для начала рассмотрим принцип рабочей группы.
Такую сеть часто называют «одноранговой». Почему? Вспоминаем документ «Табель о Рангах»,
который описывал соотношение чинов по старшинству и приходим к выводу, что в рабочей
группе все наши компьютеры равны. И не важно работает компьютер под управлением Windows
Server 2003 или Windows XP. Это первая особенность рабочей группы.
Чтобы вывести вторую особенность ответьте на вопрос, зачем мы объединяем компьютеры в
сеть? Возьму смелость на себя и предположу, что основная цель это предоставления доступа к
ресурсам. Ресурсам, расположенным на одном участнике сети для других. Какие это ресурсы
дело пятое, корпоративное приложения или сервер Counter Strike. Сразу еще один вопрос «Что
главное при открытии доступа к ресурсах? (особенно в корпоративной среде) ». Ответ лежит на
поверхности – главное это безопасность. Вы явно не хотите, чтобы ваш домашний фотоальбом
стал доступен всему дому, подключенному через беспроводную сеть, но в тоже время ваш друг,
сосед с пятого этажа должен увидеть фотографии со вчерашней вечеринки. Как же быть?
Необходимо аутентифицировать и авторизовывать подключающихся к вашему компьютеру
клиентов сети. Чтобы вы четко понимали термины «аутентификация» и «авторизация» приведу
простой пример, позаимствованный у сотрудника Microsoft.
Вы идете по улицам столицы и вас останавливает сотрудник ППС. Естественно просит ваши
документы. Вы достаете свой паспорт и отдаете сотруднику Милиции. Он открывает паспорт и
видит, что вы гражданин РФ и фотография в паспорте на вас чем то похожа. Это говорит о том,
что аутентификацию вы проходите. После чего сотрудник милиции открывает страницу паспорта
с пропиской, видит, что прописка в Магаданской области и сообщает вам, что авторизацию вы
провалили.
Если серьезно, то аутентификация это проверка того что в сети существует учетная запись
пользователя, который хочет получить доступ к ресурсам, а авторизация это проверка даны ли
ему эти права.
Вернемся к вашему домашнему компьютеру с архивом фотографий. На основе чего он,
находящийся в рабочей группе должен аутентифицировать вашего соседа? На основе
собственной базы учетных записей созданной на компьютере. В разных версиях Windows она
называется по-разному PWD-файлы, SAM-ульи.
Суть в другом, для того чтобы сосед получил доступ вы должны либо:
— Создать учетную запись для соседа на своем компьютере, дать ей доступ и сообщить соседу
имя записи и пароль. Но если нужно открыть доступ 10 соседям неужели создавать учетки для
всех? Можно пойти другими путями.
— Работать с соседом (или соседями) с одинаковыми учетными записями, т.е у все User с
паролем «123». Сами понимаете вариант не безопасный и глупый.
— Или открыть доступ к ресурсам группе «Все», что полностью перечеркивает безопасность и не
дает вам возможности выбирать, кто должен получить доступ, а кто нет.
А если еще при этом соседи должны заходить на компьютер друг к другу, то вам придется
создать на каждом компьютере учетную запись для каждого соседа. И при этом следить, чтобы
пароли совпадали. Если Василий Петрович решит сменить у себя на компьютере пароль для
учетной записи придется обходить оставшиеся девять и сбрасывать пароль на новый.Итак,
вторая особенность рабочей группы: компьютер участник аутентифицирует
подключающихся пользователей к его ресурсам на основе локальной базы с учетными
записями. И у каждого участника группы она своя.
Рис. 1 Классическая схема рабочей группы, где каждый компьютер содержит учетные
записи для всех пользователей сети.
Представьте теперь себе корпоративную сеть хотя бы из 50 компьютеров и сразу становится
понятно, что рабочая группа имеет место быть либо в крошечных «домашних» сетях состоящих
из 5-8 компьютеров либо у системных администраторов фанатично изображающих преданность
делу путем ежедневной беготни по местам пользователей.
Организация сети на основе домена Active Directory.
При переходе на доменную сеть схема несколько меняется. В нашей сети появляется еще один
игрок – контроллер домена Active Directory. Это сервер под управлением одной из серверных
операционных систем начиная от Windows 2000 и заканчивая Windows 2008R2 за исключением
Web-редакций. Для чего же он нужен? При аутентификация в домене использует протокол
Kerberos, который по приданию “древних Скифов” был назван в честь Цербера, трехголового
огнедышащего пса, охраняющим ворота Царства Аида.
Три головы протокола аутентификации Kerberos это:
— Клиент – компьютер/пользователь, который хочет обратиться к какому-то ресурсу.
— Сервер – компьютер, предоставляющий доступ к какому-то ресурсу.
— Доверенный посредник между клиентом и сервером, который ручается за подлинность
клиента.
Как раз этим доверенным посредником и является контроллер домена. Он хранит все учетные
записи для пользователей и компьютеров входящих в его домен. Если в рабочей группе вы для
аутентификации создавали учетные записи для каждого пользователя, то в домене Active
Directory вместе с пользовательскими учетками создаются учетные записи для компьютеров. Это
обязательно. Если на одном компьютере будет работать 3 человека, следовательно вы создадите
три учетных записи пользователя и одну учетную запись компьютера. В отличии от рабочей
группы создаются учетные записи на контроллере домена, там же и хранятся. Соответственно
каждая учетная запись создается только один раз. Сердцем контроллера домена является файл
ntds.dit, который как раз и содержит учетные записи для вашего домена (и не только записи).
Рис. 2 Схема Домена Active Directory
Теперь при загрузке компьютера человек вводит ту учетную запись и пароль которые были
прописаны на контроллере домена. Эти данные пересылаются на контроллер домена и
сравниваются с тем что было задано администратором сети при создании учетной записи. Если
имя и пароль были введены правильно, вас пускает на компьютер и ваша учетная запись
получает, что то вроде паспорта, который дает вам право находиться в сети, но не гарантирует
получения доступа к ресурсам, т.к вы прошли только первый этап аутентификацию. В
дальнейшем, когда вы захотите обратиться к ресурсам файлового сервера, вы снова обратитесь к
контроллеру домена и предоставите ему свой “паспорт”, контроллер, убедившись, что вы
аутентифицированы, выдаст вам вам “визу” с помощью которой вы сможете установить
соединение с файловым сервером. Причем данная “виза” (более правильно Билет сеанса) даст
вам право подключиться только к данному серверу и только в течении определенного времени.
(Визы увы не вечны
). Это и есть процесс авторизации.
Таким образом, можно сделать вывод, что для нормальной работы в сети ваш контроллер
домена должен быть постоянно доступен и быть готов отвечать на запросы клиентов 24 часа в
сутки. И если вдруг контроллер закашляется и потухнет, то ваши клиенты не смогут
аутентифицироваться и войти в домен, что повлечет за собой невозможность подключиться к
ресурсам вашего домена.
А что же стало с локальными учетными записями, которые были созданы до ввода наших
компьютеров в домен? Ничего, они по-прежнему существуют и каждый раз при загрузке
компьютера у пользователя есть выбор – входить с локальной учетной записью или с доменной.
Если будет выбрана локальная, то никакого обращения к контроллеру домена не будет и вход
будет осуществлен на основе локальной базы с учетными записями. Естественно при таком
варианте вы сможете подключиться только к тем ресурсам, которые расположены на вашем
компьютере, все доменные ресурсы вам будут недоступны. После ввода в домен локальные
учетные записи могут использоваться во время отключения компьютера от доменной сети либо
при решении проблем с компьютером, когда зайти под доменной учетной записью просто не
получается (пример: не настроена сетевая карта).
Рис. 3 Выбор на Windows Server 2003. Вход либо под доменной учетной записью в
домене CONTOSO, либо под локальной записью компьютера WS03SERVER.
Итак, мы четко уяснили, что для нормальной работы вашей доменной сети контроллер домена
должен быть доступен, при этом иметь созданные учетные записи для ваших пользователей и
компьютеров. А клиенты в свою очередь обязаны при входе в сеть обратиться к этому
контроллеру. Теперь необходимо понять как клиент узнает IP-адрес контроллера что бы
передать ему данные, введенные пользователем. Ведь ни имя, ни тем более IP-адрес
контроллера не задается на клиентах.
Ответ скрывается в базовом правиле Active Directory, говорящем о том что Active Directory не
функционирует без системы разрешения имен DNS. Когда вы только настраиваете первый
контроллер, служба DNS в вашей сети уже должна быть поднята. Если вдруг мастер установки
Active Directory не обнаружит работающей службы DNS, она будет установлена на этот же
сервер вместе со службой AD и должным образом сконфигурирована. В DNS будет
автоматически создана зона (точнее две но пока это не важно) с именем вашего домена и в этой
зоне появятся записи специального типа SRV, которые будут указывать на ваш контроллер.
Следовательно клиент который работает в этом домене должен быть настроен на использование
этого dns-сервера в качестве предпочитаемого. И перед обращением к контроллеру домена,
клиент осуществит запрос к DNS-серверу с просьбой сообщить ему SRV-запись для домена в
котором он работает. Таким образом он в результате получит IP-адрес нужного контроллера и
сможет переслать данные.
Важно: На практике все контроллеры домена по совместительству несут на себе службу DNS. И
причин разделять на разных серверах DNS и контроллеры домена внутри вашей сети нет.
(единственный случай где имеет смысл разделение это вынос DNS сервера за пределы вашей
сети в демилитаризованную зону)
Рис.1 Схема порядка входа клиента в сеть.
Вначале обращение к DNS. В дальнейшем получив от DNS IP-адрес контроллера, обращение к
контроллеру. В жизни это как правило один сервер. (DC+DNS)
Получается, что в вашей сети будет установлен Контроллер домена (со службой DNS на борту) и
работа всей сети зависит от него. Как быть в ситуации, если по причине “метеоритного дождя”
сервер вышел из строя? Как перестраховаться и обеспечить отказоустойчивость?
Все просто. Необходимо установить еще один контроллер в рамках уже созданного домена Active
Directory. Поднимая второй контроллер, вы создаете брата близнеца, который также как и
первый будет хранить заветный файл ntds.dit и также как и первый контроллер отвечать на
запросы клиентов. Вашим клиентам будет абсолютно все равно какой из контроллеров их
обслужил. Второй контроллер как и первый должен иметь службу DNS иначе толку от него в
случае падения первого будет очень мало. (я думаю понятно почему – AD не работает без DNS, а
если мы имеем два контроллера и только на одном служба DNS, то что будет делать второй если
первого не станет).
Когда вы создаете пользователя в Active Directory, он создается в базе (ntds.dit) того
контроллера, к которому в данный момент подключена оснастка. А если контроллеров
несколько возникает ситуация в которой один контроллер знает об изменениях, а второй еще
нет. Естественно такое безобразие долго длиться не должно и данные изменения обязаны быть
доставлены на остающийся “незнающим” контроллер. Процесс синхронизации баз контроллеров
в домене называется репликацией, которая происходит в фоном режиме без оповещения
системного администратора.
С выходом Windows Server 2008 появилась новая технология “Read Only Domain Controller” или
контроллер домена только для чтения. Особенность данного контроллера в том, что он работает
только на чтение, т.е может обсуживать ваших клиентов, но записать в его базу AD вам ничего
не удастся. Репликация в таком случае идет в одну сторону с полноценного контроллера на
контроллер домена только для чтения. Используется он в ситуациях когда необходимо
установить сервер в месте не обеспечивающего физическую безопасность.
Итак перед нам стоит задача о вводе всех наших компьютеров в домен AD, по умолчанию они
нахдятся в группе Workgroup.
1) убедится в корректной настройке tcp\ip. они должны иметь ip адреса из той же подсети что и
контроллер домена, и в настройках dns сервера должен быть прописан тот dns сервер который
хранит зону нашей AD.
Зачастую стоит задача как быть с разрешением имен за пределами вашей корпоративной сети,
если пользователи хотят получать доступ к Googlу, еще каким то веб ресурсам, а вы
прописываете в настройках dns ваш внутренний dns который о гугле понятия не имеет, если
прописать dns провайдера не будет работать AD, делается все просто, клиенты всегда в
настройках смотрят на контроллер домена, на внутренний dns сервер, а на dns сервере
настраивается перенаправление. например на dns провайдера.
теперь нужно поменять рабочую руппу на домен AD, просто в настройках компьютера вместо
названия группы прописываем имя нашего домена.
если с вышеназванным все верно то после изменения имени группы на имя домена
выскакиваетсообщение введите логин и пароль, что тэо такое? когда вы вводите комп в домен
AD там создается объект комп который связан с тем компом который мы вводим в домен.
посколько в AD что то создается, вы должны задать имя пользователя и пароль администратора
вашего домена. тк в больших организациях этим занимаются не самые главные админы,
возникает вопрос о делегировании полномочий ввода компьютеров в домен.
но в данном случае просто нужно будет ввести логин и пароль админа икомп уйдет в
перезагрузку. и потом у вас появится выбор заходить с локальной учетной записи или с
доменной.
и тд вводим остальный наши компьютеры.
Так как контроллер домена является такой важной частью частью корпоративной сети, то есть
если вдруг по какой то причине связь с контроллером домена пропадет, компы не смогут
аутентифицироваться и нормально работать в нашей сети. т е контроллер домена должен быть
всегда доступен, ка быть как застраховать себя и свою сеть?
самый простой способ установить второй контроллер домена, при его установке произойдет
копирование базы AD с первого контроллера на второй. они оба смогут аутентифицировать
пользователей и пользователю абсолютно все равно какой контроллер его аутентифицирует.
вы подключаетесь к конкретной AD к первой или ко второй, при внесении изменений вы меняете
какую то конктетную AD, то есть базы данных контроллеров домена обязаны быть
синхронизированны, это нзв репликация. это жизненно важная процедура.
Рис.2 Схема сети нашей фирмы.
Однм из главных плюсов AD является то что изначально создавалась для территориально
распеределенных сетей.
Итак два контроллера будут прекрасно сосуществовать в рамках вашей сети и все будет здорово
до одного момента. Когда к вам придет шэф и скажет: “Понимаешь %SysadminName%, мы слегка
подросли и покупаем/арендуем новый офис в другом конце города. Часть компьютеров и самое
главное Марью Ивановну из бухгалтерии мы перевозим в новое здание.” Ничего сложного
отвечаете вы, достаете из тумбочки запылившиеся Cisco, в течении следующей недели неспешно
настраиваете VPN-туннель между офисами и перевозите на новый участок часть компьютеров,
Марью Ивановну и конечно же один из контроллеров домена. В результате получаете следующую
схему сети.
А получаете вы сеть разделенную на два сегмента, каждый сегмент находится в своей подсети,
трафик между подсетями маршрутизируется и передается в зашифрованном виде по VPNтуннелю. И все замечательно домен Active Directory продолжает работать, но вы начинаете
замечать, что вход пользователя на компьютер стал занимать несколько больше времени, а судя
по детализации провайдера у вас появился лишний расход трафика. Ничего таинственного в этом
нет. Те кто внимательно читали первую часть не могли пропустить строчку “Клиенту неважно
какой контроллер домена его обслуживает”. Получается что ваши клиенты аутентифицируются
на том контроллере, чью запись SRV вернул первой DNS сервер и далеко не всегда будет тот
контроллер домена, который находится ближе. Таким образом трафик между клиентом и
контроллером будет проходить VPN-туннель основанный на медленном WAN канале вызывая
задержки при входе в сеть и лишний трафик.
Для того, чтобы все было по-взрослому необходимо сконфигурировать сайты Active Directory.
Сайт AD не имеет ничего общего с www.ya.ru и.т.д. Это логическое объединение клиентов и
контроллеров связанных высокоскоростным соединением. Ваша сеть состоит из двух участков в
каждой скорость не меньше ста мегабит, а вот эти участки связанны каналом в два мегабита или
того меньше. Получается что у вас будет два сайта (каждый филиал это сайт). И
сконфигурировав сайты Active Directory вы добьетесь того, что клиенты всегда в первую очередь
буду обращаться к тому контроллеру который находится с ними в одном сайте и если уж он не
доступен, то запрос будет послан на другой контроллер. Когда вы устанавливали первый
контроллер домена сайт с именем “default first site name” был создан автоматически и если вы
ручками не меняли настройки, Active Directory считает, что все дополнительные контроллеры и
все клиенты работают в одном сайте.
После конфигурирования сайтов контроллеры также изменят свое поведение, репликация
изменений Active Directory будет основываться на расписании, поскольку теперь AD понимает,
что она развернута в территориально распределенной сети, каналы соединяющие участи узки и
используются не только для синхронизации контроллеров.
Предвидя вопросы “Как клиент понимает, что он принадлежит к тому или иному сайту” отвечу,
что конфигурируя сайт, вы явно задаете подсети которые входят в него. Т.е если вы создали сайт
“Kazan” и закрепили за ним подсеть “192.168.5.0/24”, все клиенты имеющие IP-адрес в данной
подсети будут считать себя членами данного сайта.
И в окончании второй части раскрою “секретную команду”, позволяющую посмотреть, какой
контроллер аутентифицировал вашего клиента. Эта команда SET.
Рис. 3 Результат вывода команды SET.
Введя SET в командной строке, вы получите множество информации, но интересовать вас должен
параметр “LOGONSERVER”. При входе в домен “LOGONSERVER” будет указывать на
аутентифицировавший вас контроллер домена, а при локальном входе вместо имени
контроллера домена естественно будет стоять имя вашего клиентского компьютера.
Когда вы создавали 1ый контроллер домена, у вас создался домен Active derectory.
На слайде он называется itband.ru. Впоследствии, для обеспечения отказоустойчивости, вы
добавляли еще один контроллер домена. И он так е добавлялся в этот домен. В рамках одного
домена у вас будет общая группа «Администраторы домена».
Соответственно туда будут входить члены ИТ отдела, которые должны будут иметь высокие
привилегии в вашем домене.
К вам может прийти шеф и сказать, что мы покупаем еще одну организацию, и я хочу
интегрировать 2 сети в одну . Давайте теперь подумаем как нам быть?!
Если за новую сеть той организации, которая была куплена отвечает наш отдел ИТ, то самый
простой вариант включить компьютеры этой сети в уже существующий домен Active Directory.
Но может быть так, что у новой организации свой отдел ИТ, который администрирует
компьютеры.
Поэтому включать все в один домен было бы, ну, не очень разумно. Как минимум потому, что
группа «Администраторы домена» у нас одна, и потом, если администратор из другой компании
сделает что-то не так и повлияет на компьютеры вашей фирмы, доказать что-то будет оченьочень сложно. Поскольку группа администрирования у нас одна, надо как-то выкручиваться.
Выкручиваться я предлагаю следующим образом! Это создавать еще один домен Active derectory.
В этом домене будут свои контроллеры, своя группа «Администраторы домена», и все
компьютеры купленной фирмы будут входить туда. Но, в то же время пользователь из домена
corp.itband.ru может абсолютно спокойно подключиться к ресурсам находящимся в корневом
домене itband.ru. И, в рамках, имеющихся у него привилегий, нормально работать.
То, что мы сейчас сделали называется построением дерева Active Directory. То есть создали еще
один домен (дочерний), продолжающий пространство имен, имеющееся у нас. (itband.ru)
\Но даже если у вас один единственный домен, вы все равно имеете дерево Active Derectory.
Просто оно состоит из одного домена.
Продолжаем разговор. Шеф говорит, что купил еще одну компанию. Там тоже будет свой отдел
ИТ. Но в то же время мы очень-очень хотим, чтобы домен этой компании назывался Itcommunity.
Т.е. продолжить существующее дерево AD мы не можем. Поэтому создаем отдельное дерево под
названием Itcommunity.ru. Опять же, дерево отдельное, пространство имен разное. Но
пользователи из Itcommunity пользователи, в рамках своих прав, могут абсолютно нормально
подключаться к ресурсам, находящимся в itband.ru. Точно так же пользователи из itband.ru
могут подключаться к Itcommunity. В такой ситуации мы имеем 2 дерева, которые работают в
одном лесу AD. е
Лес AD –это границы вашей организации AD. То есть пользователь зайдя на свой компьютер не
может получить доступ за пределами нашего леса AD.( ну естественно если администратор этого
не захочет) и обратная ситуация пользователь снаружи не смогут получить доступ к нам , если
мы этого не захотим.
Для всех доменов которые работают в рамках одного леса существует общая схема: когда вы
создаете пользователя он создается определенного вида, то есть набор атрибутов, такие как:
имя, фамилия, офис, этаж и т.д. Вот где бы мы не создали нашего пользователя в в itband.ru,
Itcommunity.ru, corp.itband.ru и т.д. этот пользователь будет иметь одинаковый набор атрибутов,
если вы вдруг в домене itband.ru модифицируете набор атрибутов и добавите еще один атрибут,
он появится у всех пользователей в каждом домене, вот это называется схема. Схема AD это
описание того какие объекты вы можете создавать и как эти объекты будут выглядеть, опять же
в рамках одного леса AD пользователи аутентифицировавшиеся могут получать доступ к
ресурсам. То есть у вас файловый сервер может находиться в домене Itcommunity.ru, а
пользователь в домене corp.itband.ru, и пользователь, если он имеет права на этот сервер,
абсолютно нормально подключится. То есть лес AD логическая структура максимального размера,
то есть выше леса ничего нет. У вас есть домены, они объединяют группы компьютеров,
объединяют контроллеры, и для всех этих контроллеров и компьютеров существуют политики и
группы администраторов. И они у каждого домена свои. Но в то же время люди могут работать.
Это напоминает холдинговую компанию: каждая компания в рамках этого холдинга она вроде
как независима, там есть свой директор , там есть свой персонал, но в то же время все они
связаны между собой.
А вот если наш шеф купит компанию и скажет, вот я в принципе купил компанию, но их сеть не
должна с нашей никак пересекаться, абсолютно, появился еще один домен AD linux.org вот он у
нас будет в отдельном лесу. И наши леса никак не будут пересекаться. Это две разных
организации AD, две разных инсталляции AD.
Если вы внимательно слушали ранее, то мастер установки AD у вас не должен вызвать никаких
трудностей, давайте разбираться, самый нижний пункт:
Создать новый домен в новом лесу.
В какой ситуации мы должны выбрать такой пункт установки?
Если вы разворачиваете абсолютно новый лес, и новый домен. То есть чистая новая инcталяция
AD. Для новой фирмы, для новой компании первый контроллер домена, то есть вы пришли у вас
рабочая группа вы говорите, - здесь будет AD, запускаете мастер выбираете Создать новый
домен в новом лесу.
Дальше,
Создать новый домен в существующем лесу. Что это значит?
То есть у нас уже есть организация AD, лес AD, и в нем как минимум один контроллер домена.
Мы хотим создать еще один контроллер домена, но не добавлять его в существующий, а создать
новый домен. И вот такая галочка создать новый корень доменного дерева, если не поставим, то
наш домен будет продолжать существующее дерево. То есть построение corp.itband.ru, если
галочку поставим, то построим Itcommunity.ru.
И последняя опция добавить контроллер домена в существующий домен.
Дальше
До этого мы говорили, что контроллер домена является центром аутентификации наших
клиентов, и вообще отвечает за предоставление доступа пользователей к нашей сети, на самом
деле контроллер домена несет еще одну функцию, которая не менее важна, чем аутентификация,
эта функция fpsdf.ncz групповые политики, или управление параметрами наших компьютеров.
Если вы администрируете рабочую группу, выполняете какое то административное действие на
клиентском компьютере, это действие не коим образом не влияет на остальные компьютеры, те
если вам необходимо на 100 компьютерах прописать настройки прокси сервера , вы садитеcь за
каждый их них и прописываете прокси сервер, в домене AD все происходит гораздо проще,
Мы имеем набор компьютеров и элемент групповой политики, который создается и
конфигурируется на контроллере домена, впоследствии при загрузке клиент получает
параметры, которые вы прописали на контроллере домена. Групповые политики - это
своеобразное средство принуждения, т.е. если клиенту каким-то образом удастся поменять
параметры, при следующей загрузке или в фоновом режиме через определенный промежуток
времени, произойдет новое накатывание политик с контроллера домена. Все параметры вернутся
в то значение, которое прописано в нашем контроллере домена. Через групповые политики мы
можем делать целый набор групповых действий, сейчас содержит около 3000 параметров
которые мы можем передать клиенту, и это без Group policy preference что является заменой
скриптов.