Глава 6. Управляем Active Directory

Центральным компонентом ИТ инфраструктуры практически каждой организации выступает AD (Active Directory). AD предоставляет контроль доступа, персонализацию пользователя и системы, а также благосостояние каталога и прочих служб. Впервые Microsoft предложил AD в Windows 2000, а также улучшал и расширял этот продукт при каждом успешном выпуске Windows Server.

За прошедшие годы Microsoft превратила AD больше в торговую марку, нежели в отдельную функциональную возможность. В сердцевине пребывают AD DS (Active Directory Domain Services, Доменный службы AD). Под торговой маркой AD также присутствуют четыре доолнительных функциональных возможности Windows Server:

Служба домена Active Directory сложная и содержит множество перемещающихся частей. При помощи AD вы обладаете некой логической структурой, состоящей из лесов, доменов, деревьев доменов и OU (organizational units, Подразделения организации). Также вы обладаете физической структурой, включая DC (domain controllers, Контроллеры домена) и GC (global catalogs, Глобальные каталоги). Помимо этого имеется механизм репликаций для реплицирования объектов по вашему домену. Для более глубокого взгляда на архитектуру AD отсылаем вас к https://activereach.net/support/knowledge-base/connectivity-networking/understanding-active-directory-its-architecture/ {Прим. пер.: также см. наш перевод 2 издания Полного руководства Active Directory Дишана Франсиса}.

Лес (forest) это контейнер верхнего уровня, который размещает домены. Лес выступает границей безопасности, хотя вы можете настраивать доверие между лесами чтобы сделать возможным межсетевое взаимодействие между множеством Лесов. AD основывает имена Лесов на DNS. DC AD и клиенты AD пользуются DNS для обнаружения необходимого IP адреса DC, что превращает DNS в критически важную часть вашей инфраструктуры AD.

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

Контроллер домена (domain controller) это Windows Server, исполняющий AD и содержащий все объекты для данного домена. ВСЕ домены обязаны обладать по крайней мере одним DC, хотя рекомендуется всегда обладать по крайней мере двумя. Вы устанавливаете на своём сервере службу домена AD и затем продвигаете этот сервер превратиться в Контроллер домена.

Глобальный каталог (global catalog) это частичная реплика объектов из каждого домена в неком объекте чтобы сделать возможным поиск. К примеру, Exchange интенсивно применяет GC. Вы можете обладать такой службой GC в некоторых или во всех DC из своего леса. Как правило, вы устанавливаете такую возможность GC в то время как вы предлагаете Windows Server выступать DC.

Применяя AD DS (или AD) и PowerShell, вы можете развёртывать свои контроллеры домена в своей организации. Для установки Контроллера домена корня Леса и установки некого Леса AD воспользуйтесь рецептом Установка корневого домена Леса AD.

При установке компонентов и служб при помощи PowerShell в среде домена часто применяет удалённое взаимодействие, которое, в свою очередь, пользуется аутентификацией. Из одной из машин вы применяете удалённым взаимодействием PowerShell для осуществления действий в прочих системах. Для подобных операций вам требуются правильные учётные данные.

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

После того как у вас имеется первый DC в вашем Лесу Reskit.Org, вам следует добавить DC реплики для обеспечения надёжности операций домена. В Установке реплики контроллера домена вы добавляете в свой домен второй DC. В Установке дочернего домена вы расширяете свой лес и добавляете в свой лес некий подчинённый домен.

Active Directory пользуется некой базой данных объектов, которая содержит пользователей, компьютеры и группы. В рецепте Создание пользователей и групп AD и управление ими вы создаёте, перемещаете и удаляете объекты пользователей и групп, а также создаёте и применяете Подразделения организации. В Управлении компьютерами AD вы управляете в своём AD необходимыми компьютерами, в том числе присоединяя системы рабочей группы в свой домен. В рецепте Добавление в AD пользователей при помощи файлов CSV вы добавляете в свой AD пользователей при помощи файла CSV (comma separated values, с форматом разделённых запятой значений), содержащим подробности о пользователях.

Групповая политика выступает другой важной функциональной возможностью AD. При помощи Групповой политики вы можете определять для пользователей и компьютеров политики, который Windows автоматически применяет к своим пользователям и/ или компьютерам. В рецепте Создание объектов Групповых политик вы создаёте простой GPO (group policy object, объект Групповой политики) и наблюдаете за применением этой политики.

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

В рецептах Отчётность по компьютерам AD и Отчётность по пользователям AD вы изучаете свой AD на предмет поиска не стартовавших или не зарегистрировавшихся в вашем домене компьютеров. Также вы просматриваете учётные записи для пользователей, которые выступают участниками особых групп безопасности (например, корпоративных администраторв). Эти два рецепта помогут вам удерживать ваш AD свободным от устаревших объектов или от объектов, которые могли бы предоставлять риск безопасности.

Все рецепты в этой главе и в остальной части данной книги основываются на создании некого домена, Reskit.Org, дочернего домена, UK.Reskit.Org, трёх контроллеров домена и двух дополнительных серверов. Вот схема, показывающая применяемые серверы:

Для реализации этого Леса вы можете воспользоваться VM (virtual machines, Виртуальными машинами - ВМ) Hyper-V. Для сборки этих серверов вы также можете получить с https://github.com/doctordns/ReskitBuildScripts сценарии сборки. Каждый из рецептов данной главы выставляет для использования конкретный сервер. Вы собираете новые ВМ по мере необходимости в них.

Создавая свой первый Контроллер домена вы создаёте Лес AD. Установка Active Directoy и DNS всегда была достаточно простой. Вы всегда можете пользоваться GUI, однако применять PowerShell тоже просто.

Для создания некого DC вы начинаете с системы под управлением Windows Server. Затем в этот сервер вы добавляете компоненту AD DS Windows. Наконец, вы создаёте свой первый DC, например, отдельный контроллер домена DC1.Reskit.Org для домена Reskit.Org.

Вы выполняете этот рецепт в DC1, сервере рабочей группы, в котором у вас имеются установленными PowerShell 7 и VS Code. Вы устанавливаете этот сервер как сервер рабочей группы при помощи сценариев сборки https://github.com/doctordns/ReskitBuildScripts.

На Шаге 1 вы устанавливаете компонент AD Domain Services. Этот компонент позволяет вам развёртывать сервер в качестве Контроллера домена. Вывод этой команды выглядит подобно следующему:

На Шаге 2 вы вручную импортируете модуль ADDSDeployment. Поскольку PowerShell не поддерживает данный модуль естественным образом, данный шаг загружает этот модуль при помощи функциональной возможности Совместимости с Windows PowerShell. Получаемый от этой команды вывод выглядит аналогично приводимому ниже:

На Шаге 3 вы пользуетесь командлетом Get-Command для выявления команд, содержащихся в модуле ADDSDeployment, что отображается примерно так:

На Шаге 4 вы создаёте безопасную строку пароля для его применения в качестве пароля Администратора в создаваемом вами домене. Этот шаг не производит вывод.

Прежде чем вы продвините этот сервер в качестве DC, полезно проверить гарантию того что продвижение было успешным, а также возможным. На Шаге 5 вы пользуетесь командой Test-ADDSForestInstallation на предмет того можете ли вы продвинуть DC1 в качестве DC в домене Reskit.Org. Вывод этой команды выглядит подобно следующему:

На Шаге 6 вы продвигаете DC1 в качестве самого первого Контроллера домена в новом домене, Reskit.Org. Вывод выглядит так:

После завершения продвижения, вы можете проверить критически важные службы, требующиеся для Active Directory. Проверка служб Netloon и DNS, которые выполняются на Шаге 7 должна отображаиться примерно так:

Когда вы продвигаете DC1 вы также запрашиваете необходимое продвижение установки DNS в DC1. На Шаге 8 вы проверяете те зоны, которые созданы этим процессом продвижения DC, что отображается следующим образом:

Для завершения вашего процесса продвижения вам требуется перезапустить DC1, что вы и делаете на Шаге 9, который не производит вывода.

Те командлеты, которые позволяют вам предлагать сервер в качестве DC не установлены в сервере по умолчанию. Добавление компонента Windows Active Directory Domain Services на Шаге 1 прибавляет в вашу систему все необходимые командлеты.

На Шаге 6 вы устанавливаете AD и предписываете также что следует установить и сервер DNS - а затем вы проверяете их наличие на Шаге . На Шаге 8 вы просматриваете созданные автоматически процессом продвижения зоны DNS. При помощи параметра DomainName для Install-ADDSForest вы определяете имя домена DNS, Reskit.Org. Этот шаг создаёт необходимый домен DNS, однако в данный момент, это всё ещё не- интегрированная с AD зона. После того как вы перезапустите данную службу, данная зона должна превратиться в AD- интегрированную (и настроенную исключительно на безопасные обновления).

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

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

Вы выполняете этот рецепт в DC1, самом первом Контроллере домена из вашего домена Reskit.Org, после того как вы продвинули его на роль DC В рецепте Установка корневого домена леса AD вы создали DC1 в качестве Контроллера домена для домена Reskit.Org. Зарегистрируйтесь в качестве Reskit\Administrator.

После того как вы осуществили установку и AD выполнили перезагрузку, на Шаге 1 вы изучаете DSE AD, что выглядит примерно так:

На Шаге 2 для просмотра дальнейших сведений относительно вашего вновь созданного леса вы пользуетесь командой Get-ADForest, которая отображает следующее:

На Шаге 3 для получения дополнительной информации о домене Reskit.Org вы применяете Get-ADDomain, вывод которой таков:

Все службы AD исполняются в рамках службы Windows Netlogon. Служба ADWS это вебслужба, применяемая командлетами PowerShell AD для взаимодействия с самим AD. В качестве службы определения местоположения AD полагается на DNS, что делает возможным для клиентов AD и DC находить DC. Все три обязаны быть поднятыми и запущенными для вас чтобы вы были способны управлять AD с применением PowerShell. На Шаге 4 вы проверяете все три службы, что выглядит примерно так:

В рецепте Установка корневого домена леса AD вы активировали DC1, некий сервер Windows, на роль Контроллера домена. При выполнении этого сам процесс активации создаёт трёх пользователей домена: пользователей Administrator, Guest и krbtgt (Kerberos Ticket-Granting Ticket, Мандата на выдачу мандатов Kerberos). Вам никогда не следует прикасаться к пользователю krbtgt и обычно надлежит оставлять отключённым пользователя Guest. Для добавления безопасности вы можете переименовать своего пользователя Administrator в нечто менее очевидное и создать нового пользователя с нижним уровнем полномочий и именем Administrator.

На Шаге 5 вы изучаете всех пользователей в своём вновь созданном Лесу AD, что отображается примерно так:

Процесс активации Контроллера домена также создаёт какое- то число групп, которые могут оказаться полезными. На Шаге 6 вы изучаете различные созданные группы (а также их сферы действия), что выглядит как- то так:

Группа Корпоративных Администраторов является обладающей очень высокими полномочиями. Участники этой группы способны выполнять практически любые действия в своём домене - запускать/ останавливать службы, изменять сам AD, а также получать доступ ко всем файлам и папкам в своём домене или любой подключённой к домену системе. На Шаге 7 мы изучаем изначальных участников этой группы с наивысшими полномочиями, что отображается следующим образом:

Чтобы сделать для клиентов AD или DC AD возможным нахождение Контроллеров домена, AD полагается на DNS. Когда вы устанавливаете некий Контроллер домена, вы также можете в то же самое время установить и такую службу DNS. Когда вы устанавливаете Контроллер домена с DNS, процесс активации ADсоздаёт некоторые зоны DNS в вашей вновь создаваемой службе DNS. На Шаге 8 вы изучаете созданные в DC1 зоны DNS, что отображается как- то так:

Другой хорошей проверкой вашего вновь активированного DC является гарантия того, что вы способны разрешать DNS название своего нового домена (Reskit.Org). На Шаге 9 для проверки вы пользуетесь Resolve-DnsName, что выглядит следующим образом:

На Шаге 1 вы просматриваете DSE для своего домена. Для действий с доменом AD реализует службу каталога LDAP (Lightweight Directory Access Protocol, облегчённого протокола службы каталогов). Такая DSE это компонента каталогов LDAP и она содержит сведения относительно структуры вашего каталога. DSE доступна без необходимости аутентификации содержит дополнительные сведения относительно вашего Леса AD. Эти сведения могут оказаться полезными злоумышленникам; тем самым, рекомендуется никогда не выставлять AD DC в Интернет, если вы можете содействовать этому. Для получения дополнительных сведений относительно корневой DSE, обратитесь к https://docs.microsoft.com/windows/win32/adschema/rootdse.

Служба ADWS, которую вы отследили на Шаге 4, реализует некую веб службу. Все команды AD пользуются этой веб службой для получения сведений из вашего AD и внесения в него изменений. Когда эта служба не запущена, не работают и команды AD. Прежде чем пользоваться командлетами AD вам надлежит удостовериться в запуске этой службы.

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

В рецепте Установка корневого домена леса AD вы установили в DC1 AD. Когда у вас имеется лишь один Контроллер домена, тогда такой Контроллер домена выступает единственной точкой отказа. При единственном Контроллере домена если DC1 падает, вы не сможете управлять AD при помощи командлетов PowerShell, пользователи не будут иметь возможности регистрации. Всегда рекомендуется устанавливать по крайней мере два Контроллера домена. Когда вы применяете для своих Контроллеров домена ВМ, вам также следуете гарантировать что каждая их таких ВМ Контроллера домена пребывает в отдельном хосте виртуализации.

Для добавления второго Контроллера домена в ваш домен, вы запускаете Install-ADDSDomainController в другом хосте, например, в DC2. С точки зрения параметров этот командлет аналогичен Install-ADDSForest. Как и при создании вашего первого Контроллера домена будет полезным позаботиться о некой проверке чтобы гарантировать успешную активацию второго Контроллера домена.

В этом рецепте вы предлагаете некий хост, DC2 под роль второго Контроллера домена в вашем домене Reskit.Org. Как и при создании вашего первого Контроллера домена, после активации DC2 в качестве Контроллера домена, вам для продолжения потребуется перезапустить этот сервер. А после такого перезапуска полезно убедиться что сам процесс активации был успешным.

Вы исполняете этот рецепт на DC2, подключённом к домену сервере, в котором вы установили PowerShell 7 и VS Code. Вам надлежит зарегистрироваться в DC2 под Reskit\Administrator, участником группы Корпоративных Администраторов.

Применяя сценарии сборки Reskit.Org, вы бы собрали эту ВМ после создания DC1 в качестве Контроллера домена.

На Шаге 1 вы импортируете модуль ServerManager, что не создаёт вывод. На Шаге 2 вы убеждаетесь что вы адрес вашего Контроллера домена разрешим, причём он, на данный момент, единственный Контроллер домена в домене Reskit.Org. Это выглядит примерно так:

После того как вы разрешили IP адрес DC1, на Шаге 3 вы убеждаетесь что способны подключаться к двум ключевым портам в DC1 (445 и 389). Получаете примерно такой вывод:

Как вы уже видели при активации DC1 в качестве вашего первого Контроллера домена, прежде чем активировать соответствующий Контроллер домена, вам требуется добавить в DC2 компоненту ADDSDeployment. Получаемый на Шаге 4 вывод выглядит подобно следующему:

Расставив по своим местам все предварительно необходимые моменты, на Шаге 5 вы активируете DC2 в качестве Контроллера домена и убеждаетесь что этот Контроллер домена не перезапустился по завершению этого шага. На данном этапе нет вывода.

На Шаге 6 перед перезапуском DC2 (необходимого для завершения нашего процесса активации), вы проверяете что объекты компьютера теперь имеются в AD. Этот шаг помогает вам убедиться что DC2 теперь в верном месте в AD. Вот вывод данного этапа:

На Шаге 7 вы завершаете свой процесс активации и перезапускаете DC2. После перезапуска вам требуется зарегистрироваться в качестве Администратора домена (Reskit\Administrator). Этот шаг не производит вывода как такового.

На Шаге 8 вы изучаете все хосты в Подразделении организации (OU) Контроллеров домена, что отображается так:

На заключительном в данном рецепте Шаге 9 вы применяете командлет Get-ADDomain чтобы убедиться что DC1 и DC2 являются контроллерами домена в этом домене. Вывод на этом шаге выглядит так:

На Шаге 1 вы вручную импортируете модуль ServerManager. Как вы это наблюдали в предыдущих рецептах, данный модуль не поддерживается в PowerShell 7 естественным образом. Необходимый модуль на данном шаге загружается при помощи описанного ранее в этой книге решения Совместимости Windows PowerShell.

На Шаге 3 вы убеждаетесь что DC2 способен подключаться к DC1 по портам 445 и 389. Windows пользуется портом TCP 445 для совместных файловых ресурсов SMB. Агент групповой политики всякого присоединяемого к домену хоста применяет этот порт для выборки подробностей групповой политики из совместного ресурса SYSVOL в DC1. LDAP пользуется портом 389 для выполнения в Контроллере домена действий, например, добавления нового пользователя или проверки на участие в группе. Оба эти порта обязаны быть открытыми и способными к взаимодействию если активация DC2 была успешной.

На Шаге 6 вы выполняете выборку всех учётных записей компьютеров, в настоящее время пребывающих в вашем AD. По умолчанию, процесс активации AD DC гарантирует, что учётные записи этих хостов компьютеров теперь пребывают в Подразделении организации (OU) Контроллеров домера Такое расположение Контроллеров домена в неком Подразделении организации (OU) является существенным , поскольку позволяет применять установленные в Этом Подразделении организации настройки групповой политики к вашему новому Контроллеру домена. Если DC2 был компьютером рабочей группы и не был присоединён к вашему домену, сам процесс активации создал бы данную учётную запись в соответствующем Подразделении организации Контроллеров домена. Если DC2 уже был присоединён к домену, тогда ваш процесс активации переместил бы учётную запись его компьютера в Подразделение организации (OU) Контроллеров домена.

В данном рецепте, прежде чем активировать DC2 в качестве Контроллера домена, вы убеждаетесь что все предварительные требования пребывают на своих местах. Затем вы убеждаетесь что у вас имеются правильно настроенными ваши Лес, домен и Контроллеры домена. Достаточно просто допустить ошибки, но также легко (как правило) и исправить их. На практике это избыточная проверка, поскольку большинство активаций AD "просто работают". Такие дополнительные проверки обеспечат вам выявление и разрешение любых проблем, которые могли бы влиять на вашу активацию или вызывать неверную работу после не совсем успешной активации.

Как вы видели в рецепте Установка реплики контроллера домена, добавление некого Контроллера домена в существующий домен выполняется достаточно прямолинейно. Если только выполнены предварительные требования, такие как имеющийся где нужно DNS, сам процесс активации достаточно прост.

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

Рекомендуется требовать непрерывного пространства имён доменов, при котором соответствующий дополнительный домен выступает потомком другого имеющегося домена. В этом рецепте вы создаёте дочерний домен для созданного вами ранее домена Reskit.Org. Вы активируете свой сервер UKDC1 в качестве самого первого контроллера в новом подчинённом домене, UK.Reskit.Org. Все этапы в данном рецепте очень схожи с выполнявшимися нами в рецепте Установка реплики контроллера домена.

Вы исполняете этот рецепт в UKDC1, присоединённом к вашему домену Reskit.Org серверу, в котором у вас имеются установленными PowerShell 7 и VS Code. Вы создаёте этот сервер после того как вы установили DC1 в качестве Контроллера домена.

На Шаге 1 вы загружаете модуль ServerManager. Этот модуль не поддерживается естественным образом со стороны PowerShell 7. Данный не производящий вывода этап загружает указанный модуль при помощи решения Совместимости с Windows PowerShell.

Когда вы создаёте новый домен и новый Контроллер домена (например, при помощи UKDC1), этому серверу требуется установить соединение с держателем роли FSMO именования домена, того контроллера домена, который отвечает за изменения вашего Леса {Прим. пер.: подробнее в нашем переводе 2 издания Полного руководства Active Directory Дишана Франсиса}. На Шаге 2 вы убеждаетесь что способны достигать этого хоста, DC1, что выглядит примерно так:

На Шаге 3 вы проверяете способность подключаться кDC1 по портам 445 и 389, причём для надлежащего функционирования домена требуются оба. Вывод этого этапа таков:

На Шаге 4 вы добавляете в UKDC1 компоненты AD DS. Эти компоненты требуются для установки всех необходимых инструментов, которые вы применяете при создании своего дочернего домена. Вот вывод на этом шаге:

На Шаге 5 вы собираете хэш- таблицу параметров, которые вы применяете на следующем этапе при выполнении активации. На Шаге 6 вы пользуетесь этой хэш таблицей при вызове Install-ADDSDomain для создания подчинённого домена. Эти два шага не производят вывод. По завершению активации вы перезапускаете хост; регистрируетесь в качестве Reskit\Administrator.

Раз вы зарегистрировались, вы способны проверить подробности Леса своего AD из вашего вновь активированного Контроллера домена дочернего домена. На Шаге 7 вы пользуетесь Get-ADForest с выводом, подобным следующему:

На Шаге 8 вы изучаете подробности домена для своего вновь созданного дочернего домена. При помощи Get-ADDomain и указания в качестве цели своего нового Контроллера домена, вы наблюдаете вывод, подобный приводимому ниже:

На Шаге 2 вы убеждаетесь что DC1 выступает держателем роли FSMO именования вашего домена. Предполагая, что у вас установлены домен и Лес Get-ADDomain, как показано в данной главе, держателем этой роли выступает DC1. Вы можете вызвать Get-ADForest и получить имя соответствующего хоста из свойства DomainNamingMaster.

На Шаге 5 и на Шаге 6 вы активируете UKDC1 в качестве первого Контроллера домена в вашем новом дочернем домене, UK.Reskit.Org. В отличии от двух предыдущих активаций Контроллера домена (DC1 и DC2), на этом шаге вы позволяете Windows выполнить перезагрузку немедленно по завершению активации. Этот этап потребует некоторого времени - потенциально 10 минут или более - потому потерпите.

На Шаге 7 вы пользуетесь Get-ADForest для изучения подробностей своего Леса, сохранённого в UKDC1. Как вы можете наблюдать на Рисунке 6-27, эти подробности теперь отображают в свойствах Domains ваш новый домен (UK.Reskit.Org). Кроме того, по умолчанию, вы можете видеть что UKDC1.UK.Reskit.Org также является сервером Глобального каталога.

После создания вашего Леса/ домена и ваших Контроллеров домена мы можем приступить к управлению всеми центральными объектами в AD, а именно, пользователями, группами, компьютерами и Подразделениями организации (OU). Учётные записи пользователя и компьютера идентичны конкретному пользователю или компьютеру. Windows пользуется этими объектами чтобы позволять этим компьютерам и пользователям безопасно регистрироваться с применением содержащихся в AD паролей.

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

Подразделения организации (OU) позволяют вам разбивать на части пользователей, компьютеры и группы по отдельным контейнерам OU. Подразделение организации (OU) снабжает вам существенными ролями в вашем AD. Первейшим выступает делегирование роли. Вы можете делегировать имеющееся управление любого OU (и его дочерних Подразделений организации) чтобы они заботились о различных группах. Например, вы можете создать некое Подразделение организации (OU) верхнего уровня с названием Code в домене Reskit.Org. Затем вы можете делегировать полномочия для всех объектов из этого Подразделения организации (OU) в некую группу, скажем, в UKAdmins, позволяя всем участникам группы управлять объектами в этом Подразделении организации UK и во всех подлежащих.

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

В данном рецепте вы изучаете объекты пользователя и группы AD. В следующем рецепте, Управление компьютерами AD вы изучите управление компьютерами AD. А в рецепте Создание объектов Групповых политик вы назначите некую Групповую политику созданному в данном рецепте Подразделении организации (OU).

В данном рецепте вы работаете в DC1, Контроллере домена из домена Reskit.Org. В этом хосте у вас имеются установленными PowerShell 7 и VS Code.

Для создания некого нового пользователя AD вы применяете командлет New-ADUser. По причине объёма количество сведений, которые вы желаете сохранять для всякого создаваемого вами пользователя, общее число параметров, которое вам может потребоваться передавать в New-ADUser может составлять очень длинный код строк. Чтобы избежать этого, вы создаёте некую таблицу хэшей из параметров и значений параметров, а затем пользуетесь ею для создания соответствующего пользователя. На Шаге 1 вы создаёте такую таблицу, что не производит вывод.

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

На Шаге 3 вы создаёте новое Подразделение организации, IT (ИТ), что также не создаёт вывод. Вы пользуетесь этим Подразделением организации для сбора объектов пользователей и компьютеров ИТ подразделения Reskit.Org. Затем, на Шаге 4, который также не создаёт вывод, вы перемещаете этих только что созданных двух пользователей в своё Подразделение организации ИТ.

Вместо того чтобы создавать некого пользователя (который по умолчанию помещается в качестве нового объекта пользователя в контейнер Users вашего AD) и далее перемещаете его в некое Подразделение организации, вы можете создавать нового пользователя непосредственно в неком Подразделении организации (OU). На Шаге 5 вы создаёте третьего нового пользователя непосредственно в Подразделении организации ИТ, что также не производит вывод.

На не создающем вывода Шаге 6 вы создаёте двух дополнительных пользователей, которыми вы воспользуетесь позднее в данном рецепте. При помощи Шага 7 вы применяете Get-ADUser для выборки всех объектов пользователей из своего домена Reskit.Org, что выглядит подобно следующему:

Вы можете удалять любого пользователя AD активируя Remove-ADUser. Имеются два широко применяемых шаблона для удаления некого пользователя. Первый шаблон вовлекает применение Get-ADUser для получения того пользователя, которого вы желаете удалить и затем пробрасываете его конвейером в Remove-ADUser. Такой шаблон подходит для командной строки, в которой вам всегда надлежит убеждаться что вы обладаете правильным пользователем, прежде чем удалите такого пользователя. Второй, возможно, более подходящий для сценариев, состоит в удалении соответствующего пользователя одним действием (и имеющий риск удаление неверного пользователя). На Шаге 8 вы пользуетесь шаблоном Get | Remove для получения необходимого пользователя с последующим его удалением. На Шаге 9 вы удаляете указываемого пользователя напрямую, определяя идентичность этого пользователя при вызове Remove-ADUser. Ни Шаг 8, ни Шаг 9 не продуцируют вывод.

На Шаге 10 вы обновляете объект некого пользователя новыми/ обновляемыми свойствами. Этот шаг не производит вывод. Чтобы увидеть полученные изменения, на Шаге 11 вы можете воспользоваться Get-ADUser и просмотреть имеющиеся свойства своего обновлённого пользователя, что отображено ниже:

AD допускает два типа учётных записей групп, причём они оба способны содержать как пользователей, так и группы: безопасность (security) и распределение (distribution). Как правило, вы применяете группы распределения для систем электронной почты. К примеру, Exchange, применяет их для реализации списков распространения. Для назначения полномочий и прав вы пользуетесь группами безопасности. Например, когда вы разрешаете какой- то группе обладать доступом к каким- то файлу или папке, тогда по умолчанию все участники подобной группы обладают такими полномочиями доступа. При установке полномочий и прав рекомендуется пользоваться группами.

Группы безопасности в AD обладают тремя сферами действия, которые предлагают различные функциональные возможности в плане участия и того как вы их применяете для назначения полномочий и прав. Для получения дополнительных сведений относительно сфер действия и групп безопасности AD в целом отсылаем вас к https://docs.microsoft.com/windows/security/identity-protection/access-control/active-directory-security-groups.

На Шаге 12 вы создаёте новую локальную группу домена, IT Team (ИТ команда). На Шаге 13 вы добавляете всех имеющихся в Подразделении организации ИТ пользователей в эту группу ИТ команды. Ни один из шагов не производит вывода. На Шаге 14 вы получаете и отображаете всех участников своей группы ИТ команды, что выглядит следующим образом:

На Шаге 7 вы видите всех пользователей своего домена Reskit.Org. Обратите внимание на пользователя UK$. Этот пользователь относится к дочернему домену (UK.Reskit.Org). Как таковой, он не является реальным пользователем. Символ $ в самом конце имени этого пользователя указывает на то, что это скрытая учётная запись пользователя для поддержки имеющегося дочернего домена. Не поддавайтесь искушению навести порядок и удалить эту учётную запись пользователя - это могло бы нарушить структуру вашего дочернего домена.

Как вы увидели из данного рецепта, те командлеты, которые вы применяете для добавления или изменения пользователя, группы или Подразделения организации (OU) не производят вывод, что сокращает вывод, через который вам следует продираться. Некоторые командлеты и наборы командлетов будут выдавать подробности вывода создаваемых, обновляемых или возможно удаляемых объектов. Рассматривайте такое отличие вывода для командлетов AD в качестве функциональной возможности.

Объекты компьютера AD представляют присоединённые к домену компьютеры, которые могут применять свой домен для аутентификации регистрации пользователя. Прежде чем вы можете зарегистрироваться в качестве пользователя домена, например, Reskit\JerryG, ваш компьютер обязан быть участником домена. Когда присоединённый к домену компьютер запускается, он взаимодействует с каким- то Контроллером домена для собственной аутентификации. По- существу, этот компьютер регистрируется в своём домене и создаёт безопасный канал к своему Контроллеру домена. После того как Windows устанавливает этот безопасный канал, Windows способен зарегистрировать некого пользователя. Под своим капотом Windows применяет безопасный канал для обсуждения условий регистрации пользователя.

В этом рецепте вы работаете с компьютерами AD и добавляете SRV1 в домен Reskit.Org.

Вы исполняете этот рецепт в DC1, Контроллере домена в домене Reskit.Org. Этот рецепт также использует SRV1. Этот хост запускается как не присоединённый к домену хост Windows Server 2022 (который вы применяли в ранних главах в этой главе). Также вы применяете UKDC1 (Контроллер домена в домене UK.Reskit.Org). В каждом из этих хостов вам надлежит иметь установленными PowerShell 7 и VS Code.

На Шаге 1 для получения соответствующих объектов компьютера, определённых до сих пор в вашем AD вы пользуетесь командлетом Get-ADComputer, что выглядит следующим образом:

На Шаге 2 вы получаете все компьютеры из домена UK.Reskit.Org из Контроллера домена этого домена, UKDC1, что показано ниже:

На Шаге 3 вы создаёте в домене Reskit новый компьютер, Wolf, или Wolf.Reskit.Org. Этот шаг не создаёт вывод.

Для подготовки добавления SRV1 в домен за одну операцию, на Шаге 4 вы создаёте объект полномочий для пользователя с правами Администратора SRV1. Для этих полномочий вы пользуетесь общим паролем, применяемой в этой книге. Не ограничивайте себя от применения вашей собственной схемы паролей. Вам требуется этот объект полномочий по той причине, что SRV1 в настоящий момент компьютер рабочей группы. На Шаге 5 вы создаёте некий блок сценария, который, когда вы его выполните, добавляет компьютер в домен Reskit.Org. Ни один из этих шагов не производит никакого вывода.

На Шаге 6 вы активируете этот блок сценария в SRV1, что добавляет SRV1 в домен Reskit.Org. Вот вывод на этом шаге:

Для завершения этого процесса присоединения SRV1 к домену Reskit.Org, на Шаге 7 вы перезапускаете SRV1, что не создаёт вывода.

После того как SRV1 выполнил свой перезапуск, на Шаге 8 вы просматриваете все те учётные записи, которые теперь находятся в домене Reskit.Org, что выглядит следующим образом:

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

На Шаге 3 вы выполняете предварительную подготовку компьютера Wolf. Имеющий возможность зарегистрироваться в Wolf пользователь способен затем применять Add-Computer (или GUI) для добавления этого хоста в домен. На Шаге 4 вы добавляете компьютер с применением полномочий Администратора домена.

Spiceworks это исключительная площадка для ИТ профессионалов для получения дополнительных сведений и решения их проблем. Spiceworks обладает интенсивным форум поддержки PowerShell, к торому вы можете получить доступ через https://community.spiceworks.com/programming/powershell.

Наиболее часто задаваемый вопрос (имеющий ответ) таков: Как мне добавить множество пользователей при помощи некого файла входных данных? Данный рецепт представляет этот ответ. Вы начинаете с файла CSV, содержащего сведения о тех пользователях, которых вы намерены добавить. Затем вы исполняете это рецепт и добавляете этих пользователей.

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

Вы исполняете этот рецепт в SRV1, присоединённом к домену сервере, в котором вы уже установили PowerShell 7 и VS Code. Зарегистрируйтесь от имени Reskit\Administrator. Вам также нужно иметь поднятыми и работающими DC1 и DC2.

Данный рецепт создаёт и применяет файл CSV. В качестве альтернативы, для применения на Шаге 1 в этом рецепте вы также можете выгрузить этот файл CS из GitHub. Если вы выгрузите его из GitHub, проверьте что вы сохранили его в C:\Foo\Users.CSV.

На Шаге 1, который не производит вывода, вы создаёте простой файл CSV, который вы сохраняете в C:\Foo\Users.CSV

На Шаге 2 вы импортируете этот вновь созданный файл CSV и отображаете содержащиеся в нём сведения, что выглядит следующим образом:

На Шаге 3 вы добавляете всех содержащихся в CSV пользователей в AD. Вы добавляете пользователей при помощи New-ADUser, который не производит вывод. Этот шаг добавляет некий вывод, чтобы показать каких пользователей вы добавили, что выглядит так:

На завершающем, Шаге 4, этого рецепта, вы пользуетесь Get-ADUser для просмотра всех пользователей из домена Reskit.Org. Вот вывод этого этапа:

На Шаге 3 вы добавляете всех пользователей на основании своего CSV. Вы добавляете этих пользователей явным образом в Подразделение организации (OU) ИТ применяя параметр -Path (как то предписывает таблица хэшей $Prop). При промышленном применении в случае, когда добавляемые пользователи могут располагаться в различных Подразделения организации, вам следует расширить свой CSV чтобы он содержал название Подразделения организации назначения, в которое вы желаете добавлять каждого пользователя.

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

В этом рецепте вы для начала создаёте некий GPO внутри своего AD. Затем вы настраиваете этот GPO, например, включения компьютера в Подразделение организации (OU) ИТ для применения сценариев PowerShell этих систем или настройку особых экранных заставок. Существуют тысячи установок, которые вы можете настраивать для некого пользователя или компьютера через Групповую политику. Microsoft создал электронную таблицу. которая перечисляет все установки политик, которые вы можете выгружать с https://www.microsoft.com/en-us/download/101451. На момент написания этих строк, эта электронная таблица покрывает файлы шаблонов Групповой политики, доставляемых при помощи Windows 10 обновления мая 2020 (то есть Windows 10 2004).

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

Имеющаяся конфигурация вашего GPO обычно имеет результатом выработку Windows сведений, к которым может получать доступ агент групповой политики хоста (тот код, который применяет имеющиеся объекты GPO). Эти сведения сообщают имеющемуся агенту как работать. Настройки выполняются через шаблоны при помощи установок реестра внутри файлов Registry.POL. Соответствующий агент Групповой политики получает подробности соответствующей политики из совместного ресурса SYSVOL в Контроллере домена и применяет их всякий раз когда некий пользователь регистрируется в системе или покидает её, либо когда стартует или останавливается. Соответствующий модуль Групповой политики также предоставляет возможность создания привлекательных отчётов, описывающих соответствующие GPO.

Вы исполняете этот рецепт в DC1, Контроллере домена из домена Reskit.Org. Вы создали этот Контроллер домена в рецепте Установка корневого домена леса AD и позднее создали соответствующее Подразделение организации ИТ. Кроме того, прежде чем продолжать, убедитесь, что вы создали в DC1 папку C:\Foo.

Обратите внимание, что как и многие относящиеся к AD командлеты, те командлеты, которые вы применяете для управления GPO не производят много вывода.

На Шаге 1 вы создаёте новый GPO в домене Reskit.Org. Этот шаг создаёт пустой GPO. Этот GPO ещё пока не привязан ни к какому Подразделению организации, а потому не применяются.

На Шаге 2 вы отключаете настройки пользователя, что позволяет соответствующему клиенту GPO игнорировать любые настройки пользователя. Поступая так мы можем заставлять клиента обрабатывать GPO слегка быстрее.

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

На Шаге 4 и на Шаге 5 вы создаёте некий новый GPO настраиваете таймаут экранной заставки на 900 секунд.

На Шаге 6 вы присоединяете эти два GPO к Подразделению организации ИТ. Пока вы не привяжете эти GPO к некому Подразделению организации (OU, или ко всему домену, или к некой площадке домена), обработка GPO игнорирует такой GPO.

В данном рецепте Шаги с 1 по Шаг 6 не производят вывод.

На Шаге 7 вы применяете Get-GPO для возврата сведений относительно всех GPO из нашего домена, что выглядит следующим образом:

На Шаге 8 вы вырабатываете отчёт GPO и отображаете его при помощи команды Get-GPOReport. Эта команда не производит вывод, однако при помощи Invoke-Command вы просматриваете полученный отчёт в своём браузере по умолчанию, что отображено ниже:

На Шаге 9 вы пользуетесь Get-GPOReport для возврата некоторого отчёта обо всех GPO в домене в неком формате XML, что не производит вывод.

На Шаге 10 вы проводите итерации по всем возвращённым XML и производит простой отчёт по GPO и тому где они присоединены, что выглядит следующим образом:

На Шаге 8 вы наблюдаете вывод из командлета Get-GPOReport. На момент написания этих строк браузер Edge не выстраивает получаемый вывод настолько привлекательно как бы вам этого хотелось. То что может выглядеть как ошибка, это просто то, как Edge (и снова, на момент написания этих строк) отрисовывает этот документ HTML.

На Шаге 9 и на Шаге 10 вы создаёте свой минимальный отчёт. На Шаге 9 вы пользуетесь командой Get-GPOReport для получения некого отчёта для всех GPO в вашем домене, возвращаемый в качестве XML. На Шаге 10 вы выдаёте отчёт по всем GPO в домене Reskit с применением составляющего форматирования строк .NET при помощи оператора -f .

Применение составляющего форматирования .NET позволяет вам создавать привлекательный вывод когда возвращаемые неким командлетом объекты не пребывают в виде для применения напрямую Format-Table. На Шаге 9, например, возвращаемый XML возвращает подробности и ссылках GPO в качестве свойств, которые на самом деле некий объект с подчинёнными свойствами. Для создания привлекательного вывода вы создаёте некую форматированную строку, которую вы применяете для отображения каждой из строк своего отчёта, включая заглавные строки отчёта. Вначале вы применяете эту форматированную строку для создания двух строк заголовка отчёта этого отчёта. Затем, для каждого GPO в возвращаемом списке вы получаете значение имени GPO, к какому Подразделению организации (OU) присоединён это GPO, включён он или нет и будет ли этот GPO не перекрываем. Наконец, вы применяете соответствующую строку формата для вывода отдельной строки отчёта. В большинстве случаев эти индивидуальные отчёты проще читать и содержат только те сведения, которые вы полагаете полезными.

В качестве альтернативы создания отчёта, как показано на Шаге 9, вы можете создавать индивидуальные таблицы хэшей и применять их для создания некого персонального объекта для своего отчёта.

Командлеты Format-Table и Format-List являются наиболее применяемыми когда каждый объект обладает простыми свойствами. Когда некий объект обладает свойствами, которые являются неким объектом со свойствами, эти команды форматирования не обтёсывают такие (подчинённые) свойства. В данном случае вы должны получать все подробности ссылок GPO вручную для каждого GPO и вырабатывать строки своего отчёта на основании таких результатов. Хотя данная схема отчёта пристойно работает для этого конкретного набора GPO, когда у вас имеются более длинные названия или более глубокие ссылки на Подразделения организаций (OU), вам может потребоваться дополнительная регулировка тех строк формата,которые вы установили на Шаге 10.

AD для поддержки своих операций применяет специальную базу данных. Эта база данных является распределённой базой данных со множеством хозяев и со сходимостью - каждый Контроллер домена хранит эту базу данных в файле C:\Windows\NTDS\ntds.dit.

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

Репликации AD основываются на разделах - срезах общей базы данных. AD способен реплицировать каждый раздел по- отдельности. В AD имеются различные разделы:

Имеются два типа репликаций: репликации внутри площадки и репликации между площадками. Репликации внутри площадки происходят между Контроллерами домена в заданной площадке AD, в то время как репликации между площадками происходят между различными площадками.

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

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

В большинстве организаций меньшего размера (таких как Reskit.Org), репликации устанавливаются и работают автоматически. Однако, для крупных и распределённых организаций репликации могут быть достаточно сложными , ибо вы пытаетесь балансировать между современностью против стоимости географической полосы пропускания. Когда у вас имеются Контроллеры домена на различных континентах, вы желаете собирать такие изменения и выполнять их все за раз, допустим, каждые четыре часа. Однако это означает, что ваши удалённые Контроллеры домена имели бы на этот период времени устаревшие сведения. В качестве отлитого в бронзе правила, вам надлежит проектировать репликации так, чтобы они происходили быстрее чем некая персона способна перелететь между двумя площадками AD, обслуживаемыми Контроллером домена. Когда вы изменяете свой пароль, скажем, в Лондоне, тогда, если изменения происходят в течении 12 часов когда, допустим, вы летите в Брисбен, Австралия, ваши Австралийские Контроллеры домена содержат реплицированный пароль. Тем самым, вы сможете зарегистрироваться со своим новым паролем непосредственно сразу после посадки в Брисбене.

Для получения дополнительных сведений относительно понятий репликации AD обращайтесь к https://docs.microsoft.com/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts.

Для любой крупной организации проектирование и планирование AD имеют жизненно важное значение - для получения дополнительных сведений относительно необходимой работы по планированию и проектированию обращайтесь к https://docs.microsoft.com/windows-server/identity/ad-ds/plan/ad-ds-design-and-planning.

Традиционно вы применяет большое число консольных приложений Win32 для управления репликациями и устранением их неполадок, включая repadmin.exe, которая повсеместно заменяет более раннюю команду replmon.exe. Для получения дополнительных сведений относительно команды repadmin.exe (и репликаций) отсылаем вас к https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/getting-over-replmon/ba-p/396687.

С появлением PowerShell и модуля AD PowerShell вы теперь можете выполнять большинство функций repadmin.exe при помощи командлетов PowerShell. В этом рецепте вы изучите некоторые подробности репликаций AD с применением PowerShell.

Вы исполняете этот рецепт в DC1, Контроллере домена из домена Reskit.Org Вам также надлежит обладать DC2 и UKDC1 доступными и подключёнными к Интернету на момент начала тестирования этого рецепта. Вам следует обладать в этих хостах установленными PowerShell 7 и VS Code.

На Шаге 1 вы обнаруживаете партнёров по репликации для DC1. При двух Контроллерах домена в вашем домене Reskit (DC1 и DC2) вывод с этого шага выглядит так:

На Шаге 2 вы проверяете метаданные имеющихся партнёров по репликации для домена в целом, что отображено ниже:

На Шаге 3 вы изучаете метаданные для участников группы. Вы осуществляете этот шаг после создания группы безопасности IT Team (Команда ИТ) и её заполнения и на данный момент вывод выглядит следующим образом:

На Шаге 4, который не производит вывод, вы изменяете эту группу, добавляя двух участников. Затем вы удаляете одного из них из этой группы. Под своим капотом этот этап обновляет членство в этой группе (три раза), что вырабатывает обмен репликациями для реплицирования изменений членства в группе из DC1 в DC2.

На Шаге 5 вы повторно изучаете метаданные членства в проверочной группе чтобы увидеть воздействие Шага 4, что отображается так:

На Шаге 6 вы создаёте отчёт об отказах в репликациях с выводом, подобным следующему:

На Шаге 7 вы имитируете проблему со связью посредством остановки DC2 и дождёмся полного останова системы. На Шаге 8 вы вносите изменения в некого пользователя (в DC1). Эти шаги не производят вывод, хотя Шаг 7 имеет результатом попытку AD выполнить репликацию об изменении учётной записи пользователя в DC2.

На Шаге 9 вы применяете команду repadmin.exe для выработки итогового отчёта по репликациям, что выглядит следующим образом:

На Шаге 2 вы обнаруживаете партнёров по репликациям своего домена. В домене со всего двумя Контроллерами домена вы можете ожидать что каждый из Контроллеров домена выступает входным партнёром по репликации для другого имеющегося Контроллера домена и именно ото отображает соответствующий рисунок.

На Шагах с 3 по 5 вы изучаете возникающие изменения в данных репликаций до и после внесения изменений участия в группе. Отличным способом для выявления таких конкретных изменений для участия в группе безопасности, включая удаление участника, является командлет Get-ADReplicationAttributeMetadata. Воспроизводимые сведения не сообщают вам кто произвёл эти изменения в той системе, в которой они появились. Однако знание о том, что кто- то внёс изменения и когда они произошли это существенные первые шаги.

На Шаге 7 вы создаёте потенциальную проблему, останавливая DC2. На Шаге 8 вы производите изменения в AD через DC1, что обычно очень быстро реплицируется в DC2. Однако поскольку DC2 остановлен, эта репликация не происходит.

На Шаге 9 вы пользуетесь консольным приложением repadmin.exe для выработки итогового отчёта по репликации, отображающего что DC1 не способен выполнить взаимодействие с DC2. Порой, более старые инструменты, такие как repadmin.exe, производят лучший вывод чем имеющиеся командлеты. Для применения в консоли и когда вы желаете получить простой итоговый отчёт о репликации, repadmin.exe всё ещё великолепный инструмент.

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

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

Данный рецепт создаёт некий отчёт по компьютерам, которые не регистрировались или длительное время не перезапускались.

Одна из проблем при разработке подобных этому сценариев состоит в создании имеющих значение тестовых данных. Если вы желаете создать тестовый отчёт, отображающий систему, которая не регистрировалась более 6 месяцев, для получения необходимых сведений вам, возможно, придётся ждать 6 месяцев. Этот рецепт показывает как обойти это в целях тестирования.

Вы исполняете этот рецепт в DC1, Контроллере домена из домена Reskit, в котором вы установили PowerShell 7 и VS Code. Кроме того, вы должны были завершить все более ранние рецепты, которые создавали некоторые объекты компьютеров внутри вашего AD, включая Создание пользователей и групп AD и управление ими.

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

На Шаге 1 вы создаёте три учётных записи AD компьютера. Вы пользуетесь этими учётными записями для имитации компьютеров, которые длительное время не подключались, тем самым позволяя вам просматривать полный отчёт. Если вы повторно выполните этот рецепт или этот шаг, добавление этих учётных записей произведёт ошибки, поскольку эти учётные записи уже имеются. Вы можете изменить этот шаг чтобы проверять и обнаруживать что такие учётные записи уже имеются перед их созданием.

На Шаге 2 вы создаёте три константы времени, представляющие значение времени для 7 дней тому назад, 1месяца назад и 6 месяцев назад. Этот шаг позволяет вам проверять что заданная учётная запись пользователя не регистрировалась на протяжении этого периода времени.

На Шаге 3 вы создаёте новую функцию, Get-RKComputers. Эта функция возвращает список всех учётных записей компьютеров из AD совместно с их последним временем регистрации.

На Шаге 4 вы начинаете свой отчёт с создания заголовка отчёта.

На Шаге 5 вы вызываете Get-RKComputers и заполняете массив $Computers (всеми доступными компьютерами).

На Шагах с 6 по Шаг 9 вы добавляете подробности в отчёт по компьютерам, которые никогда не регистрировались на протяжении более 6 месяцев, не входили в систему 1 - 6 месяцев и компьютеры, которые не регистрировались от 1 недели до 1 месяца.

На окончательном, Шаге 10 , вы отображаете полученный отчёт, созданный на предыдущих шагах. Вот как выглядит получаемый вывод:

На Шаге 3 вы создали некую функцию для получения учётных записей компьютеров в AD. Эта функция возвращает некий массив названий компьютеров и значения дат последнего входа в систему. В промышленном решении вы можете усовершенствовать эту функцию чтобы возвращать учётные записи компьютеров только из определённых Подразделений организаций. Вы также можете расширить эту функцию на проверку того находится ли этот компьютер в сети, проверяя сетевое соединение с этим компьютером или проверяя имеется ли запись A DNS для определённого компьютера для выявления устаревших учётных записей компьютеров.

На Шагах с 5 по Шаг 9 вы создаёте отчёт, добавляя текстовые строки в переменную $RKReport. Выполняя это, вам надлежит добавлять символы CRLF перед и после каждой строки текста при добавлении каждой из строк в свой отчёт. Обеспечение того, чтобы каждая строка отчёта начиналась в правильном месте, может быть сложной задачей при создании отчётов с использованием техники, показанной в этом рецепте.

В своём предыдущем рецепте вы создали некий отчёт по учётным записям компьютеров, которые могут представлять интерес. Учётные записи пользователей и групп также неплохо отслеживать. Когда некий пользователь не регистрировался на протяжении разумного периода времени, его учётная запись может вызывать риск безопасности. Точно также, некий пользователь, участвующий в какой- то учётной записи с привилегиями (скажем, Корпоративного Администратора), может использоваться каким- то злоумышленником. ИТ специалистам известно, насколько легче просто поместить кого- то в группу с наивысшими полномочиями, чем настраивать более детализированные полномочия при помощи чего- то подобного Just Enough Administration (см. рецепт Реализация Just Enough Administration (JEA) в Главе 8, Реализация корпоративной безопасности).

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

В этом рецепте вы получите все учётные записи из своего AD и изучите потенциальные риски безопасности.

В этом рецепте вы работаете в DC1, Контроллере домена из домена Reskit.Org после выполнения рецептов из данной главы. В этом хосте у вас также установлены PowerShell 7 и VS Code.

В данном рецепте все шаги, за исключением последнего, не производят вывод. Эти шаги создают отчёт, который вы и просматриваете на окончательном шаге.

На Шаге 1 вы создаёте функцию, Get-ReskitUser, которая производит набор объектов пользователей, относящихся ко всем пользователям из вашего AD. На Шаге 2 вы применяете эту функцию для заполнения массива, $RKUsers, содержащего пользователей и необходимые для вашего отчёта подробности.

На Шаге 3 вы собираете для своего отчёта заголовок, а затем, на Шаге 4, вы собираете раздел отчёта по отключённым пользователям. В применяете Шаг 4 для добавления подробностей по отключённым учётным записям пользователей. На Шаге 5 вы добавляете подробности по пользователям, которые не регистрировались на протяжении последних дней. На Шаге 6 вы добавляете сведения по пользователям, которые имели более чем пять неудачных попыток регистрации.

Окончательный раздел вашего отчёта перечисляет пользователей, которые являются участниками критически важных групп AD. На Шаге 7 вы создаёте некий заголовок для этого раздела. Далее, на Шаге 8 и на Шаге 9 вы добавляете подробности участников этих групп.

По завершению всех этапов, на Шаге 10 вы можете просмотреть получаемый в этом отчёте вывод, который выглядит как- то так

На Шаге 1 вы создаёте функцию выборки пользователей. Эта функция позволяет вам изменять формат необходимых вам сведений по мере необходимости, тем самым улучшая получаемый вывод вашего отчёта.

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

На Шаге 9 вы наблюдаете окончательный отчёт. Обратите внимание, что пользователь Malcolm одновременно обладает высоким числом неудачных попыток регистрации и в некоторые момент времени регистрировался успешно. Когда вы регистрируетесь с применением учётной записи домена и неким неверным паролем, AD отвергает такую регистрацию и увеличивает счётчик плохих попыток. После того как регистрация оказалась успешной, однако, такой счётчик неудач обнуляется.