Руководство. базовая локальная среда active directory и среда azure ad

Предварительные требования

Для работы с этим учебником требуется следующее:

Компьютер с установленным Hyper-V. Рекомендуется использовать компьютер с ОС Windows 10 или Windows Server 2016.
Внешний сетевой адаптер для связи виртуальной машины с Интернетом.
Подписка Azure
Копия Windows Server 2016.
Microsoft .NET Framework 4.7.1

Примечание

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

Эти скрипты создают общую среду Active Directory перед установкой агента облачной подготовки Azure AD Connect. Они актуальны для всех руководств.

Копии сценариев PowerShell, используемых в этом руководстве, можно найти на сайте GitHub здесь.

Настройка DNS в локальном домене

Чтобы правильно разрешить управляемый домен из локальной среды, может потребоваться добавить серверы пересылки к существующим DNS-серверам. Если в локальной среде не настроено взаимодействие с управляемым доменом, выполните следующие действия на рабочей станции управления для локального домена AD DS.

Выберите ПускАдминистрированиеDNS.

Выберите зону DNS, например aaddscontoso.com.

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

Укажите другой DNS-домен, например contoso.com, а затем введите IP-адреса DNS-серверов для этого пространства имен, как показано в следующем примере:

Установите флажок Сохранять условную пересылку в Active Directory и реплицировать ее следующим образом: , а затем выберите параметр Все DNS-серверы в этом домене, как показано в следующем примере:

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

Чтобы создать сервер условной пересылки, нажмите кнопку ОК.

Устранение неполадок, связанных с выдачей RID

Общие сведения об устранении неполадок

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

Способы устранения неполадок

Параметры ведения журнала

Все записи, связанные с выдачей RID, регистрируются в журнале системных событий, а источником их является Directory-Services-SAM. По умолчанию ведение журнала включено, и для него настроена максимальная степень подробности. Если в журнале нет записей, которые связанны с изменениями в компонентах, реализованными в Windows Server 2012, проблемы следует решать как классические (то есть до выпуска Windows Server 2012) неполадки с выдачей RID, возникавшие в Windows 2008 R2 или более ранних версиях.

Служебные программы и команды для устранения неполадок

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

Dcdiag.exe
Repadmin.exe
Network Monitor 3.4

Общая методика устранения неполадок, связанных с конфигурацией контроллеров домена

Вызвана ли ошибка очевидной проблемой с разрешениями или доступностью контроллера домена?
1. Пытаетесь ли вы создать субъект безопасности, не имея необходимых разрешений? Проверьте в выходных данных наличие ошибок отказа в доступе.
2. Доступен ли контроллер домена? Изучите полученную ошибку либо сообщения о доступности LDAP или контроллеров домена.
Упоминаются ли в полученном сообщении об ошибке относительные идентификаторы и достаточно ли это сообщение конкретно, чтобы его можно было использовать в качестве инструкции? Если да, то следуйте этой инструкции.
Упоминаются ли в полученном сообщении об ошибке относительные идентификаторы, но при этом оно является недостаточно конкретным? Пример: «Не удается создать объект, так как службе каталогов не удалось выделить относительный идентификатор».
1. изучите журнал системных событий на контроллере домена о событиях rid «legacy» (Windows Server 2012), описанных в запросе к пулу rid (16642, 16643, 16644, 16645, 16656).
2. Проверьте журнал системных событий в контроллере домена и хозяине RID на наличие новых событий, связанных с блокировкой, которые описаны ниже в этом разделе (16655, 16656, 16657).
3. Проверьте работоспособность репликации Active Directory с помощью средства Repadmin.exe и доступность хозяина RID с помощью команды Dcdiag.exe /test:ridmanager /v. Включите запись двухстороннего сетевого мониторинга между контроллером домена и хозяином RID, если этих проверок оказалось недостаточно.

В журнале системных событий контроллера домена Windows Server 2012 регистрируются указанные ниже новые сообщения. Системы автоматического отслеживания работоспособности Active Directory, такие как System Center Operations Manager, должны вести наблюдение за этими событиями, так как все они важны, а некоторые являются признаком серьезных проблем с доменом.

Что такое Active Directory

Active Directory — это технология Microsoft, которая представляет собой распределенную базу данных, в которой хранятся объекты в иерархическом, структурированном и безопасном формате. Объекты AD обычно представляют пользователей, компьютеры, периферийные устройства и сетевые службы. Каждый объект уникально идентифицируется своим именем и атрибутами. Домен, лес и дерево представляют собой логические подразделения инфраструктуры AD.

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

Типичный домашний компьютер — обособленный объект. Вы управляете настройками и учётными записями пользователей на компьютере. Компьютер, присоединённый к домену, отличается — этими настройками управляет контроллер домена.

Является ли мой компьютер частью домена?

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

Вы можете быстро проверить, является ли ваш компьютер частью домена. Откройте приложение «Параметры» (Win+x).

Нажмите «Система».

Перейдите на вкладку «О программе» и найдите пункт «Переименовать этот ПК (для опытных пользователей)»:

Если вы видите «Домен»: за которым следует имя домена, ваш компьютер присоединён к домену.

Если вы видите «Рабочая группа»: за которым следует имя рабочей группы, ваш компьютер присоединён к рабочей группе, а не к домену.

В англоязычной версии это соответственно «Settings» → «System» → «About» → «Rename this PC (advanced)».

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

Для этого выполните команду (можно за один раз всё скопировать-вставить в окно терминала):

$ComputerSystem = Get-CimInstance -Class Win32_ComputerSystem;
$ComputerName = $ComputerSystem.DNSHostName
if ($ComputerName -eq $null) {
    $ComputerName = $ComputerSystem.Name
}

$fqdn = (::GetHostByName($ComputerName)).HostName

$ComputerSystem | Microsoft.PowerShell.Utility\Select-Object `
@{ Name = "ComputerName"; Expression = { $ComputerName }},
@{ Name = "Domain"; Expression = { if ($_.PartOfDomain) { $_.Domain } else { $null } }},
@{ Name = "DomainJoined"; Expression = { $_.PartOfDomain }},
@{ Name = "FullComputerName"; Expression = { $fqdn }},
@{ Name = "Workgroup"; Expression = { if ($_.PartOfDomain) { $null } else { $_.Workgroup } }}

Подробности смотрите в статье: Как в PowerShell узнать, прикреплён ли компьютер к домену или к рабочей группе

Подключение CentOS 7 к домену

Устанавливаем софт, который нам понадобится, для корректного ввода centos в домен windows.

# yum install realmd sssd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools

Вводим Centos 7 в домен:

# realm discover XS.LOCAL
xs.local
  type: kerberos
  realm-name: XS.LOCAL
  domain-name: xs.local
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools

# realm join -U administrator XS.LOCAL
Password for administrator:

Если не получили никакой ошибки, значит все прошло нормально. Можно зайти на контроллер домена и проверить, появился ли наш linux сервер в домене.
Изменим немного конфиг sssd для того, чтобы не нужно было вводить полное имя домена при логине, а только username.

# mcedit /etc/sssd/sssd.conf

use_fully_qualified_names = False

Разрешаем доменным пользователям создавать домашние директории:

# authconfig --enablemkhomedir --enablesssdauth --updateall

Запускаем службу sssd и добавляем в автозагрузку:

# systemctl enable sssd.service && systemctl restart sssd

Проверяем авторизацию по ssh, подключившись по любой доменной учетной записи.
Для пользователя будет создана домашняя директория /home/lin-user@xs.local.

Завершение развертывания операционной системы

Чтобы завершить создание виртуальной машины, необходимо завершить установку операционной системы.

В диспетчере Hyper-V дважды щелкните виртуальную машину.
Нажмите кнопку «Запустить».
Вам будет предложено нажать любую клавишу для загрузки с компакт-диска или DVD-диска. Сделайте это.
На начальном экране Windows Server выберите язык и нажмите кнопку Далее.
Нажмите Установить.
Введите ключ лицензии и нажмите кнопку Далее.
Установите флажок «Я принимаю условия лицензии» и нажмите кнопку Далее.
Выберите Custom: Install Windows Only (Advanced) (Пользовательская: установить только Windows (расширенная).
Нажмите кнопку Далее
Когда установка завершится, перезапустите виртуальную машину, выполните вход и запустите обновление Windows, чтобы обеспечить актуальность виртуальной машины. Установите последние обновления.

Как правильно назвать домен active directory

Как неправильно делать мы поняли и знаем, сделаем теперь все красиво, сразу повторюсь, что если у вас тестовая среда называть AD вы можете как вам захочется, хоть microsoft.com. А если по серьезному, то вернемся к нашей компании Pyatilistnik.inc. Для доменной зоны Active Directory я бы выбрал зону третьего уровня, ad.pyatilistnik.org. Веб сайт компании повесил бы на логичный pyatilistnik.org. Благодаря этому не было бы проблем с MS Exchange сервером. Если у вас несколько филиалов, то я советую вам использовать один лес, пример есть Нижний Новгород и Москва, для Москвы я выбираю ad.pyatilistnik.org, а для НН nn.ad.pyatilistnik.org. Надеюсь вы теперь поняли как лучше и правильнее называть домен Active Directory.

Имена OU

Разрешенные символы

Разрешены все символы, даже расширенные символы. Хотя пользователи и компьютеры Active Directory позволяют называть OU расширенными символами, мы рекомендуем использовать имена, которые описывают назначение OU и которые достаточно коротки, чтобы легко управлять. Протокол доступа к легкому каталогу (LDAP) не имеет ограничений, так как cn объекта ставится в кавычках.
Неустановимые символы

Никакие символы не допускаются.
Минимальная длина имени: 1 символ
Максимальная длина имени: 64 символа

Особые проблемы

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

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

Примечание

Аналогичный конфликт имен может также происходить с другими типами имен RDN при определенных условиях, не ограниченных типами имен DC и OU.

Для чего нужна Active Directory

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

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

Дальнейшие действия

Дополнительные сведения о сравнении Azure AD DS с другими решениями для идентификации и о том, как работает синхронизация, см. в следующих статьях:

Compare self-managed Active Directory Domain Services, Azure Active Directory, and managed Azure Active Directory Domain Services (Сравнение самостоятельно управляемой службы Microsoft Azure Active Directory, Azure Active Directory и управляемых доменных служб Active Directory)
Синхронизация в управляемом домене доменных служб Azure AD
Сведения об администрировании управляемого домена см. в разделе Основные понятия управления учетными записями пользователей, паролями и администрированием в Azure AD DS.

Для начала работы создайте управляемый домен портале Azure.

Active Directory и LDAP

Упрощенный протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP) — стандартный протокол Интернет соединений в сетях TCP/IP. LDAP спроектирован специально для доступа к службам каталогов с минимальными издержками. В LDAP также определены операции, используемые для запроса и изменения информации каталога.

Клиенты Active Directory применяют LDAP для связи с компьютерами, на которых работает Active Directory, при каждом входе в сеть или поиске общих ресурсов. LDAP упрощает взаимосвязь каталогов и переход на Active Directory с других служб каталогов. Для повышения совместимости можно использовать интерфейсы служб Active Directory (Active Directory Service- Interfaces, ADSI).

Устранение неполадок условного доступа

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

имя субъекта-пользователя;
отображаемое имя пользователя;
имя операционной системы;
метка времени (допускается приблизительное время);
целевое приложение;
тип клиентского приложения (браузер или клиент);
идентификатор корреляции (уникальный для входа).

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

Собрав сведения, следует обратиться к следующим ресурсам:

Проблемы при входе с условным доступом. Описание неожиданных результатов входа, связанных с условным доступом, на примере сообщений об ошибке и журнала входа в Azure AD.
Использование инструмента what-if. Описывается, почему политика была или не была применена к пользователю в определенном случае или почему она будет применена в известном состоянии.

.local или ICANN

Во многих учебных руководствах можно встретить названия доменов вида company.local. Действительно, нет никакого криминала в том, чтобы использовать такие имена в учебных и тестовых целях. Хуже, когда по той же схеме называют реальные домены:

Имя противоречит идеологии глобального DNS: не даёт гарантии отсутствия коллизий с другими такими же доменами (когда придет пора устанавливать доверительные отношения)
Отсутствует возможность использовать данное имя для доступа из глобальной сети (когда придет пора публикации)
На домен, владение которым невозможно подтвердить, нельзя получить публичный SSL-сертификат. Данное ограничение особенно актуально с развитием облачных сервисов, когад размываются границы между on-premise и cloud сервисами. Просто пример: для работы Single Sign On со службами Officе 365 требуется AD Federation Services c публичным сертификатом

Поэтому я рекомендую при именовании домена всегда использовать официально зарегистрированное глобальное имя в иерархии ICANN (Internet Corporation for Assigned Names and Numbers), которое гарантированно избавит от описанных выше недостатков.

OU names

Allowed characters

All characters are allowed, even extended characters. Although Active Directory Users and Computers lets you name an OU with extended characters, we recommend that you use names that describe the purpose of the OU and that are short enough to easily manage. Lightweight Directory Access Protocol (LDAP) doesn’t have any restrictions, because the CN of the object is put in quotation marks.
Disallowed characters

No characters are not allowed.
Minimum name length: 1 character
Maximum name length: 64 characters

Special issues

When the OU at the domain root level has the same name as a future child domain, you might experience database problems. Consider a scenario where you delete an OU named marketing to create a child domain with the same name, for example, (leftmost label of the child domain FQDN name has the same name).

The OU is deleted and during the tombstone lifetime of the OU you create a child domain that has the same name is created, deleted, and created again. In this scenario, a duplicate record name in the ESE database causes a phantom-phantom name collision when the child domain is re-created. This problem prevents the configuration container from replicating.

Note

A similar name conflict might also happen with other RDN name types under certain conditions, not restricted to DC and OU name types.

Мост связей сайтов

Мост связи сайтов — это объект Active Directory, представляющий набор связей сайтов, все сайты которых могут обмениваться данными с помощью общего транспорта. Мосты связей сайтов позволяют подключать контроллеры домена, которые не соединены напрямую через канал связи для репликации друг с другом. Как правило, мост связей сайтов соответствует маршрутизатору (или набору маршрутизаторов) в IP-сети.

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

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

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

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

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

Pam_mount и сессия SSH

Для того, чтобы pam_mount корректно работал в сессии SSH нужно отредактировать конфигурацию сервера SSH — файл /etc/ssh/sshd_config.

Параметру ChallengeResponseAuthentication дать значение no.

Без этой правки, из-за особенностей работы OpenSSH при подключении по SSH ресурсы не монтируются с помощью pam_mount с ошибкой:

conv->conv(...): Conversation error

Некоторые подробности тут:http://community.centrify.com/t5/DirectControl-Express-for-UNIX/Try-to-auto-mount-cifs-home-dir-on-Ubuntu-using-Centrify-AD-Pam/td-p/8640https://bugzilla.mindrot.org/show_bug.cgi?id=688

Также, это неприятное обстоятельство можно обойти выполнив в сессии SSH команду:

su -l $USER

То есть фактически залогинившись в сессии SSH еще раз с именем текущего пользователя.

В этому случае OpenSSH не принимает участия создании сессии и ресурсы монтируются.

Подготовка Active Directory

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

При подготовке Active Directory для использования Exchange следует помнить о нескольких моментах:

Используемая учетная запись должна быть членом группы безопасности «Администраторы предприятия». Если вы пропустили шаг 1, так как вы хотите, чтобы команда PrepareAD расширила схему, используемая учетная запись также должна быть членом группы безопасности администраторов схемы.
Компьютер, на котором будет выполняться команда, должен находиться в том же домене и на том же сайте Active Directory, что и хозяин схемы. Он также должен взаимодействовать со всеми доменами в лесу по порту TCP 389.
Подождите, пока Active Directory реплицирует изменения, внесенные на шаге 1, на все контроллеры домена и затем переходите к этому шагу.

При выполнении следующей команды для подготовки Active Directory к использованию Exchange вам потребуется указать имя организации Exchange. Это имя используется только Exchange и обычно не видно пользователям. В качестве имени организации выступает имя компании, в которой устанавливается Exchange. Используемое имя не повлияет на функциональность Exchange или доступные адреса электронной почты. Можно указать любое имя, учитывая следующие ограничения:

можно использовать любые прописные или строчные буквы от A до Z;
можно использовать цифры от 0 до 9;
имя может содержать пробелы, но только не в начале или конце;
в имени можно использовать дефис или тире;
имя может содержать до 64 символов, но не может быть пустым;
имя нельзя изменить после его указания.

Выполните следующие действия, чтобы подготовить Active Directory к использованию Exchange. Если имя организации содержит пробелы, необходимо заключить его в кавычки («).

Откройте окно командной строки Windows и перейдите к установочным файлам Exchange.
Выполните следующую команду:

Важно!

Если вы настроили гибридное развертывание между локальной организацией и Exchange Online, необходимо включить переключатель при запуске вышеуказанной команды.

После завершения подготовки Active Directory для Exchange active Directory необходимо подождать, пока Active Directory реплицирует изменения во все контроллеры домена. Если вы хотите проверить, как происходит репликация, вы можете использовать этот инструмент. входит в состав функции Средства служб доменных служб Active Directory в Windows Server 2012 R2, Windows Server 2012 и Windows Server 2008 R2. Дополнительные сведения об использовании этого средства см. в repadmin.

Последние штрихи на пути к совершенству

Итак, если следовать моим рекомендациям, для домена AD мы выбираем имя:

глобально зарегистрированное
выделенное (дочернее от домена сайта компании)
специфичное
используем split-brain

При этом для адресов электропочты и SIP-адресов в Lync было бы приятнее использовать более короткие адреса user@argon.pro. Ничто не мешает нам сделать это, но возникнут неудобства.

Адрес электропочты у пользователя = user@argon.pro, логин входа = lab\user, user principal name = user@lab.argon.pro. Здесь легко запутаться не только пользователю, но и программам вроде Outlook и Lync.

Чтобы избежать путаницы, я рекомендую в качестве user principal name задать наиболее знакомый пользователю адрес — электропочты. Для этого нужно в свойствах AD-домена lab.argon.pro добавить почтовый домен (в нашем случае — родительский) argon.pro в список поддерживаемых UPN-суффиксов.

Утилиты командной строки Active Directory

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

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

Объекты групповой политики

Что такое групповая политика и объекты групповой политики

Групповая политика — это инструмент, доступный администраторам, использующим домен Active Directory Windows 2000 или более поздней версии. Он позволяет централизованно управлять настройками на клиентских компьютерах и серверах, присоединённых к домену, а также обеспечивает рудиментарный способ распространения программного обеспечения.

Настройки сгруппированы в объекты, называемые Group Policy Objects (GPO), то есть объектами групповой политики. Объекты групповой политики сопрягаются с и могут применяться к пользователям и компьютерам. Объекты групповой политики нельзя применять к группам напрямую, хотя вы можете использовать фильтрацию безопасности или таргетинг на уровне элементов для фильтрации применения политики на основе членства в группе.

Что могут делать организационные политики

Что угодно.

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

Всё, что вы не сможете настроить с помощью предустановленных параметров, вы можете контролировать с помощью скриптов, в том числе на PowerShell.

Значение объектов групповой политики для Active Directory

Объекты групповой политики это и есть тот мощнейший инструмент, который позволяет очень гибко и эффективно управлять Active Directory.

Схема типичного механизма управления:

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

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

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

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