Как создать подразделение организации в windows server

После того, как установлена роль Active Directory в домене windows server 2019, появляется возможность управления доменом. Далее необходимо создать пользователей, которые будут входить под учетными записями, группы и подразделения. 

Как создать и удалить пользователя, группу и объект в домене

• Создание пользователя в домене
• Создание группы в домене
• Создание объекта в домене
• Удаление пользователя в домене
• Удаление группы в домене
• Удаление подразделения в домене

Для создания и удаления пользователя, группы и подразделения воспользуемся средством централизованного управления сервером — Диспетчер серверов. Далее выбираем «Пользователи и компьютеры Active Directory».

Создание пользователя в домене.

1. Нажимаем «Пуск«, далее выбираем «Диспетчер серверов«.

2. В новом окне нажимаем «Средства«, в открывшемся списке выбираем «Пользователи и компьютеры Active Directory«.

3. Далее нажимаем правой клавишей на «User«, далее «Создать» — «Пользователь«.

4. Заполняем необходимые поля для создания пользователя (Имя, Фамилия, Имя входа пользователя). «Полное имя» заполнится автоматически. Затем нажимаем «Далее«. 

5. В следующем окне дважды набираем пароль для пользователя. Затем устанавливаем чекбокс на «Требовать смены пароля при следующем входе в систему«. Тогда при входе в систему пользователю будет предложено заменить текущий пароль. Нажимаем «Далее«.

6. В новом окне смотрим сводную информацию по вновь созданному пользователю и нажимаем «Готово«. Будет создан новый пользователь.

Создание группы в домене

1. Для создания группы в домене, нажимаем правой клавишей мыши на «Users«, далее «Создать» — «Группа«.

2. Задаем «Имя группы«, «Область действия группы» и «Тип группы«, далее нажимаем «ОК«. Будет создана группа.

3. Для добавления пользователей в группу, открываем пользователя, выбираем вкладку «Член групп«, нажимаем кнопку «Добавить«.

4. В новом окне вводим имя группы, в которую будет добавлен пользователь. Проверяем нажав кнопку «Проверить имена«, далее «ОК«.

5. Также возможно добавить пользователя в группу, открыв нужную группу. Далее выбираем вкладку «Члены группы«. Нажимаем «Добавить«.

6. В новом окне вводим имена пользователей, которые будут добавлены в группу. Проверяем нажав клавишу «Проверить имена«, далее «ОК«.

Добавление подразделения в домене

1. Для добавления подразделения в домене нажимаем правой клавишей мыши на домен, в появившемся меню «Создать» — «Подразделение«.

2. Задаём имя подразделения, далее «ОК«.

3. Если необходимо, в созданном подразделении создаём вложенные подразделения. Далее в созданные подразделения можно перенести или создать различные объекты (пользователи, компьютеры, группы).

Удаление пользователя

1. Обычно сначала пользователя отключают и по истечении определенного промежутка времени удаляют. Для этого выбираем пользователя, правой клавишей мыши — «Отключить учетную запись«.

2. Для удаления выбирают необходимого пользователя, далее правой клавишей мыши — «Удалить«. 

3. Появится предупреждение о том, что «Вы действительно хотите удалить Пользователь с именем…«. Нажимаем «Да» и выбранный пользователь будет удален из домена.

Удаление группы

1. Для удаления группы в домене выбираем нужную группу, нажимаем правой клавишей — «Удалить«.

2. Появится предупреждение о том, что «Вы действительно хотите удалить Группу безопасности….«. Нажимаем «Да«. Выбранная группа будет удалена из домена.

Удаление подразделения

1. Перед тем, как удалять подразделение, необходимо снять защиту, которая не дает удалить объект от случайного удаления. Если попробовать просто удалить подразделение, то появится предупреждение — «Недостаточные привилегии для удаления Departmnet1, или объект защищен от случайного удаления«.

2. Для снятия защиты в меню «Вид» выбираем «Дополнительные компоненты«.

3. Далее выбираем подразделение (объект), которое хотим удалить. Правой клавишей мыши — «Свойства«.

4. Выбираем вкладку «Объект«. Убираем чекбокс «Защитить объект от случайного удаления«, далее «ОК«.

5. Далее нажимаем правой клавишей мыши на выбранное подразделение — «Удалить«.

6. Появится предупреждение о том, что «Вы действительно хотите удалить Подразделение с именем….?«. Нажимаем «Да«. Если в выбранном объекте не будет других вложенных объектов, то подразделение будет удалено. 

7. Если объект содержит другие объекты, то появится предупреждение «Объект Department1 содержит другие объекты. Вы действительно хотите удалить объект Department1 и все содержащиеся в нем объекты?«. Нажимаем «Да» и выбранный объект будет удален с вложенными объектами.

8. Далее в окне «Active Directory — пользователи и компьютеры» в меню «Вид» возвращаем галочку напротив «Дополнительные компоненты«.

Посмотреть видео о том, как создать или удалить пользователя, группу, объект в домене можно здесь:

Windows server 2019 — установка и настройка WSUS, создание и настройка GPO

Windows server 2019 — добавление и удаление компьютера в домене

Windows server 2019 — переименование администратора домена, изменение формата выводимого имени пользователя

Windows server 2019 — установка и настройка Active Directory, DNS, DHCP 

Windows server 2019 — установка и настройка сервера печати, разворачивание МФУ с помощью GPO 

Windows server 2019 — GPO изменение экранной заставки, отключение монитора, изменение политики паролей

{/source}

Организационная единица или, как обозначено в русской версии Windows server, подразделение (Organizational Unit) — это субконтейнер в Active Directory, в который можно помещать пользователей, группы, компьютеры и другие объекты AD. Подразделения (OU) управляются администраторами домена. Вы также можете настроить делегирование управления над подразделением с помощью мастера делегирования управления. OU могут быть вложенными, и к ним можно применять групповые политики.

Создание подразделения (OU)

OU можно создать с помощью Active Directory Administrative Center (ADAC), Active Directory Users and Computers (ADUC), командной строки и PowerShell.

Создание подразделения с помощью Active Directory Administrative Center

Давайте создадим подразделение с помощью ADAC:

Запустите Active Directory Administrative Center (dsac.exe).

Переключитесь в режим просмотра дерева и разверните домен или подразделение, в котором вы хотите разместить новое.

Щелкните правой кнопкой мыши на OU или домен, выберите «New…», а затем выберите Organizational Unit.

Появится окно создания подразделения:

Введите имя OU и нажмите OK, чтобы его создать.

Создание подразделения с помощью командной строки

Чтобы создать OU с помощью cmd, запустите dsadd.exe со следующими параметрами:

dsadd.exe ou "OU=testorg,DC=office,DC=local" -desc "TestOU"

Эта строчка создаст TestOU в домене с описанием «TestOU».

Создание подразделения с помощью Windows PowerShell

Для создания нового подразделения с помощью PowerShell нам нужно использовать команду New-ADOrganizationalUnit. Запустите PowerShell от имени администратора и введите следующее:

Import-Module ActiveDirectory
New-ADOrganizationalUnit "TestOU" -Description "TestOU"

Эта строчка создаст TestOU в домене с описанием «TestOU».

Удаление подразделения AD

Подразделения по умолчанию защищены от случайного удаления. Чтобы удалить его, нам нужно снять флажок Protected from Accidental Deletion в свойствах.

Удаление подразделения с помощью Active Directory Administrative Center

Откройте Active Directory Administrative Center (dsac.exe).

Переключитесь в режим просмотра дерева, разверните свой домен и найдите OU, которое вы хотите удалить. Щелкните OU правой кнопкой мыши и выберите “Delete”.

Появится окно подтверждение удаления:

Нажмите Yes для подтверждения. Если OU содержит дочерние объекты, нажмите еще раз.

Удаление подразделения с помощью командной строки

Для удаления OU с помощью командной строки необходимо использовать инструмент dsrm.exe в cmd, запущенном от имени администратора, со следующим синтаксисом:

 dsrm.exe "OU=TestOU,DC=office,DC=local" -subtree

Эта строчка полностью удалит OU с любыми объектами внутри.

Удаление подразделения с помощью Windows PowerShell

Для удаления подразделения нам нужно использовать команду New-ADOrganizationalUnit в PowerShell запущенном от имени администратора:

Import-Module ActiveDirectory
Remove-ADObject -Identity "OU=TestOU,DC=office,DC=local" -Recursive -Confirm:$False

Эта строчка полностью удалит OU TestOU со всеми существующими в ней объектами.

Изменение подразделения AD

Иногда вам нужно изменить OU. Вот как это сделать тремя различными способами.

Изменение подразделения с помощью Active Directory Administrative Center

Откройте Active Directory Administrative Center (dsac.exe). Переключитесь в режим просмотра дерева и найдите OU, которую вам нужно изменить.

Щелкните на нем правой кнопкой мыши и выберите «Properties:«. Измените свойства, которые вам нужны. Например, вы можете изменить описание или добавить менеджера.

Снимите флажок с параметра «Защищен от случайного удаления» и нажмите OK.

Изменение подразделения с помощью командной строки

Для того чтобы изменить OU, необходимо использовать dsmod.exe в cmd от имени администратора. Но в этом случае вы можете изменить только описание.

dsmod.exe ou "OU=TestOU,DC=office,DC=local" -desc "New Description"

Здесь мы назначаем » New Description » для TestOU.

Изменение подразделения с помощью Windows PowerShell

Команда Set-ADOrganizationalUnit используется для изменения OU. Она очень мощная, в отличие от dsmod.exe. Вы можете легко изменить множество параметров OU, таких как DistinguishedName, LinkedGroupPolicyObjects или ManagedBy. Вот пример того, как изменить параметр ManagedBy в OU:

Import-Module ActiveDirectory
Set-ADOrganizationalUnit -Identity "OU=TestOU,DC=office,DC=local" -ManagedBy "CN=User,CN=Users,DC=office,DC=local"

Организационное подразделение (Organizational Unit — OU) представляет собой контейнер в домене Active Directory, который может содержать различные объекты из того же самого домена AD: другие контейнеры, группы, аккаунты пользователей и компьютеров. OU представляет собой единицу административного управления внутри домена, на который администратор может назначить объекты групповых политик и назначить разрешения другим пользователем.

Таким образом, выделим две основные задачи использования OU кроме хранения объектов Active Directory

• Делегирование управления и административных задач внутри домена другим администраторам и обычным пользователям без предоставления им прав администратора домена;
• Назначение групповых политик на все объекты (пользователей и компьютеры), которые находятся в данном подразделении (OU).

Содержание:

• Как создать Organizational Unit с помощью консоли ADUC
• Структура OU в Active Directory
• Как создать OU с помощью PowerShell
• Как делегировать полномочия на OU

Как создать Organizational Unit с помощью консоли ADUC

Для создания Organizational Unit ваша учетная запись должна обладать правами Domain Admins, или ей должны быть делегированы полномочия на создание новый OU (во всем домене или конкретном контейнере).

Откройте оснастку Active Directory Users and Conputers (ADUC – dsa.msc) и выберите контейнер домена, в котором вы хотите создать новый OU (мы создадим новый OU в корне домене). Щелкните ПКМ по имени домена и выберите New -> Organizational Unit. Укажите имя создаваемого OU.

По умолчанию все создаваемые Organizational Unit защищены от случайного удаления.

Если вы откроете свойства созданного OU, вы увидите что на вкладке Object включена опция «Protect object from accidental deletion». Чтобы вы могли удалить данный OU, нужно снять данный чекбокс. При удалении OU удаляются все другие объекты, которое содержатся в контейнере.

Структура OU в Active Directory

В небольших инфраструктурах AD (20-50 пользователей) необязательно создавать новые OU, можно все складывать в дефолтные контейнеры в корне (Users и Computer). В большой инфраструктуре желательно разделить все объекты на разные контейнеры. В основном используется иерархический дизайн Organizational Unit в AD, по географическому или функциональному принципу.

К примеру, у вашей организация имеются подразделения в разный странах и городах. Было бы логично на верхнем уровне домена создать отдельные контейнеры для каждой страны, а внутри страны отдельные контейнеры для города / региона / области. Внутри последних можно создать отдельные контейнеры для администраторов, групп, компьютеров, серверов и пользователей (см скриншот). При необходимости вы можете добавить дополнительные уровни иерархии (здания, отделы и т.д.). С такой иерархией вы сможете гибко делегировать полномочия в AD и назначать групповые политики.

Как создать OU с помощью PowerShell

Ранее для создания OU в AD можно было использовать консольную утилиту dsadd. Например, для создания OU в домене можно выполнить такую команду:

dsadd ou “ou=Kazahstan,dc=vmblog,dc=ru”

В Windows Server 2008 R2 появился отдельный модуль для работы с AD: Active Directory module для Windows PowerShell (входит в состав RSAT). Для создания Organizational Unit можно использовать командлет New-ADOrganizationalUnit. Например, создадим новый OU с именем Belarus в корне домена:

New-ADOrganizationalUnit -Name "Belarus"

Чтобы создать новый OU в существующем контейнере, выполните команду:

New-ADOrganizationalUnit -Name Minsk -Path "OU=Belarus,DC=vmblog,DC=ru" -Description "Belarus central office " -PassThru

Как делегировать полномочия на OU

При делегировании полномочия на OU другим пользователям желательно предоставлять права не непосредственно учетным записям пользователям, а административным группам. Таким образом, чтобы предоставить права на OU новому пользователю достаточно добавить его в предварительно созданную доменную группу.

Для делегирования щелкните ПКМ по OU и выберите пункт Delegate Control.

В мастере делегирования управления выберите группу пользователей, которым нужно предоставить доступ.

Затем выберите задачи администрирования, которые нужно делегировать.

В данном примере мы делегировали членам группы AccountOperators полномочия на смену паролей всех пользователей в контейнере Belarus.

В данном видео Рябухин Максим поделится практическим опытом создание и управление квотами для общих ресурсов на базе Windows Server 2016.

Весь процесс разделен на этапы. Их будет 6. Первые 5 имеют подготовительный характер, а последний, заключительный, демонстрирует результат.

1) Обзор лабораторного стенда

2) Создание общего ресурса на файловом сервере

3) Создание подразделения, пользователя и группы в Active Directory Windows Server 2016

4) Создание и конфигурирование групповой политики Windows Server 2016

5) Создание и настройка квот дискового пространства

6) Демонстрация результата применения квот на дисковое пространство сервера

Обзор лабораторного стенда

Лабораторный стенд представлен сервером на базе Windows Server 2016 и клиентской машиной на базе Windows 10. Забегая вперед, скажу, что на сервере подняты роли активной директории и файлового сервера, клиентский компьютер добавлен в домен.

Создание общего ресурса на файловом сервере

Создадим общий ресурс на файловом сервере. Для этого в диспетчере серверов перейдем в раздел общие ресурсы. Щелкнем правой кнопкой мыши и создаем ресурс, оставляя при этом параметры по умолчанию.

Создание подразделения, пользователя и группы в Active Directory Windows Server 2016

Далее создадим необходимые элементы в Active Directory Windows Server 2016. Создадим новое подразделение в домене. Откроем оснастку пользователи и компьютеры. Щелкнем на домен “vlab.edu” и создаем подразделение. Назовем его “vlab”.

В этом подразделении аналогично создадим нового пользователя “user1”. Под ним мы будем входить в домен на клиентской машине. И создадим группу “NetDrive”, в разделе групп, в последствии добавив в нее нашего пользователя. Эта группа понадобиться нам как фильтр безопасности для применения групповой политики.

Создадим объект групповой политики. Откроем оснастку «Управление групповой политикой» и в разделе объектов создадим новую. Назовем ее «AddNetDrive».

Теперь давайте изменим ее содержимое. В разделе конфигурации пользователя, необходимо открыть раздел настроек, далее конфигурации windows и выбрать сопоставление дисков. Создадим элемент «сопоставленный диск». В параметрах укажем путь к общему ресурсу, в нашем случае это \ad1share, укажем букву диска, и обязательно установим галочку «выполнять в контексте пользователя». Привяжем объект к нашему подразделению … и укажем в фильтре безопасности созданную ранее группу.

Вводим учетные данные и входим в систему под доменной учетной записью “user1”. Проверяем подключился ли у нас сетевой диск. Диск подключен. Но обращаю ваше внимание что на этом диске доступно столько же пространства сколько и на родительском диске общего файлового ресурса. Что бы не допустить переполнения, нам необходимо установить квоту. 

Создание и настройка квот дискового пространства

Давайте перейдем к ее созданию. Для того что бы создать квоту, необходимо открыть диспетчер ресурсов файлового сервера. В разделе квот создаем новую квоту и назначаем ей параметры по умолчанию, выбирая их из шаблона.

Этого вполне достаточно что бы изучить принцип действия квотирования и понять, как он функционирует. Если вас интересую вопросы по «тонкой» настройке квот, оставляйте их в комментариях под видео, постараюсь всем ответить.

Вернемся на клиентский ПК и удостоверимся что квота применена и функционирует. Доступное для использования общего ресурса пространство ограничено размером в 100МБ. И теперь чисто технический используя этот сетевой ресурс допустить переполнения родительского диска невозможно

Итог: на мой взгляд данная технология позволяет более эффективно использовать ресурсы сервера и осуществлять мониторинг и контроль рационального использования дискового пространства. К тому же она позволяет избежать ряда проблем связанных с переполнением дисков.

Обновлено 04.07.2018

Всем доброго времени суток, продолжаем наши уроки системного администрирования. Продолжим сегодня разбираться в основных объектах Active Directory. После того, как мы разобрались с планированием Active Directory, первое что нужно создать, это структуру организационных подразделений (OU). Делается это для того, чтобы системный администратор, мог делегировать права на отдельные группы объектов, объединенных по каким-то критериям, применять групповые политики, по тем же соображениям. Если вы организуете себе удобную иерархию, то у вас все будет в AD просто лафа, которая вам сэкономит много времени.

Я создам у себя в AD, структуру такого плана:

• На верху OU территориальной принадлежности. В моем случае это города
• Дальше это OU серверы, пользователи и компьютеры
• Дальше можно уже при необходимости делить на этажи, отделы и все такое, как вашей фантазии придет в голову.

Ну собственно начнем. Открываем Пуск-Администирование-ADUC

Дальше правым кликом по имени нашего домена, выбрать меню Создать-Подразделение или нажать иконку сверху.

Вводим название OU, в моем случае Город. Дальше подобным образом создаем нужное вам количество OU в нужной вам иерархии.

У меня это выглядит вот так. Есть несколько городов, которые содержат в себе дополнительные организационные подразделения:

• Пользователи
• Группы рассылок
• Группы
• Системные учетные записи
• Сервера
• Компьютеры

Если вы вдруг создали лишний OU или не в том месте, можете попробовать ее удалить или перенести, делается это правым кликом удалить или крестик сверху. Но увидите что от удаления OU защищен.

Для того чтобы, это поправить и у вас был в Active Directory порядок, идем меню «Вид-Дополнительные компоненты».

Теперь кликаем правым кликом по нужному OU и выбираем свойства.

Переходим на вкладку «Объект», и видим эту галочку, которая защищает OU. Сняв ее можно проводить манипуляции, совет как сделаете, что нужно поставьте галчку обратно.

Как видите компания Microsoft сделала процесс создания объектов в Active Directory, очень тривиальным, так как многие вещи, системный администратор просто делегирует, например, на отдел кадров, которые заводят учетные записи. Если остались вопросы, то пишите их в комментариях, рад буду пообщаться.

Материал сайта Pyatilistnik.org

Лабораторная
работа №6

Реализация
структуры подразделений

Введение
в подразделения

Введение
в подразделения

Подразделением
(organizational
unit,
OU)
называется
контейнер, спо­собствующий систематизации
объектов домена в рамках логических
административных групп. Среди объектов,
которые могут содержаться в подразделениях,
следует упомянуть учетные записи
пользователей, группы, компьютеры,
принтеры, приложения, общие папки, а
также другие вложенные подразделения,
относящиеся к локальному домену.
Графически подразделения обозначаются
пиктограммой папки с книгой. При установке
Active
Directory
на новые
контроллеры домена Microsoft
Windows
Server
2003 автоматически
создается подразделение Контроллеры
домена
(Domain
Controllers).
В ре­зультате
дополнения одних подразделений другими
формируется иерархическая структура,
а называется этот процесс вложением
подразделений. Структура подразделений
присутствует на любом контроллере
домена. При этом структуры подразделений
разных доменов совершенно независимы
друг от друга.

Существует
три основных задачи, руководствуясь
которыми администраторы создают
подразделения:

• делегирование
  административных полномочий;

• администрирование
  групповых политик;

• сокрытие
  объектов.

Создание
подразделений для делегирования
административных полномочий

Как
правило, новые подразделения создаются
с целью делегирования административных
полномочий. Под делегированием
административных полномочий понимается
передача обязанностей по управлению
определенной частью пространства имен
(например, подразделением), которые
изначально возложены на сотрудников
отдела информационных технологий,
администратору,
пользователю или группе таковых.
Операционная система Windows
Server
2003 позволяет
делегировать административные полномочия
относительно объектов, содержащихся в
подразделениях (будь то пользователи,
компьютеры или объекты ресурсов), путем
наделения администраторов конкретными
полномочиями. Для решения последней
задачи применяются списки управления
доступом подразделений.

Список
управления доступом
(access
control
list,
ACL)
— это механизм
ограничения доступа к отдельным элементам
данных или управления, исходя из
идентификационных данных пользователей
и информации о их членстве в тех или
иных группах. В каждом списке ACL
имеются
индивидуальные записи
(access
control
entries,
ACEs),
которые
определяют круг пользователей и групп,
обладающих полномочиями доступа к
данному подразделению, и регламентируют
типы доступа.

Иерархические
модели подразделений в контексте
делегирования административных
полномочий

Определившись
с тем, какие подразделения следует
выделить в компании, вы можете приступить
к формированию из них иерархической
структуры административного управления.
В рамках каждой такой структуры существует
уровень высокоуровневых подразделений,
под которым тем или иным образом
систематизируются подразделения второго
уровня. В различных ситуациях иерархические
структуры, предназначенные для
делегирования административных
полномочий, отражают следующие
организационные модели,

• Местонахождение
  Структуры
  подобного рода применяются в тех
  случаях, когда административные
  обязанности в рамках домена распределяются
  по «территориальному» признаку (рис.
  1). На иллюстрации изображены два
  подразделения высшего уровня (East
  и West),
  которые
  соответствуют установленным в компании
  contoso.com
  регионам.
  Подразделения второго уровня представляют
  физические местоположе­ния четырех
  отделений компании.

Рис.
1. Структура подразделений, построенных
по признаку местоположения

■
Бизнес-функции
Такие
структуры применяются в тех случаях,
когда административ­ные полномочия
в рамках домена распределяются в
соответствии с исполняемыми ими
бизнес-функциями (рис. 2). На рис. 2
подразделения высшего уровня Admin,
Devel
и Sales
соответствуют
крупнейшим отделам компании contoso.com.
Подразделения
второго уровня представляют более
мелкие функциональные единицы.

■
Типы
объектов Подобные
структуры применяются в тех случаях,
когда административные обязанности в
рамках домена распределяются согласно
типам управляемых объектов (рис. 3).
Изображенные на рис. 3 подразделения
высшего уровня — Users,
Computers
и Resources
— соответствуют
применяемым в компании contoso.com
типам
объектов. Подразделения второго уровня
представляют более подробные характеристики
типов объектов.

Рис.
2. Структура подразделений, построенная
в соответствии с бизнес-функциями

Рис.
3. Структура подразделения, построенная
согласно типам объектов

• Сочетания
  Структуры подобного рода применяются
  в тех случаях, когда административные
  обязанности в домене распределяются
  согласно произвольным сочетаниям
  иерархических моделей местоположения,
  бизнес-функций и типов объектов (рис.
  4). Высокоуровневые подразделения —
  West
  и
  East
  — соответствуют
  регионам, в которых расположены отделения
  компании cdntoso.com.
  Подразделения
  второго уровня представляют функциональные
  единицы компании.

Рис.
4. Структура подразделений, построенная
на основе сочетания моделей местоположения
и бизнес-функций

Типы
административных обязанностей

Подразделению
можно делегировать административные
обязанности двух типов:

• неограниченные
  полномочия управления;

• управление
  классами объектов.

По
умолчанию, неограниченными полномочиями
управления всеми объектами домена
обладают только его администраторы.
Они ответственны за создание первоначальной
структуры подразделений, исправление
допущенных ошибок и введение дополни­тельных
контроллеров домена. В большинстве
случаев следует ограничиться
предоставлением неограниченных
полномочий управления только членам
этой группы. Однако если в компании
существуют отделы, в которых требуется
определить индивидуальные структуры
подразделений и административные
модели, делегировать неограниченные
полномочия управления можно и им.

Принимая
решение о делегировании подразделению
неограниченных полномочий управления,
нужно установить, какие области компании
смогут изменять свойства подразделений,
а также создавать, удалять и изменять
объекты подразделений. Если вам кажется,
что административные возможности
разумно ограничить, можно делегировать
подразделению полномочия управления
конкретными классами объектов. Неважно,
что в схеме определено множество классов
объектов — в данном случае рассматриваются
только те из них, в которых администраторам
предстоит создавать объекты. Среди
классов подобного рода, как правило,
фигурируют объекты учетных записей
пользователей и компьютеров, групп и
подразделений. Перед делегированием
администраторам полномочий управления
классами объектов в отношении каждого
из них нужно определить:

• области
  в рамках компании, которым будет
  предоставлены неограниченные полномочия
  управления объектами данного класса
  в рассматриваемом подразделении;

• области
  в рамках компании, которым будет
  разрешено создавать объекты данного
  класса и которые, соответственно,
  получат неограниченные полномочия
  управления ими;

• области
  в рамках компании, которым будет
  разрешено изменять отдельные атрибу­ты
  существующих объектов данного класса
  или выполнять с их участием отдельные
  задачи.

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

Создание
подразделений для администрирования
групповых политик

Групповыми
политиками называются совокупности
настроек конфи­гурации пользователей
и компьютеры, которые за счет привязки
к компьютерам, сайтам, доменам и
подразделениям регулируют поведение
компьютеров пользователей. Создание
конфигурации рабочего окружения, которым
пользуются те или иные группы пользователей,
фактически сводится к созданию объектов
групповой политики (group
policy
objects,
GPOs)
— совокупностей
настроек групповой политики. Путем
связывания объектов GPO
с подразделениями
действие GPO
распространяется
либо на пользователей, либо на компьютеры,
расположенные в рамках этих подразделений.

Создание
подразделений для сокрытия объектов

Иногда
предъявляемые компаниями требования
подразумевают сокрытие отдельных
объектов в рамках подразделений (или
даже целых подразделений) от определенных
категорий пользователей. К примеру,
даже в отсутствие полномочий на чтение
атрибутов того или иного объекта
пользователь может иметь разрешение
на просмотр данных в его родительском
контейнере, и тогда сам факт существования
объекта будет ему известен. Для сокрытия
объектов в рамках домена они объединяются
в подразделения; в этих подразделениях
настраиваются полномочия Список
содержимого
(List
Contents),
которые
распространяются не на всех пользователей,
а лишь на некоторых из них.

Проектирование
структур подразделений

Проект
структуры подразделений должен быть
как можно более простым. Необходима
минимизация численности лесов и доменов.
При этом не исключено, что для выполнения
выставленных компанией административных
требований вам придется ввести
значительное количество подразделений.
Лучше всего начать с одного подразделения,
а впоследствии, по мере необходимости,
вводить новые. Иногда без многоуровневого
вложения подразделений не обойтись,
но, в принципе, нужно стараться свести
количество уровней структуры к минимуму
(их не должно быть больше семи) — в
противном случае повышается вероятность
возникновения административных проблем
и снижения производительности.

Вложение
подразделений

Чем
больше групповых политик системе
приходится оценивать, тем медленнее
проходят процессы регистрации и загрузки.
Более того — если на каждом уровне
иерархии подразделений будут установлены
разные полномочия, задача устранения
неполадок значительно усложнится. В
этом отношении гораздо более удачной
представляется структура с единообразными
(наследуемыми) полномочиями. Таким
образом, при формировании структуры
подразделений нужно стремиться
минимизировать количество вносимых в
полномочия изменений и сократить
численность требующих обработки объектов
GPO.
Кроме того,
при проектировании структур подразделений
следует иметь в виду следующие факторы.

• Подразделения
  не являются участниками системы
  безопасности. Следовательно, назначать
  полномочия доступа лишь на основе
  членства пользователей в подразделении
  нельзя. Управление доступом есть вотчина
  глобальных, универсальных и локальных
  групп домена.

• Структура
  подразделений не решает задачу навигации
  пользователей. Несмотря на то, что
  структура подразделений в рамках домена
  прозрачна для пользователей, наиболее
  эффективным способом обнаружения
  ресурсов в Active
  Directory
  остается
  отправка запросов глобальному каталогу.
  Следовательно, создавать подразделения
  нужно в расчете не на пользователей, а
  на административные задачи.

Разработка
структуры подразделений

В
любом домене может быть реализована
индивидуальная иерархия подразделений.
Если в
компании
несколько доменов, в каждом из них можно
создать отдельные структуры подразделений,
не зависящие от структур других доменов.

Создание
подразделений

Для
создания подразделений используется
консоль Active
Directory
—
пользователи и компьютеры
(Active
Directory
Users
And
Computers).

Для
того чтобы создать новое подразделение,
выполните следующие действия:

1. Выберите
   ПускАдминистрированнеАсДуе
   Directory
   —
   пользователи
   и
   компьютеры
   (StartAdministrative
   ToolsActive Directory Users And Computers).

2. Щелкните
   правой кнопкой мыши на записи, в которой
   предполагается создать новое подразделение
   (это может быть либо домен, либо другое
   подразделение), после чего выберите в
   контекстном меню СоздатьПодразделение
   (NewOrganizational
   Unit).

3. В
   поле Имя
   (Name)
   диалогового
   окна Новый
   объект — Подразделение (New
   Object—
   Organizational
   Unit)
   введите имя нового подразделения и
   щелкните кнопку ОК.

Создание
подразделений для сокрытия объектов

В
процессе создания подразделения с целью
сокрытия объектов участвуют консоль
Active
Directory
—
пользователи
и компьютеры
(Active
Directory
Users
And
Computers)
и вкладка
Безопасность
(Security)
диалогового
окна Свойства
(Properties)
рассматриваемого
подразделения. Скрывать объекты согласно
нижеследующей процедуре могут только
те пользователи, которые обладают
полномочиями изменения списков ACL
подразделения.

Для
того чтобы создать подразделение с
целью сокрытия объектов, выполните
следующие действия:

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

2. Щелкнув
   на записи нового подразделения правой
   кнопкой мыши, выберите пункт Свойства
   (Properties).

3. Оказавшись
   в диалоговом окне Свойства
   (Properties)
   подразделения,
   перейдите на вкладку Безопасность
   (Security).
   Для того чтобы просмотреть вкладку
   Безопасность
   (Security)
   диалого­вого
   окна Свойства
   (Properties)
   подразделения,
   необходимо предварительно выбрать
   в меню
   Вид
   (View)
   консоли
   Active
   Directory
   —
   пользователи
   и компьютеры
   (Active
   Directory
   Users
   And
   Computers)
   пункт
   Дополнительные
   функции (Advanced
   Features).

4. Когда
   на экране появится вкладка Безопасность
   (Security)
   диалогового
   окна Свойства
   (Properties),
   удалите из подразделения все предварительно
   установленные полномочия. Щелкните
   кнопку Дополнительно
   (Advanced).

5. Снимите
   флажок Разрешить
   наследование разрешений от родительского
   объекта к этому объекту и его дочерним
   объектам (Allow
   Inheritable
   Permissions
   From
   The
   Parent
   To
   Propagate
   To
   This
   Object
   And
   All
   Child
   Objects),
   расположенный
   в диалоговом окне Дополнительные
   параметры безопасности (Advanced
   Security
   Settings)
   подразделения.

6. При
   появлении на экране окна сообщения
   Безопасность
   (Security)
   щелкните
   кнопку Удалить
   (Remove).
   Затем
   нажмите ОК.

7. Вернувшись
   к вкладке Безопасность
   (Security)
   диалогового
   окна Свойства
   (Properties),
   выберите
   группы, которым предполагается
   предоставить неограниченные полномо­чия
   управления подразделением. Назначьте
   им эти полномочия.

8. Выберите
   группы, которым требуется предоставить
   базовые полномочия чтения относительно
   подразделения и содержащихся в нем
   данных. Назначьте им эти полномочия.

9. Назначьте
   полномочия. Щелкните кнопку ОК.

10. Переместите
    в новое подразделение объекты, которые
    требуется скрыть.

Администрирование
подразделений

Задачи,
связанные с администрированием
подразделений, помогают администратором
адаптироваться к происходящим в компании
изменениям, которые оказывают воздействие
на подразделения.

Среди
задач, связанных с администрированием
подразделений, фигурируют их переименование,
перемещение и удаление; кроме того, речь
пойдет о перемещении объектов из одного
подразделения в другое.

Переименование,
перемещение и удаление подразделений

Иногда
в процессе адаптации к меняющимся
потребностям компании подразделения
приходится переименовывать, перемещать
и удалять. Одновременно с удалением
подразделения удаляются все содержащиеся
в нем объекты.

Для
того чтобы переименовать подразделение,
выполните следующие действия:

1. Выберите
   ПускАдминистрированиеАсtive
   Directory
   —
   пользователи
   и
   компьютеры
   (StartAdministrative
   ToolsActive Directory Users And Computers).

2. Раскройте
   запись нужного домена.

3. Щелкнув
   правой кнопкой на записи подразделения,
   которое требуется переименовать,
   щелкните кнопку Переименовать
   (Rename).

4. Введите
   поверх старого имени сайта новое имя
   подразделения. Щелкните в незаполненной
   области дерева консоли.

Для
того чтобы переместить подразделение,
выполните следующие действия:

1. Выберите
   ПускАдминистрированиеАсtivе
   Directory
   — пользователи
   и
   компьютеры
   (StartAdministrative
   ToolsActive Directory Users And Computers).

2. Раскройте
   запись нужного домена.

3. Щелкните
   на записи подразделения, которое
   предполагается переместить, перета­щите
   его в нужное положение и отпустите
   кнопку мыши. В результате подразделение
   будет перенесено в новое место.

Для
того чтобы удалить подразделение,
выполните следующие действия:

1. Выберите
   ПускАдминистрированнеАсtivе
   Directory
   —
   пользователи
   и
   компьютеры
   (StartAdministrative
   Too!sActive Directory Users And Computers).

2. Раскройте
   запись домена.

3. Щелкните
   на записи подразделения, которое
   предполагается удалить, и щелкните
   кнопку Удалить
   (Delete).

4. При
   появлении окна сообщения Active
   Directory
   щелкните
   кнопку Да
   (Yes).

5. Если
   в удаляемом подразделении содержится
   объекты, на экране появится еще одно
   окно сообщения Active
   Directory.
   Если вы намерены
   удалить подразделение вместе с
   содержащимися в нем объектами, щелкните
   кнопку Да
   (Yes).

Настройка
свойств подразделений

Задание
свойств подразделения во-первых расширяет
комплекс информации о нем, а во- вторых
облегчает задачу его обнаружения.
Информация о подразделении содержится
во
вкладках
Общие
(General)
и Управляется
(Managed
By)
его
диалогового окна Свойства
(Properties).
Во вкладке
Общие
(General)
приводится
описание подразделения с указанием
адреса, города, штата или области,
ZIP-кода
или почтового индекса, страны и региона.
Если описание подразделения в этой
вкладке введено, по нему можно, проводить
поиск.

Во
вкладке Управляется
(Managed
By)
приводится
имя менеджера подразделения, название
отделения компании, в котором он работает,
его адрес, город, штат или область, страна
или регион, номера телефона и факса.
Если ввести в поле Имя
(Name)
этой вкладки
имя менеджера, предварительно указав
сведения о пользователе. В относящемся
к нему диалоговом окне Свойства
(Properties),
эта информация
будет автоматически выведена во вкладке
Управляется
(Managed
By).

Для
того чтобы задать свойства подразделения,
выполните следующие действия:

1. Выберите
   ПускАдминистрированиеАсtive
   Directory
   — пользователи
   и
   компьютеры
   (StartAdministrative
   TooIsActive Directory Users And Computers).

2. Раскройте
   запись нужного домена.

3. Щелкнув
   правой кнопкой мыши на записи искомого
   подразделения, выберите в контекстном
   меню пункт
   Свойства (Properties).

4. Перейдите
   на вкладку свойств подразделения, в
   которой планируется ввести или изменить
   информацию, и введите Значения в поле
   каждого свойства. Повторите эти действия
   для каждой вкладки, после чего щелкните
   кнопку ОК.

Перемещение
объектов между подразделениями

Если
объекты перемещаются между разными
подразделениями одного домена, разрешения,
назначенные для них напрямую, остаются
в силе; кроме того, объекты наследуют
разрешения от своих новых подразделений.
Соответственно, все разрешения, которые
ранее были унаследованы объектами от
старого подразделения, аннулируются.

Существует
несколько способов перемещения объектов
Active
Directory
между
подразделениями:

• путем
  перетаскивания;

• с
  помощью функции Переместить
  (Move)
  консоли
  Active
  Directory
  —
  пользователи
  и компьютеры
  (Active
  Directory
  Users
  And
  Computers);

• с
  привлечением утилиты с командной
  строкой Dsmove.

Перетаскивание
объектов

Операцию
перемещения объекта из одного подразделения
в другое можно свести к выделению его
записи в исходном подразделении,
перетаскиванию ее в целевое подразделение
и высвобождению кнопки мыши.

Для
того чтобы переместить объект из одного
подразделения в другое путем перетаскивания,
выполните следующие действия:

1. Выберите
   ПускАдминнстрированиеАсive
   Directory
   — пользователи
   и
   компьютер-
   (StartAdministrative
   ToolsActive Directory Users And Computers).

2. Раскройте
   запись домена и запись исходного
   подразделения.

3. Щелкните
   в правой панели на записи объекта,
   который предполагается переместить в
   другое подразделение, перетащите его
   в целевое подразделение на дереве
   консоли, а затем отпустите кнопку мыши.
   В результате объект будет перенесен в
   новое
   место.

Консоль
Active
Directory
—
пользователи
и компьютеры
(Active
Directo
Users
And
Computers)
ограничивает
возможности перемещения подразделений
границами домена. Для того чтобы
переместить подразделение из одного
домена в другой, нужно обратиться к
диспетчеру объектов Active
Directory
(утилите
Movetree.exe).

Перемещение
объектов с помощью функции Переместить

В
зависимости от задач, которые ставятся
компанией, из одного подразделения в
другое перемещаются отдельные пользователи
или целые группы. Функция Переместить
(Move)
приносит
желаемый результат безотносительно к
типу перемещаемых объектов.

Для
того чтобы переместить объект из одного
подразделения в другое с помощью функции
Переместить
(Move),
выполните
следующие действия:

1. Откройте
   консоль Active
   Directory
   —
   пользователи
   и компьютеры
   (Active
   Directo
   Users
   And
   Computers),
   щелкните
   правой кнопкой на записи объекта,
   который предполагается переместить,
   и выберите в контекстном меню пункт
   Перемесить
   (Move).

Для
того чтобы переместить несколько
объектов одновременно, во время выделения
их записей нужно удерживать клавишу
Ctrl;
после выделения
сле­дует,
как обычно, щелкнуть правой кнопкой
мыши и выбрать пункт Переместить
(Move).

1. При
   появлении на экране диалогового окна
   Переместить
   (Move)
   выбери те
   подразделение или контейнер, в которым
   предполагается разместить перемещаемый
   объект, и щелкните кнопку ОК.

Перемещение
объектов с помощью утилиты Dsmove

Dsmove
— это утилита
командной строки, предназначенная для
перемещения объектов из одного
подразделения в другое. Кроме того, она
позволяет переименовывать отдельные
объекты без их перемещения по дереву
каталогов.

Синтаксис
Dsmove
выглядит
следующим образом: dsmove
ObjectDN
[-newname
NewName]
[- newparent
ParentDN]
[{-s
Server
| -d
Domain}]
[-u
UserName]
[-p
{Password|*}]
[-q]
{- uc
| -uco
| -uci}

Назначение
всех параметров команды Dsmove
определяется
в табл. 1.

Табл.
1. Параметры команды Dsmove

Если
в задаваемое значении содержатся
пробелы, вокруг текста нужно поставить
открывающие и закрывающие кавычки
(пример: «CN=User
One,
CN=Users,
DC=Contoso,
DC=Com»).
Если
для параметра устанавливается несколько
значений, в качестве разделителей
применяются пробелы (см., например,
список составных имен).

• Для
  того чтобы переместить пользователя
  User
  One
  из подразделения
  Sales
  в подраз­деление
  Marketing,
  введите:

dsmove
<<CN=User One, 0U=Sales, DC=Contoso, DC=Com» -newparent
OU=Marketing, DC=Contoso, DC=Com

• Для
  того
  чтобы
  переименовать
  объект
  пользователя
  из
  User
  One
  в
  User
  Two,
  введите,
  dsmove
  «CN=User One, 0U=Sales, DC=Contoso, DC=Com>> -newname «User
  Two»

• Для
  того чтобы провести операции перемещения
  и переименования одновременно; введите:

dsmove
«CN=User One,0U=Sales,DC=Contoso,DC=Com» -newparent
OU=Marketing,DC=Contoso,DC=Com -newname «User Two»

Для
того чтобы переместить объекты из одного
подразделения в другое с помощь: утилиты
Dsmove,
выполните
следующие действия:

1. Выберите
   ПускКомандная
   строка (StartCommand
   Prompt).

2. При
   появлении на экране окна командной
   строки введите dsmove
   и
   укажите все необходимые параметры.

ЗАДАНИЯ

1. Создайте
   в домене contoso.com
   структуру
   подразделений.

Спланируйте
структуру подразделений в компании
Contoso
Pharmaceuticals.
У
компании
Contoso
Pharmaceuticals четыре
отделения:
Chicago,
Kansas
City, St. Paul
и
Columbus.
Кроме того,
компания подразделяется на два региона:
East
и West.
В регион East
входят отделения
Chicago
и Columbus,
а в регион
West,
соответственно,
— Kansas
City
и
St.
Paul.
В компании
существует единственный домен —
contoso.com.
Ряд административных
решений принимается отделами IT
на
местах, подотчетными региональным
отделам IT,
которые
несут ответственность за принятие
стратегических административных
решений. Ваша задача — изобразить на
схеме иерархию подразделений в рамках
домена contoso.com.

1. Создать
   в рамках домена contoso.com
   ряд подразделений
   высшего уровня.

2. Создайте
   подразделения второго уровня.

3. Переименуйте,
   удалите и переместите подразделения.

4. Установите
   свойства подразделения

5. Переместите
   объекты из одного подразделения в
   другое с помощью Переместить
   (Move)
   и
   утилиты командной строки Dsmove.

Соседние файлы в папке Бубнов

• #
• #
• #
• #
• #
• #

В Windows Server 2008 впервые появились замечательные командлеты PowerShell для работы с ActiveDirectory. Эти прекрасные, логичные, интуитивно понятные и чрезвычайно мощные инструменты вызывали у меня чувство грусти, если не сказать — «досады»: они были недоступны мне, эникейщику непрофильной конторы. Все одиннадцать сетей, которые я обслуживал были построены на базе Windows 2003 R2.

Одиннадцать несвязанных доменов в одиннадцати несвязанных сетях в разных городах, разбросанных по Дальнему востоку. И ни в одной из них — ни то, что «Семёрки», даже «Висты» нет, что ставит крест на попытках использования AD cmdlets в связке с две тысячи третьей.

Задача была сформулирована следующим образом — «создать код, способный выполнять основные операции по управлению AD из сценариев PowerShell, исполняемый в Windows XP / 2003». О том, как она была решена, читайте под хабракатом (осторожно, костыли; много текста и кода).

Контекст

В последнее время унылая, в общем-то, работа эникейщика несколько осложнялась периодом аномальной активности системных администраторов и прочих начальников по линии ИТ: они решили внести массу изменений настройки серверных служб, рабочих станций пользователей и прочего ИТ-хозяйства. Естественно, руками эникейщиков, т.к. нормальных инструментов типа Альтириса или MS SCCM у них не было.

В какой-то момент я понял, что физически не успеваю воплощать в жизнь их гениальные идеи во вверенных мне сетях, и задумался об автоматизации. Проведенный анализ рабочего времени показал, что, в первую очередь, нужно ускорить процесс тиражирования изменений в AD. Для этого, как мне тогда казалось, были необходимы Active Directory Comandlets (для работы которых требовалось закупить хотя бы одну лицензию для Windows 7).

Руководители бизнеса и сисадмины были неумолимы: «Зачем нам новая система, если старая отлично работает? Ах, она работает не отлично? Но ведь есть ты, чтобы все было замечательно! Иначе зачем тебе столько платят? Да, кстати, если тебе так нужна новая система, купи её сам на свои деньги и используй! И вообще, если не способен решать задачи бизнеса в рамках предложенного инструментария, пшёл вон из Компании!»

«Okay,» — ответил я: «идти вон» очень сильно не хотелось. В конце концов, реализация «хотелок» руководства — одно из ключевых отличий эникейщика от настоящего системного администратора. Стало ясно, что в очередной раз придется «применять смекалку» и «выкручиваться». В качестве платформы для построения системы «эрзац-управления AD» был выбран PowerShell (в основном, за легкость работы с .NET и COM).

Код

Получение уникального имени подразделения

Если вы работали с ActiveDirectory или знакомы с иной реализацией LDAP, вам известно, насколько широко используются в самых разных случаях уникальные (отличимые) имена — DNs (Distinguished Names).

Уникальное имя LDAP состоит из нескольких относительных уникальных имен — RDNs (Relative Distinguished Names), представляющих собой пары «Атрибут = Значение». Пример относительного уникального имени для подразделения (Organization Unit):

ou=Managers

Пример уникального имени для этого же подразделения:

ou=Managers,DC=example,dc=com

Эта запись говорит о том, что в домене AD с именем «example.com» на первом уровне находится подразделение «Managers».

По своему опыту могу сказать, что уникальные имена LDAP не являются интуитивно понятными и вызывают у начинающих эникейщиков некоторое затруднение. Поэтому я счел необходимым написать простую функцию, конвертирующую интуитивно понятное представление вида «example.com/Managers/Accounting/» в нотацию DN:

<#
.SYNOPSIS
	Принимает путь к OU в формате "example.com/123/456", возвращает его Distinguished Name.
	
.Description
	Корректность пути и его существование не проверяется, что позвоялет использовать функцию
	для несуществующих путей.
	ВНИМАНИЕ: имя домена должно быть полным DNS-именем, а не NEIBIOS именем (т.е. example.com, а не EXAMPLE)
	
.PARAMETER Path
    Путь, который будет сконвертирован в DN
 
.OUTPUTS	
	System.String. Возвращает Distinguished Name, соответствующий переданному пути.
#>	
Function Convert-ADPath2DN([STRING]$Path)
{	$Res = ""
	$ResOU = $null
	#Преобразуем путь к OU в OU DN
	$P = Join-Path $Path "/"
	$P = $P.Replace("","/")
	#Проверяем, получилось ли у нас что-то похожее на путь
	if ($P -match "^(?<DNS_DOMAIN_NAME>(w+.w+)+)/.+$")
	{
	
	
		$i = 0
		$DNS_DOMAIN_NAME = $Matches.DNS_DOMAIN_NAME		
		#Формируем путь по OU
		While (-not ($P -eq $DNS_DOMAIN_NAME))
		{
			$i++
			$OU = Split-Path -Leaf $P		
			$P = Split-Path -Parent $P
			If ($i -ne 1)
			{
				$ResOU = $ResOU + ","
			}
			$ResOU = $ResOU+ "OU=$OU"
		}		
	}	
	else 
	{
		$DNS_DOMAIN_NAME = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name		
	}
	
	#Меняем точки на слэши, чтобы модно было использовать удобные функции для работы с путями
	$DNS_DOMAIN_NAME = $DNS_DOMAIN_NAME.Replace(".","")
		
 
 	$DC_NAMES = @()		
	While ($DNS_DOMAIN_NAME -ne "")
	{
		$DC = Split-Path -Leaf $DNS_DOMAIN_NAME
		$DNS_DOMAIN_NAME = Split-Path -parent $DNS_DOMAIN_NAME					
		$DC_NAMES = $DC_NAMES + $DC
	}
		
		
		
	$Count = $DC_NAMES.Count	
	for ($i=$Count;$i -gt 0;$i--)
	{
		$DC = $DC_NAMES[$i - 1]
		If ($i -ne $Count)
		{
			$ResDC = $ResDC + ","
		}
		$ResDC = $ResDC+ "DC=$DC"		
		if ($ResOU -ne $null)
		{
			$Res = $ResOU + "," + $ResDC		
		}
		else
		{
			$Res = $ResDC
		}
	}
		
	Return $Res
}

Пример использования:

$Var = Convert-ADPath2DN -Path "example.com/Test/"
$Var
OU=Test,DC=example,DC=com

Хотя эта функция и не имеет непосредственного отношения к управлению ActiveDirectory, она очень полезна и используется в других функциях.

Создание подразделения организации

Каждый эникейщик должен знать, что тестировать скрипты для ActiveDirectory нужно на специально выделенном для этого тестовом домене, желательно физически отключенном от основной сети предприятия.

Не менее важным является и соблюдение политики компании по снижению расходов на ИТ (думаю, что во многих непрофильных организациях есть подобные указания), а значит, ни ПК, способного «потянуть» виртуальную машину с Windows 2003, ни, тем более, отдельного сервера, на котором можно развернуть тестовую среду, в распоряжении эникейщика, как правило, нет.

Поэтому наш герой, вопреки строгим наказам старших товарищей, тестирует свои наработки прямо в «боевой» AD. Не будем его за это осуждать, а попытаемся вместо этого — помочь.

Первое, что ему следует сделать — создать отдельное подразделение (Organization Unit), внутри которого будет происходить дальнейшая отработка навыков скриптописательства. Ну, а поскольку тема топика связана с программированием на Powershell, реализуем на нём соответствующую функцию.

Для этого нам понадобится задействовать конструктор Create класса System.DirectoryServices.DirectoryEntry. Итоговый вариант может выглядеть, например, так:

<#
.SYNOPSIS
	Создает подразделение организации в AD с заданным именем по заданному пути.	
.Description
	При создании подразделения существование родителя не проверяется, что может вызвать проблемы.
	Эта функция - служебная. Для создания подразделений рекомендуется использовать функцию 
	New-ADOrganizationUnit
	
.PARAMETER Path
	Путь к подразделению AD, в котором будем создавать OU (т.е. родителю).
	
.PARAMETER Name
	Имя создаваемого подразделения (Organization Unit).
 
.OUTPUTS	
	$null. Функция не возвращает значений.
#>	
Function New-ADOrganizationUnit_simple([STRING]$Path,[STRING]$Name)
{
	#Отключаем сообщения об исключениях, т.к. они будут возникать довольно часто.
	#основная причина - попытка создать OU, который уже существует.	
	$ErrorActionPreference = "SilentlyContinue"
	
	#Конвертируем путь в нотацию DN (см. описание функции выше)
	$OUDN = Convert-ADPath2DN -Path $Path	
	
	#Приводим путь к стандарту ADsPath
	$OUDN = "LDAP://$OUDN"	
	
	#Создаем объект, представляющий текущий домен
	$objDomain = [ADSI]$OUDN	
	
	#Создаем подразделение
	$objOU = $objDomain.Create("organizationalUnit", "ou=$Name")
	$objOU.SetInfo()
	
	#Обработка исключений
	Trap
	{
		#Если дело в том, что такое подразделение уже есть, оповестим об этом пользователя.	
		if ($_.Exception.ErrorCode -eq $SYSTEM_ERROR_CODE_OU_ALREADY_EXISTS)
		{
			Write-Host "OU $Name в $Path уже существует"
		}
	}
	
}

Явным недостатком указанной реализации является неспособность этой функции к созданию полной ветки подразделений: если вам потребуется создать OU «example.com/Users/HR/Women» в домене, в котором нет подразделения «example.com/Users«, то вы не сможете использовать её для решения данной задачи.

Точнее, сможете, но это будет крайне неудобно, т.к. придется сначала создать OU «Users», затем «HR» и только после этого — «Women».

Такой сценарий явно противоречит принципу автоматизации рутины, а потому — неприемлем. Вместо этого гораздо лучше использовать функцию, которая создаст всю ветку автоматически, например, такую:

<#
.SYNOPSIS
	Создает подразделение организации в AD по заданному пути.
	
.Description
	Будет создан не только последний элемент, но и вся родительская иерархия (все родительские подразделения).
	
.PARAMETER Path
	Путь к создаваемому подразделению.
 
.OUTPUTS	
	$null. Функция не возвращает значений.
#>	
Function New-ADOrganizationUnit ([STRING]$Path)
{
	#Проверяем, соответствует ли переданная строка пути к подразделению (example.com/Unit1/Unit2...)
	If ($Path -match "^(?<DNS_DOMAIN_NAME>(w+.w+)+)/.+$")
	{
		$i = 0	
		#Меняем направление слешей, чтобы использовать командлеты "*-Path"
		$Pth = Join-Path $Path "/"
		$Pth = $Pth.Replace("","/")
				
		$OUs = @()
		#Создаем OU по одному
		While ($Pth -ne "")
		{
			$i++
			$Pos = $Pth.IndexOf("/") 			
			
			If ($i -eq 1)
			{
				$DNS_DOMAIN_NAME = $Pth.Substring(0,$Pos)
			}
			else
			{
				$OU = $Pth.Substring(0,$Pos)			
				$OUs = $OUs + $OU
			}	
			$Pth = $Pth.Substring($Pos+1,($Pth.Length - $Pos -1))			
		}
		
		#Создаем весь путь OU
		$Pth = $DNS_DOMAIN_NAME		
		For ($i=0;$i -lt $OUs.Count;$i++)
		{	
			$OU = $OUs[$i]		
			#Вызываем предыдущую функцию для непосредственного создания OU. 
			#Подразделения создаются "сверху вниз", поэтому ситуация создания
			#дочернего подразделения при отсутствии родительского - исключена.
			New-ADOrganizationUnit_simple -Name $OU -Path $Pth
			$Pth = $Pth + "/" + $OU
				
		}		
	}	
}

Использование функции тривиально:

#Создаём подразделения "Test" и "MyFirstOU" в домене example.com
New-ADOrganizationUnit -Path "example.com/Test/MyFirstOU/" | Out-Null

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

Матёрые сисадмины, начитавшись серьёзных книг, рекомендуют своим падаванам предпочитать группы безопасности одиночным учетным записям пользователей в любых сценариях администрирования AD и, тем более, при планировании её структуры (если, конечно, падавана вообще допускают участию в решении этой задачи).

В качестве аргумента обычно приводят тиражируемость получаемых конструкций: если, например, разрешить чтение некоторой групповой политики, разрешающей запуск произвольного ПО лично директору (точнее, его учётной записи), то при возникновении необходимости предоставить такую возможность ещё кому-то, то придется все шаги по настройке прав доступа повторить заново и для другого Важного Дяди.

Если же создать группу, например, «gAllowRunAnything» и дать разрешение запускать произвольные исполняемые файлы членам этой группы, то процесс сильно упростится: достаточно будет включить учетную запись второго сотрудника в эту группу. Очевидно, такой вариант гораздо проще для эникейщика (которому придется производить эти манипуляции) и прозрачнее для системного администратора (которому потом нужно будет разобраться с тем, что там намудрил эникейщик).

Не будем спорить со старшими коллегами о важности групп, а просто реализуем возможность их создания в виде функции PowerShell:

<#
.SYNOPSIS
	Создает группу AD в заданном OU. 	
	
.Description
	Создает глобальную группу безопасности в заданном подразделении организации (Organization Unit).
	
.PARAMETER Path
	Путь к подразделению организации, в котором нужно создать группу.
	
.PARAMETER Name
	Имя создаваемой группы
	
.PARAMETER Force
	Модификатор создания пути. Если он задан, то путь к OU будет принудительно создан.
	
.OUTPUTS	
	$null. Данная функция не возвращает значений. 
#>	
Function New-ADGroup([STRING]$Path, [STRING]$Name, [System.Management.Automation.SwitchParameter]$Force)
{
	#Если указано, принудительно создаём иерархию подразделений
	$ErrorActionPreference = "SilentlyContinue"
	If ($Force -eq $true)
	{
		New-ADOrganizationUnit -Path $Path		
	}	
	#Конвертируем понятное неспециалисту представление пути в DN
	$OUDN = Convert-ADPath2DN -Path $Path
	
	#Создаем объект - представление домена
	$OUDN = "LDAP://$OUDN"
	$OU = [ADSI]"$OUDN"	
	
	#Создаем и сохраняем группу безопасности в подразделении
	$Group = $OU.Create("group", "cn=$Name")
	$Group.Put("sAMAccountName", "$Name")
	$Group.SetInfo() 
	
	#Обработка исключений
	Trap
	{
		#Наиболее часто возникающее исключение, не требующее остановки:
		# "такая группа уже существует"
		if ($_.Exception.ErrorCode -eq $SYSTEM_ERROR_CODE_OU_ALREADY_EXISTS)
		{
			Write-Host "Группа $Name в $Path уже существует"
		}
	}
}

Как видите, здесь тоже используется одна из версий конструктора Create класса System.DirectoryServices.DirectoryEntry.

И снова использование функции элементарно (я специально старался упрощать синтаксис, чтобы мои коллеги, такие же эникейщики, не имеющие специальных знаний в области организации и администрирования AD / LDAP, могли быстро разобраться):

#Создадим группу "gSales" в подразделении "Unit1". При необходимости - создадим само подразделение и все родительские подразделения.
New-ADGroup -Path "example.com/Test/MySuperScriptingResults/Fatal/Unit1" -Name "gSales" -Force 

Создание и привязка объектов групповых политик

Что такое ActiveDirectory? Википедия говорит, что это LDAP-совместимая реализация службы каталогов от MS. Системный администратор, наверное, вспомнит о лесах, доменах и доверии, безопасник — о механизме аутентификации, а эникейщик — о групповых политиках.

Почему о них? В них — вся профессиональная жизнь эникейщика: установка ПО на рабочие станции, блокировка настроек IE, не позволяющая пользователям устанавливать различные «*-Бары», SRP, решающие проблему с играми в рабочее время и даже блокировка панели задач, которую Мариванна так любит сдвинуть влево, требуя от эникейщика незамедлительно «вернуть, как было, а то работать невозможно». Впрочем, я слишком углубился в воспоминания. Думаю, с тезисом о важности GPO в Windows-сетях никто спорить не станет.

А раз GPO нужны и важны, значит следует включить некие механизмы для работы с ними в создаваемую библиотеку. Что нужно сделать с объектом GPO в первую очередь? Разумеется, создать его (очевидно, никакая операция не может предшествовать созданию):

<#
.SYNOPSIS
	Создает новый объект групповой политики в заданном домене. 
	
.Description
	Привязка созданного объекта к подразделению организации не выполняется.	Для работы используется
	COM-объект GPMC (соответственно, GPMC должна быть установлена).
	
.PARAMETER DomainDNSName
	FQDN-имя домена, в котором будет создан объект групповой политики.

.PARAMETER GPOName
	Имя создаваемого объекта групповой политики.
 
.OUTPUTS	
	GPMGPO. Возвращает созданный объект групповой политики.
#>	
Function New-GPO([STRING]$DomainDNSName,[STRING]$GPOName)
{	
	$GPM = New-Object -ComObject GPMgmt.GPM	
	#Список предопределенных констант
	$GPMConstants = $GPM.GetConstants()		
	#Объект домена
	$GPMDomain = $GPM.GetDomain($DNS_DOMAIN_NAME, $DNS_DOMAIN_NAME, $Constants.UseAnyDC)
	#Создаем GPO	
	$GPMGPO = $GPMDomain.CreateGPO()
	$GPMGPO.DisplayName = $GPOName
	
	Return $GPMGPO	
}

Эта функция создает объект GPO в репозитории объектов, и ничего более. Она полезна, но для практического исользования — недостаточна: созданный объект требуется еще привязать (Link) к подразделению. Без этого он останется как бы «неактивным» (строго говоря, он активен, для него просто не определена область воздействия). А для того, чтобы присоединить политику к OU, нужно получить её объектное представление. Логично попытаться получить его, зная имя GPO, например, так:

<#
.SYNOPSIS
	Получает COM-объект заданной GPO по её имени.	
	
.Description
	Позволяет получить пригодный для модификации объект GPO, зная её имя.	
	
.PARAMETER DomainDNSName
	FQDN-имя домена, в котором выполняется поиск GPO.

.PARAMETER GPOName
 	Имя GPO, который нужно найти.
	
.OUTPUTS	
	GPMGPO. Возвращает ссылку на COM-объект найденной GPO ( или $null, если GPO не была найдена).
#>	
Function Get-GPO([STRING]$DomainDNSName,[STRING]$GPOName)
{
	$GPMGPO = $null
	#Отключаем реакции на возникающие исключения
	$ErrorActionPreference = "SilentlyContinue"
	
	#Создаем объект, представляющий GPMC
	$GPM = New-Object -ComObject GPMgmt.GPM	
	
	#Список предопределенных констант
	$GPMConstants = $GPM.GetConstants()		
	
	#Получаем объект GPMDomain, представляющий текущий домен
	$GPMDomain = $GPM.GetDomain($DomainDNSNAme, $DomainDNSNAme, $GPMConstants.UseAnyDC)	
	
	#Ищем групповую политику в домене по её имени
	$GPMGPO = $GPMDomain.SearchGPOs($GPM.CreateSearchCriteria()) | Where-Object{$_.DisplayName -eq $GPOName}		
	
	#Возвращаем объект GPO. Если политика не найдена - вернется $null.
	Return $GPMGPO
}

Имея в арсенале механизм поиска объекта GPO по имени, можно попытаться выполнить привязку:

<#
.SYNOPSIS
	Выполняет присоединение (Link) объекта групповой политики к заданному подразделению организации (OU). 
	
.Description
	Присоединяет существующий объект GPO к существующему подразделению организации в рамках одного домена.
	Кросс-доменное присоединение не поддерживается.
	
.PARAMETER	DomainDNSName
	FQDN-имя домена, в котором выполняется операция присоединения.
	
.PARAMETER	GPOName
	Имя присоединяемого объекта GPO. Объект должен быть доступен в репозитории объектов групповых политик заданного домена.
	
.PARAMETER	OUPath
	Путь к подразделению организации, к которому нужно присоединить заданный объект GPO.
 
.OUTPUTS	
	$Null. Данная функция не возвращает результат.
#>	
Function Mount-GPOToOU ([STRING]$GPOName,[STRING]$OUPath,[STRING]$DomainDNSName)
{
	#Ищем нужный объект GPO в репозитории домена
	$GPMGPO = Get-GPO -DomainDNSName $DomainDNSName -GPOName $GPOName
	
	#Убеждаемся в том, что объект найден
	If ($GPMGPO -ne $Null)
	{	
		#Приводим путь к нотации DN
		$OUDN = Convert-ADPath2DN -Path $OUPath
		
		#Получаем представление домена в виде COM-объекта GPMC
		$GPM = New-Object -ComObject GPMgmt.GPM		
		$GPMConstants = $GPM.GetConstants()	
		$GPMDomain = $GPM.GetDomain($DomainDNSName, $DomainDNSName, $Constants.UseAnyDC)
		
		#Получаем представление интересующего подразделения
		$GPMSOM = $GPMDomain.GetSOM($OUDN)				

		#Выполняем привязку (Link) объекта GPO к подразделению
		$GPMSOM.CreateGPOLink(-1, $GPMGPO) | Out-Null		

        trap
        {
            #Исключения создаются внутри COM-объекта. У нас нет возможности определять их причину.
            #Как правило, она заключается в том, что указанный линк уже существует. Поэтому продолжаем
            continue           
        }
		
	}
	#Если объект GPO по заданному имени не найден, сообщаем пользователю и выбрасываем исключение
	else
	{
		Write-Host "Cannot find a GPO object named $GPOName"
		Throw "Cannot_find_GPO"
	}
}

Последняя функция позволяет привязывать не только свежесозданный, но и любой имеющийся в репозитории объект GPO. Одним из применений этой функции стала практика быстрого «ввода в продакшн» ранее созданных объектов групповой политики: сначала они тестировались в специальном обособленном подразделении (OU), а затем

внезапно ночью

по окончании тестирования и получения одобрения от системного администратора связывались с «боевыми» подразделениями. Было удобно.

Дотошный читатель может спросить о том, с какой целью здесь использован COM-объект GPMC. Всё очень просто: .NET предоставляет слишком высокий уровень абстракции и не позволяет выполнять некоторые операции. Например, я не нашел способа привязать GPO к подразделению, не смог выполнить импорт и экспорт GPO (см. далее) с помощью System.DirectoryServices.DirectoryEntry. Используя GPMC выполнить указанные действия не только возможно, но и относительно просто.

Импорт и экспорт настроек GPO

Итак, у нас появилась возможность создания объектов групповых политик и их привязки к подразделениям. Вспомним о целях — зачем мы вообще разрабатываем все эти функции? Чтобы помочь эникейщику в его нелёгком труде. В какой именно помощи нуждается эникейщик? В автоматизации рутинных операций, которые ему следует выполнить. Какие из них связаны с GPO? Как правило, речь идет о внесении изменений, разработанных системным администратором, в параметры GPO во множестве сетей (или в разных OU одного домена).

Обычно это происходит так: безопасник решает, что, например, в целях запрета «выноса» информации на съемных носителях следует запретить использование оных. Сисадмин подготавливает описание соответствующих настроек GPO (инструкцию) и дает эникейщикам указание растиражировать указанные изменения в своих сетях.

Изменений может быть много, и, что еще страшнее, сетей — тоже. В итоге может получиться так, что эникейщик весь день занят тиражированием, и не может вытащить застрявший листок из принтера, обеспечить нужный репертуар для аудиосистемы в уборной, найти в Сети реферат для дочки-студентки бухгалтера и, что самое ужасное, показать пользователю, где же находится та самая «любая клавиша».

И здесь на помощь нашему бойцу клавиатуры и отвёртки приходит всемогущая MS со своим механизмом импорта / экспорта настроек GPO, реализованным в рамках GPMC. Этот механизм позволяет импортировать настройки, заданные в одном GPO в другой, даже если эти два объекта групповой политики (донор и реципиент) находятся в разных доменах. Ну, а Powershell позволяет довести процесс до полного автоматизма.

Процедуру экспорта эталонной политики мы оставим системному администратору, а сами займемся импортом. Для начала рассмотрим, что же представляет из себя резервная копия GPO (сама MS настаивает на том, что это именно Backup, а не Export):

Имя папки в данном примере — это уникальный идентификатор экспортированного объекта GPO. Он нам понадобится при импорте, поэтому уже сейчас было бы неплохо научиться этот GUID получать. Рискую сойти за известного персонажа сетевого фольклора, но проще всего получить этот идентификатор просто взглянув на имя папки, например, так:

<#
.SYNOPSIS
	Позволяет определить GUID резервной копии GPO по её (копии) содержимому.	
	
.Description
	Функция просматривает список дочерних папок в резервной копии GPO, находит среди них папку, имя которой - GUID, и
	возвращает это значение в качестве GUID'а резервной копии. Идея метода в том, что корректная резервная копия GPO
	содержит одну папку с именем в виде GUID'а. Этот имя этой папки - всегда соответствует GUID'у резервной копии.
	
.PARAMETER Path
	Path - путь к папке, в которой находится резервная копия GPO. 	
 
.OUTPUTS	
	System.String. GUID резервной копии GPO, расположенной по заданному пути.	
#>	
Function Get-ExportedBackupGUID([STRING]$Path)
{
	#Проверяем, доступна ли указанная папка, если нет - выбрасываем исключение
	If (-not (Test-Path $Path))
	{
		Write-Host "Папки $Path не существует"
		Throw "Backup dir path not found"		
	}
	
	#Получаем список подпапок
	$Children = Get-ChildItem -Force -LiteralPath $Path
	
	#Ищем в среди подпапок ту, которая именована GUID'ом
	Foreach ($Child in $Children)
	{	
		If ($Child.FullName -match "^*{w{8}-(w{4}-){3}w{12}}$")
		{
			Return $Matches[0]
		}
		
	}	
	#Папка доступна, но резервных копий GPO в ней нет.
	Write-Host "В папке $Path не найдены резервные копии политик" 
	Throw "GPO Backup(s) not found"	
}

После того, как GUID экспортированного объекта GPO стал известен, можно загрузить его настройки в произвольный объект групповой политики в репозитории AD:

<#
.SYNOPSIS
	Импортирует настройки GPO из резервной копии.	
	
.Description
	Позволяет импортировать в заданный объект групповой политики настройки, сохраненные в виде резервной копии объетка GPO. 
	Речь идет именно об импрорте, а не восстановлении из резервной копии, поэтому допускается загрузка параметров из любого GPO. 
	Если целевого объекта GPO не существует, он будет создан.
	
.PARAMETER	BackupPath
	Путь к папке с резервной копией GPO

.PARAMETER 	DNS_DOMAIN_NAME
	FQDN-имя домена, в котором находится целевая политика (реципиент).

.PARAMETER	MigrationTablePath
	Не используется. Зарезервировано для будущих версий.

.PARAMETER	NewGPOName
	Имя объекта групповой политики, в который нужно загрузить настройки из резервной копии. Если этот параметр не указан, имя будет взято из
	резервной копии (т.е. параметры будут загружены в GPO с тем же именем, которое было у оригианльного GPO-донора).
	
.OUTPUTS	
	$null. Функция не возвращает значений.
#>	
Function Import-GPO ([STRING]$BackupPath, [STRING]$DNS_DOMAIN_NAME, [STRING]$MigrationTablePath, [STRING]$NewGPOName = "")
{	
	#Проверяем доступность папки с резервной копией GPO. Если она недоступна, выбрасываем исключение
	If (-not (Test-Path $BackupPath))
	{
		Write-Host "Неверно указана папка с архивом GPO: $BackupPath"
		Throw "GPO Backup path not found"
	}
	
	#Получаем COM-объект GPMC - представление домена
	$GPM = New-Object -ComObject GPMgmt.GPM		
	$GPMConstants = $GPM.GetConstants()			
	$GPMDomain = $GPM.GetDomain($DNS_DOMAIN_NAME, $DNS_DOMAIN_NAME, $Constants.UseAnyDC)
	
	#Получаем объект GPMBackupDir, представляющий папку с резервной копией
	$GPMBackupDir = $GPM.GetBackupDir($BackupPath)	
	#Определяем GUID экспортированной GPO
	$BackupGUID = Get-ExportedBackupGUID -Path $BackupPath
	#Получаем объект - представление экспортированного GPO
	$GPMBackup = $GPMBackupDir.GetBackup($BackupGUID)
	
	#Имя GPO, в которую будем импортировать настройки: если не указано, импортируем в объект с 
	#тем же именем, которое имеет резервная копия
	If ($NewGPOName -eq "")
	{
		$TargetGPOName = $GPMBackup.GPODisplayName
	}
	else
	{
		$TargetGPOName = $NewGPOName
	}
		
	#Находим в репозитории объект GPO, в который будем импортировать настройки
	$GPMGPO = Get-GPO -DomainDNSNAme $DNS_DOMAIN_NAME -GPOName $TargetGPOName
	
	#Если GPO с заданным именем не нашелся, создаем его
	If ($GPMGPO -eq $Null)	
	{
		$GPMGPO = New-GPO  -DomainDNSNAme $DNS_DOMAIN_NAME -GPOName $TargetGPOName
	}
	
	#Импортируем содержимое GPO
	$GPMGPO.Import(0, $GPMBackup) | Out-Null		
}

Обобщенным примером использования описанных функций для работы с GPO может служить следующий код:

##Дано: в папке "c:good_gpo" находится резервная копия объекта групповой политики, содержащая некие полезные настройки, созданные системным администратором.

#Задача: применить эти настройки к объектам (пользователям и компьютерам), находящимся в подразделении "example.com/TestUnits/OU1"

##Решение:

# Импортируем настройки в созданную GPO с именем "Imported_good_GPO" (он будет создан при необходиости).
Import-GPO -BackupPath "c:good_gpo" -Dns_Domain_Name "example.com"  -NewGPOName "Imported_good_GPO"

#Привязываем полученный объект к указанному OU
Mount-GPOToOU -GPOName "Imported_good_GPO" -OUPath "example.com/TestUnits/OU1" -DomainDNSName "example.com"

Доступ к GPO

Всякий, кому приходилось заниматься обслуживанием доменов Windows AD, наверняка, на определенном этапе своей карьеры сталкивался с противоречием настроек, указанных в различных объектах GPO, присоединенных к одному и тому же подразделению организации.

Например, к OU «Users», в котором находятся учетные записи Главновского И.И. (руководителя) и Логинова-Паролева В.А. (эникейщика) может быть присоединено две объекта групповых политик: «pAllow_Run_Any_Executable«, разрешающий, как следует из названия, запускать всё, что угодно, и «pDisallow_Run_Anything_Except_HelpDesk«, запрещающий запуск всего, кроме клиента хелпдеска.

Очевидно, что первый GPO должен воздействовать на учетную запись г. Главновского, не затрагивая пользователя Логинова-Паролева, а второй — наоборот. Не менее очевидно, что указанные GPO противоречат друг другу по своей сути.

Т.е. необходим некий механизм, позволяющий разграничить области действия указанных GPO. Можно, конечно, создать для одного из фигурантов персональное подразделение (OU) и привязать к нему только нужные GPO, но за подобное решение сисадмин может больно стукнуть эникейщика томиком Шетки по голове. И будет совершенно прав, ибо при таком подходе буквально за несколько месяцев структура AD разрастется так, что и сам админ не разберёт.

Гораздо более гибким (и уже поэтому — правильным) является решение, основанное на разграничении доступа к GPO. В этой схеме предусматривается создание специальных групп безопасности, регулирующих право на чтение и применение каждого объекта групповой политики, с последующим включением всех учетных записей в соответствующие группы.

Для приведенного примера можно было бы создать группу «gAllow_Run_Any_Executable«, предоставить право чтения и применения GPO «pAllow_Run_Any_Executable» только членам этой группы и включить в неё учетную запись Руководителя. С политикой для эникейщика — поступить по аналогии.

Таким образом, советы старших товарищей,

вдолбленные в голову

усвоенные в должном усердии, подталкивают нас к созданию механизма управления правами доступа к объектам GPO. Что ж, попробуем реализовать и его.

MSDN учит нас, что право доступа к объекту GPO (да, и вообще, к любому объекту AD) можно представить в виде объекта класса System.DirectoryServices.ExtendedRightAccessRule. Такой объект содержит в себе информацию о записи в правилах доступа: кому, что именно делать запрещено или разрешено:

#На PowerShell такой объект, представляющий собой запись ACE, можно создать следующим образом
$NewRule = New-Object -TypeName System.DirectoryServices.ActiveDirectoryAccessRule -ArgumentList $objTrustee, $objRihgt, $objACT

Попробуем разобраться с аргументами, переданными через ArgumentList. Начнём с очевидного: $objTrustee — это субъект безопасности, к которому относится данное правило. Например, пользователь или группа безопасности. Проще говоря, это «тот, к кому относится данное правило». В конструкции «Машка разрешила Ваське

трогать её за ляжку

вносить изменения в домен sales.example.com» субъектом безопасности будет Васька.

С точки зрения рядового эникейщика (именно эти сотрудники являются, по задумке автора, основными пользователями приведенного в этой статье набора костылей), проще всего указать субъекта безопасности по его имени. Но здесь возникает нюанс, который следует учитывать: существует довольно много стандартных участников безопасности, имена которых различны в различных языковых версиях Windows. Например, «Администратор» в англоязычной версии Windows имеет имя «Administrator».

Для решения этой проблемы в MS придумали использовать специальные идентификаторы, которые неизменны во всех локализациях ОС. Нам же, в свою очередь, осталось только научиться их использовать. Проще всего использовать перечислимый тип System.Security.Principal.WellKnownSidType:

#Получаем SID группы администраторов домена
$SID = [System.Security.Principal.WellKnownSidType]::AccountDomainAdminsSid

Если же субъект права не является Well-Known (т.е. не входит в перечень стандартных субъектов безопасности), его представление в виде объекта класса System.Security.Principal.NTAccount можно получить по имени:

[STRING]$FQDN = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name
$objTrustee = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList "$FQDN", "$Trustee"

Таким образом, представление субъекта права (кому будем разрешать / запрещать) мы создавать научились. Теперь нужно создать представление самого права, $objRihgt (что именно будем разрешать или запрещать). В приведенном выше примере речь идет о праве «вносить изменения» [в домен sales.example.com].

Как известно, количество видов разрешений («чтение», «запись», «удаление» и т.д.) — ограничено, все они входят в список допустимых значений перечислимого типа System.DirectoryServices.ActiveDirectoryRights, поэтому проще всего создать их представления с помощью соответствующего конструктора, для простоты использования обёрнутого в функцию:

<#
.SYNOPSIS
	Создает объект типа System.DirectoryServices.ActiveDirectoryRights по его имени.
	
.Description
	Использует стандартный конструктор класса System.DirectoryServices.ActiveDirectoryRights.
	Написана для удобства перехвата исключений.
	
.PARAMETER	StrRight
	Строковое наименование элемента перечисления System.DirectoryServices.ActiveDirectoryRights.
		
.OUTPUTS	
	System.DirectoryServices.ActiveDirectoryRights или $null. Возвращает объект типа System.DirectoryServices.ActiveDirectoryRights, 
	соотвтетствующий заданному имени, или $null (если такой объект не может быть создан)
#>	
Function Convert-ToAccessRight([STRING]$StrRight)
{
	$Res = $null
	$ErrorActionPreference = "SilentlyContinue"	
	$Res = [System.DirectoryServices.ActiveDirectoryRights]::$StrRight
	$ErrorActionPreference = "Stop"
	Return $Res
}

Осталось только научиться создавать представление характера действия (в примере с Машкой и Васькой речь идет о слове «разрешила«), $objACT — запрета или разрешения (ведь, каждое право может быть как «дано» (Allow), так и «отобрано» (Deny)). К счастью, и на этот раз в MSDN есть нужный перечислимый тип, System.Security.AccessControl.AccessControlType, поэтому получение представления типа правила (разрешающее оно или запрещающее) не вызывает сложностей:

#Представление разрешения
$objACT = [System.Security.AccessControl.AccessControlType]::Allow

#Представление запрета
$objACT = [System.Security.AccessControl.AccessControlType]::Deny

Рассмотрим практический пример установки специфического разрешения на доступ к объекту групповой политики:

<#
Дано:
Необходимо запретить членам группы "gForbidden_Users" чтение объекта GPO "pForbidden_GPO" в домене "Example.com"
#>

#Решение:
#Определяем полное имя домена, оно нам понадобится
[STRING]$FQDN = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name
#Создаём представление группы "gForbidden_Users", которой мы будем запрещать чтение
$objTrustee = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList "$FQDN", "gForbidden_Users"

#Создаём представление запрещающего действия
$objActDeny = [System.Security.AccessControl.AccessControlType]::Deny

#Создаём представление права чтения
$objRihgt = [System.DirectoryServices.ActiveDirectoryRights]::GenericRead
 
#Создаем правило доступа "Запретить группе 'gForbidden_Users' чтение". Чуть позже это правило применим к GPO 'gForbidden_Users'
$NewRule = New-Object -TypeName System.DirectoryServices.ActiveDirectoryAccessRule -ArgumentList $objTrustee, $objRihgt, $objACT

#Создаем представление объекта GPO по его имени.
$GPMGPO = Get-GPO -DomainDNSName "Example.com" -GPOName "pForbidden_GPO"
			
#Получаем из COM-объекта интересующей нас политики .NET-объект класса System.DirectoryServices.DirectoryEntry
[STRING]$GPOPath = $GPMGPO.Path
$objGPO = New-Object System.DirectoryServices.DirectoryEntry -ArgumentList "LDAP://$GPOPath"

#Добавляем новую запись к имеющимся правилам доступа к данному GPO
#Если нужно было бы добавить несколько правил, добавляли бы их по очереди
$objGPO.ObjectSecurity.AddAccessRule($NewRule) | Out-Null

#Сохраняем изменения.
$objGPO.CommitChanges()	| Out-Null	 

В принципе, на этом изменение прав доступа к объекту GPO AD завершено. Однако и тут есть нюанс: дело в том, каждому объекту групповой политики соответствует папка в доменной DFS (\domanname.example.comSYSVOL). И права доступа на эту папку обычно соответствуют тем, которые установлены для самого объекта GPO. Более того, если эти права будут отличаться, GPMC выдаст соответствующую ошибку:

Подобная рассинхронизация, если вдуматься, логична: в представленном выше коде мы меняем права доступа к объекту GPO, не трогая файловую систему. Можно, конечно, по аналогии добавить код, изменяющий разрешения и для папки в SYSVOL, но есть способ проще. Он основан на том, что GPMC автоматически проставляет разрешения для папки при изменении разрешений самого GPO. Таким образом достаточно внести фейковое изменение с помощью консоли GPMC, и она (консоль) сама позаботится о соответствиях:

#FQDN-имя домена
$DomainDNSName = "Example.com"
#Имя объекта GPO, для которого нужно установить соответствие разрешений
$GPOName = "pForbidden_GPO"

#Получаем представление объекта GPO по его имени
$GPMGPO = Get-GPO -DomainDNSName $DomainDNSName -GPOName $GPOName

#Получаем разрешения 
$GPOSecurityInfo = $GPMGPO.GetSecurityInfo()

#Устанавливаем те же самые, только что полученные разрешения.
#Консоль GPMC автоматически выставит такие же разрешения для папки в SYSVOL.
$GPMGPO.SetSecurityInfo($GPOSecurityInfo) | Out-Null  

Заключение

После некоторого периода «обкатки» я понял, что писать (или править написанные ранее) скрипты под каждую отдельную задачу по управлению AD — гораздо приятнее, чем решать эту же задачу вручную. Особенно, если в распоряжении есть удобный набор функций для всех операций, которые приходится выполнять.

Однако эникейщики — народ ленивый, и через некоторое время написание сценариев для выполнения заданий по администрированию AD откровенно наскучило. Появились мысли о дальнейшем развитии механизма, которые воплотились в создании «Универсального сценария администрирования», способного скачивать задания в формате XML-файлов с сервера сисадминов и выполнять эти задания без моего участия (я в это время мог спокойно выполнять свои сугубо эникейские обязанности, например, вводить логины в окна авторизации, протирать клавиатуры и т.д.).

Полное описание получившегося механизма явно выходит за рамки этой статьи. Отмечу только тот факт, что сценарий получил модульную структуру, и одним из модулей стал CM_ActiveDirectory, доступный вместе с описанием на PasteBin. Для корректной работы он, как и все остальные модули этой системы, требует загрузки модуля CM_System, который (вместе с соответствующим файлом описания) можно скачать оттуда же.

Надеюсь, читателям изложенная информация не понадобится. Хочется верить, что в 2012 году людям, которым требуется интенсивно администрировать множество доменов, компании предоставляют адекватные инструменты, и описанная контора является единственным неприятным исключением. Но если вы оказались в подобной ситуации, — не отчаивайтесь! Как видите, даже с использованием «устаревших» средств можно получать нужный результат.

Адекватных вам инструментов, коллеги!