Что такое active directory, и как установить и настроить базу данных

Репликация Active Directory средствами Windows PowerShell

В Windows Server 2012 добавлены дополнительные командлеты для репликации Active Directory в модуль Active Directory для Windows PowerShell. Они позволяют настраивать новые и существующие сайты, подсети, подключения, связи сайтов и мосты. Они также возвращают метаданные репликации Active Directory, состояние репликации, а также актуальные данные об очередях и векторе синхронизации версий. Командлеты репликации в сочетании с другими командлетами модуля Active Directory позволяют администрировать весь лес, используя только Windows PowerShell. Все это дает новые возможности администраторам, желающим предоставлять ресурсы и управлять системой Windows Server 2012 без использования графического интерфейса, что сокращает уязвимость операционной системы к атакам и требования к обслуживанию. Это приобретает особое значение, если серверы необходимо развернуть в сетях с высоким уровнем защиты, таких как сети SIPR и корпоративные сети периметра.

Подробнее о топологии сайтов и репликации доменных служб Active Directory см. в разделе Технический справочник по Windows Server.

Параметры DNS

При установке DNS-сервера отображается следующая страница Параметров DNS:

При установке DNS-сервера записи делегирования, которые указывают на DNS-сервер в качестве разрешенного для зоны, должны создаваться в зоне службы доменных имен родительского домена. Записи делегирования передают орган разрешения имен и обеспечивают правильные ссылки на другие DNS-серверы и на клиентов новых серверов, которые были сделаны полномочными для новой зоны. Эти записи ресурсов содержат следующие сведения:

• Запись ресурса сервера имен (NS) для реализации делегирования. Эта запись ресурса сообщает, что сервер с именем ns1.na.example.microsoft.com является полномочным сервером для делегированного субдомена.

• Для разрешения имени сервера, указанного в записи ресурса сервера имен (NS), в его IP-адрес требуется запись ресурса узла (A или AAAA), также называемая связывающей записью. Процесс разрешения имени узла в этой записи ресурса в делегированный DNS-сервер в записи ресурса сервера имен (NS) иногда называется «связывающим преследованием».

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

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

Процесс установки пытается создать делегирование, чтобы компьютеры, входящие в другие домены, могли разрешать DNS-запросы для узлов в субдомене DNS, включая контроллеры домена и компьютеры-члены домена

Обратите внимание, что записи делегирования могут создаваться автоматически только на DNS-серверах Майкрософт. Если зона родительского DNS-домена расположена на DNS-серверах стороннего производителя, например BIND, на странице проверки предварительных требований отображается предупреждение о неудачной попытке создания записей DNS-делегирования

Дополнительные сведения об этом предупреждении см. в разделе Известные проблемы установки AD DS.

Делегирование между родительским доменом и субдоменом, уровень которого нужно повысить, можно создать и проверить как до, так и после установки. Не следует откладывать установку нового контроллера домена из-за того, что невозможно создать или обновить делегирование DNS.

Дополнительные сведения о делегировании см. в разделе Основные сведения о делегировании зоны ( ). Если делегирование зоны не представляется возможным, можно рассмотреть другие способы обеспечения разрешения имен узлов в вашем домене из других доменов. Например, администратор DNS другого домена может настроить условную пересылку, зоны заглушки или дополнительные зоны для разрешения имен узлов в вашем домене. Дополнительные сведения см. в следующих разделах:

• Основные сведения о типах зон ( )

• Основные сведения о зонах-заглушекх ( )

• Общие сведения о серверах пересылки ( )

Архитектура ADPrep и проверки предварительных требований

Средство Adprep больше не обязательно запускать на хозяине схемы. Его можно запускать удаленно с компьютера с 64-разрядной версией Windows Server 2008 или более поздней версии.

Примечание

Средство Adprep использует протокол LDAP для импорта файлов Schxx.ldf и не переподключается автоматически, если во время импорта подключение к хозяину схемы прерывается. В процессе импорта хозяин схемы переводится в специальный режим, а переподключение отключается, так как при повторном подключении по протоколу LDAP режим станет иным. В этом случае схема будет обновлена неправильно.

Проверка предварительных требований обеспечивает соблюдение определенных условий. Эти условия необходимы для успешной установки доменных служб Active Directory. Если некоторые обязательные условия не выполняются, вы можете устранить проблемы, а затем продолжить установку. Также проверяется готовность леса или домена к автоматическому выполнению кода развертывания Adprep.

Исполняемые файлы, файлы DLL, LDF и другие файлы ADPrep

• ADprep.dll
• Ldifde.dll
• Csvde.dll
• Sch14.ldf — Sch56.ldf
• Schupgrade.cat
• *dcpromo.csv

Код подготовки Active Directory, который ранее помещался в файле ADprep.exe, прошел рефакторинг и теперь находится в файле adprep.dll. Это позволяет как программе ADPrep.exe, так и модулю Windows PowerShell ADDSDeployment использовать библиотеку для выполнения одних и тех же задач с помощью одинаковых возможностей. Программа Adprep.exe имеется на установочном носителе, но автоматические процессы не обращаются к ней напрямую — администратор должен запустить ее вручную. Она может выполняться в 64-разрядной версии Windows Server 2008 и более поздних операционных системах. Программы ldifde.exe и csvde.exe также имеют DLL-версии, прошедшие рефакторинг, которые загружаются процессом подготовки. Для расширения схемы по-прежнему используются заверенные подписями LDF-файлы, как в предыдущих версиях операционной системы.

Важно!

32-разрядного средства Adprep32.exe для Windows Server 2012 не существует. Для подготовки леса и домена необходим по крайней мере один компьютер с Windows Server 2008 (64-разрядной версии), Windows Server 2008 R2 или Windows Server 2012, работающий как контроллер домена, рядовой сервер или член рабочей группы. Средство Adprep.exe нельзя запустить в 64-разрядной версии Windows Server 2003.

Настройка доверительных отношений

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

В домене primary.local открываем Диспетчер серверов — кликаем по Средства — Active Directory — домены и доверие:

В открывшемся окне кликаем правой кнопкой по нашему домену — Свойства:

Переходим на вкладку Отношения доверия — кликаем по Создать отношение доверия…:

Нажимаем Далее — вводим имя для второго домена (secondary.local) и кликаем Далее:

Выбираем Доверие леса (если нам не нужно внешнее доверие) — Далее:

В окне «Направление отношения доверия» выбираем Двустороннее:

… и нажимаем Далее.

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

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

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

Далее нужно выбрать «Уровень проверки подлинности исходящего доверия» — если оба домена принадлежат нашей организации, предпочтительнее выбрать Проверка подлинности в лесу, чтобы предоставить доступ ко всем ресурсам:

После последуют два окна — «Выбор доверия завершен» — Далее — «Создание доверия завершено» — Далее.

В окне «Подтверждение исходящего доверия» оставляем Нет, не подтверждаю это исходящее доверие, так как на другой стороне нами не создавалось доверия.

Тоже самое в окне «Подтверждение входящего доверия».

Нажимаем Готово — доверительные отношения созданы.

NПОПЫТКА

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

В пределах сайта подключения между контроллерами домена с возможностью записи всегда упорядочиваются по двунаправленному кругу с дополнительными подключениями для уменьшения задержки на больших сайтах. С другой стороны, межсайтовая топология является слоем распределения деревьев. Это означает, что между двумя сайтами каждого раздела каталога существует одно межсайтическое соединение, которое обычно не содержит ярлыки. Дополнительные сведения о охвате деревьев и Active Directory топологии репликации см. в статье Технический справочник по топологии репликации Active Directory ( https://go.microsoft.com/fwlink/?LinkID=93578 ).

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

улучшения KCC для Windows Server 2008 rodc

существует ряд улучшений KCC для размещения нового доступного контроллера домена только для чтения (RODC) в Windows Server 2008. Типичным сценарием развертывания для RODC является филиал. Топология репликации Active Directory, наиболее часто развернутая в этом сценарии, основана на конструкции «звезда», где контроллеры домена ветви на нескольких сайтах реплицируются с небольшим количеством серверов-плацдармов на сайте концентратора.

Одним из преимуществ развертывания RODC в этом сценарии является однонаправленная репликация. Серверы-плацдармы не должны реплицироваться с RODC, что снижает нагрузку на администрирование и использование сети.

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

для Windows Server 2008 rodc нормальная работа KCC обеспечивает некоторую перераспределение. Новые функции включены по умолчанию. Его можно отключить, добавив следующий набор разделов реестра на RODC:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

«Random BH LoadBalancing Allowed»1 = Enabled (по умолчанию), 0 = отключено

Дополнительные сведения о том, как работают эти улучшения KCC, см. в разделе Планирование и развертывание служб домен Active Directory для филиалов ( https://go.microsoft.com/fwlink/?LinkId=107114 ).

Результаты

На этой странице можно просмотреть результаты установки.

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

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

Примеры использования Get-ADDomainController

Чтобы получить контроллер домена с помощью механизма обнаружения DCLocator, используйте опцию -Discover. Вы можете указать критерии поиска, задав такие опции, как -Service, -SiteName, -DomainName, -NextClosestSite, -AvoidSelf и -ForceDiscover.

Также вы можете найти контроллер домена, которому должен принадлежать ваш компьютер, через службу -DCLocator:

Get-ADDomainController -Discover

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

Get-ADDomainController -Discover -Site "Default-First-Site-Name"

Опция -ForceDiscover указывает командлету очистить всю кэшированную информацию о контроллере домена и выполнить новое обнаружение. Если этот параметр не указан, командлет может возвращать кэшированные сведения о контроллере домена.

Get-ADDomainController -Discover -Site "Default-First-Site-Name" -ForceDiscover

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

Get-ADDomainController -Discover -Domain "user01.com"

Вы можете найти ближайший доступный контроллер домена с активной ролью веб-служб AD:

Get-ADDomainController -ForceDiscover -Discover -Service ADWS

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

• PrimaryDC или 1
• GlobalCatalog или 2
• KDC или 3
• TimeService или 4
• ReliableTimeService или 5
• ADWS или 6

Пример использования опции -Service для поиска PDC (Primary Domain Controller Emulator) в вашем домене:

Get-ADDomainController -Discover -Service PrimaryDC

Эта команда ищет компьютер с функцией Глобального каталога в текущем лесу:

Get-ADDomainController -Discover -Service "GlobalCatalog"

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

Get-ADDomainController -Discover -Domain "corp.contoso.com" -Service "PrimaryDC","TimeService"

Если ваш контроллер домена не найден или не отвечает, вы можете найти его на ближайшем сайте AD (определяется весом межсайтовых ссылок):

Get-ADDomainController -Discover -ForceDiscover -NextClosestSite

Чтобы найти и получить более одного контроллера домена, используйте опцию -Filter.

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

Get-ADDomainController -Filter * | Format-Table

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

Get-ADDomainController -Filter * | Measure-Object

Вы можете отобразить более удобную таблицу, в которой показаны все контроллеры домена, их имена хостов, IP-адреса, версии ОС и имена сайтов AD:

Get-ADDomainController -Filter *| Select-Object Name,ipv4Address,OperatingSystem,site | Sort-Object name

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

Get-ADDomainController -Filter * -Server dc01.test.com | Select Name,ipv4Address, IsGlobalCatalog,Site

Ключевые возможности Active Directory

— Единая регистрация в сети. Позволяет настроить вход пользователя в рабочее пространство под своей учётной записью. Функционал аутентификации позволяет администрировать доступы пользователе ко всем ресурсам и информационным системам организации, настраивать интеграцию аутентификации c другими службами авторизации (использование единого доступа сотрудника, например, к компьютеру, к электронной почте, корпоративному порталу, 1С и т.д.).

— Безопасность информации. Централизованная настройка ролей и прав доступа группам или отдельным пользователям в рабочей сети, в зависимости от поставленной задачи.

— Лёгкий поиск. Поиск объектов осуществляется при помощи имени пользователя/компьютера или адреса электронной почты.

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

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

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

Возможности групповых политик Active Directory:

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

https://youtube.com/watch?v=fojHlsyGQqA%2520

Параметры RODC

При установке контроллера домена только для чтения (RODC) отображаются следующие параметры.

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

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

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

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

Дополнительные сведения об установке контроллера домена только для чтения см. в разделе Установка контроллера домена Active Directory только для чтения для Windows Server 2012 (уровень 200).

Добавление дополнительного контроллера домена в существующий домен AD

Прежде всего, нам нужно установить роль Active Directory Domain Services на сервере, который будет новым DC.

Установка роли ADDS

Прежде всего, откройте консоль Server Manager. Когда откроется Server Manager, нажмите «Add roles and features», чтобы открыть консоль установки ролей сервера.

Пропустите страницу «Before you Begin». Выберите «Role-based or featured-based installation» нажмите кнопку «Next». На странице «Server Selection» снова нажмите кнопку «Next».

Выберите роль Active Directory Domain Services. В открывшемся окне нажмите кнопку «Add Features», чтобы добавить необходимые инструменты управления Active Directory Management Tools.

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

Как настроить PAM в Linux

Все конфигурационные файлы PAM для различных приложений находятся в папке /etc/pam.d. Давайте посмотрим на конфигурационный файл для утилиты sudo:

Каждая строчка файла состоит из нескольких полей:

тип обязательность модуль параметры

Разберем подробнее:

• Первое поле — тип, определяет какой тип запроса к PAM надо выполнить. Существует четыре различных типа запроса auth (проверка данных входа, например, логина и пароля), account (проверка не истёк ли пароль пользователя), password (обновление пароля), и session (обслуживание сессии, например, логгирование и монтирование папок).
• Второе поле определяет как нужно интерпретировать результат, возвращённый модулем PAM. Доступно тоже несколько возможных вариантов: required (тест должен быть обязательно пройден, но следующие строки тоже будут проверяться), requisite (аналогично required, только если тест не проходит, то следующие строки уже не проверяются), sufficient (противоположно requisite, если тест проходит, то следующие строки уже не проверяются), optional (проваленные тесты игнорируются).
• Третье и четвертое поле — это название библиотеки модуля и её параметры. Всё это надо выполнить для выполнения теста авторизации или действия.

Кроме того, существуют директивы include, которые включают строки из других файлов так, как будто они были написаны в этом файле. Файл настройки sudo кажется совсем коротким, но в него включаются другие файлы. Давайте посмотрим ещё на файл /etc/pam.d/common-auth:

Здесь можно видеть более расширенный синтаксис параметра обязательности. Он позволяет лучше понять как всё это работает. Давайте его рассмотрим:

Модули PAM могут возвращать около 30-ти значений и они зависят от выбранного типа (account/auth/session…), вот они все: success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired, cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete и default. Последнее, default, означает все поля, которые явно не заданы.

В качестве действия могут быть указанны такие значения:

• ignore — не влияет на общий код возврата в приложение;
• bad — расценивать это значение как свидетельство сбоя модуля;
• die — аналогично bad, только сразу возвращать управление в приложение;
• ok — значение должно влиять на общий возвращаемый результат, переопределяет общий результат если он раньше был успешен, но не отменяет сбой;
• done — аналогично ok, только управление сразу возвращается приложению.

Таким образом, те четыре варианта обязательности, которые мы рассматривали выше можно описать вот так:

• required:
• requisite:
• sufficient:
• optional:

Здесь:

• success — модуль вернул состояние успешно, поскольку значение ok, это состояние будет учтено если ни один предыдущий модуль не дал сбоя;
• new_authtok_reqd — модуль сообщает, что пароль пользователя желательно обновить;
• ignore — модуль просит игнорировать его результат, игнорируем;
• default — все остальные возвращаемые значение расцениваем как сбой.

Обратите внимание. что модуль возвращает только одно определенное значение и уже к нему применяется действие

Чтобы закрепить всё это на практике давайте рассмотрим как запретить авторизацию от имени пользователя losst на компьютере с помощью PAM. Для этого можно воспользоваться модулем /lib/security/pam_listfile.so. Он позволяет ограничить доступ для пользователей на основе файла со списком. Откройте файл /etc/pam.d/sshd и добавьте туда такую строчку:

Здесь мы используем тип запроса auth, обязательность required и указанный выше модуль. Вот его опции и их значения:

• onerr=succeed — если возникает ошибка, доступ разрешить;
• item=user — указывает, что в файле конфигурации находятся логины пользователей;
• sense=deny — действие, если логин пользователя найден в файле;
• file=/etc/denyusers — файл с логинами пользователей, для которых надо запретить доступ.

Теперь в файл /etc/denyusers добавьте имя пользователя losst, естественно, такой пользователь должен существовать в системе. Затем попробуйте перейти в любую консоль и авторизоваться от его имени. У вас ничего не выйдет, а в логе /var/log/security или /var/log/auth.log будет сообщение об ошибке:

А если эту строчку закомментировать, то всё снова заработает.