Приложение и. создание учетных записей управления для защищенных учетных записей и групп в active directory

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

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

1. Убедитесь, что целевой сервер отвечает требованиям к системе.
2. Проверьте совместимость приложений.
3. проверьте Рекомендации для перехода на Windows Server 2016
4. Проверьте параметры безопасности. Дополнительные сведения см. в разделе устаревшие функции и изменения в работе, связанные с AD DS в Windows Server 2016.
5. Проверьте подключение к целевому серверу с компьютера, где планируется установка.
6. Проверьте доступность необходимых ролей хозяина операций.
   • чтобы установить первый контроллер домена, работающий Windows Server 2016 в существующем домене и лесу, на компьютере, где выполняется установка, необходимо подключиться к хозяину схемы , чтобы запустить adprep/forestprep и хозяин инфраструктуры для запуска adprep/домаинпреп.
   • Чтобы установить первый контроллер домена в домене, где схема леса уже расширена, требуется подключение только к хозяину инфраструктуры.
   • Для установки или удаления домена в существующем лесу необходимо подключение к хозяину именования доменов.
   • Для установки контроллера домена также требуется подключение к хозяину RID.
   • Если вы устанавливаете первый контроллер домена только для чтения в существующем лесу, вам потребуется подключение к хозяину инфраструктуры для каждого раздела каталога приложений, также известного как контекст именования не в ДОМЕНЕ или нднк.

Этапы установки и требуемые административные уровни

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

Действие установки	Требования к учетным данным
Установка нового леса	Локальный администратор на целевом сервере
Установка нового домена в существующем лесу	Администраторы предприятия
Установка дополнительного контроллера домена в существующем домене	Администраторы домена
Выполнение команды adprep /forestprep	Администраторы схемы, администраторы предприятия и администраторы домена
Выполнение команды adprep /domainprep	Администраторы домена
Выполнение команды adprep /domainprep /gpprep	Администраторы домена
Выполнение команды adprep /rodcprep	Администраторы предприятия

дополнительные сведения о новых возможностях в Windows Server 2016 см. в разделе новые возможности Windows Server 2016.

Настройка и администрирование детальной политики паролей через Центр администрирования Active Directory

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

Центр администрирования Active Directory позволяет создавать объекты детальной политики паролей (FGPP) и управлять такими объектами. Функция FGPP была представлена в Windows Server 2008, но первый графический интерфейс для управления этой функцией появился только в Windows Server 2012. Детальная политика паролей настраивается на уровне домена и позволяет перезаписывать единый пароль домена, предусмотренный в Windows Server 2003. При создании различных FGPP с различными параметрами отдельные пользователи или группы получают различные политики паролей в домене.

Информацию о детальной политике паролей см. в пошаговом руководстве по детальной настройке политик блокировки учетных записей и паролей доменных служб Active Directory (Windows Server 2008 R2).

На панели навигации выберите представление в виде дерева, щелкните свой домен, Система, Контейнер параметров паролей, а затем на панели «Задачи» щелкните Создать и Параметры пароля.

Управление детальной политикой паролей

При создании новой или редактировании уже существующей детальной политики паролей открывается редактор Параметры пароля. Здесь можно настроить все желаемые политики паролей как Windows Server 2008 или Windows Server 2008 R2, но только в специальном редакторе.

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

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

Командлет Active Directory в Windows PowerShell, предназначенный для настройки детальной политики паролей, выглядит следующим образом:

Командлет для настройки детальной политики паролей в Windows Server 2008 R2 и Windows Server 2012 работает одинаково. На приведенном ниже рисунке обозначены соответствующие атрибуты для этих командлетов:

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

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

Неявное назначение ФГПП здесь не отображается; для этого необходимо использовать параметр просмотреть результирующие параметры пароля… .

Руководство по ADMT

В следующем руководстве содержится руководство по миграции доменов с помощью средства миграции Active Directory:

Примечание

• ADMT не обновляется для переноса Windows 8.1 и 10 рабочих станций.
• Windows Server 2012, Windows Server 2012 R2 и более поздней версии Windows Server не были протестированы для современных приложений и миграций профилей. Ваш опыт может отличаться в зависимости от многих факторов, включая Windows версию, которую вы мигрируете. Используйте набор инструментов на свой собственный риск.
• Альтернатива набору инструментов ADMT также доступна в Microsoft Services:Active Directory Migration Services (ADMS). Этот инструмент работает в облаке Azure. Сведения о начальном уровне см. в таблице Taste of Premier: Directory Consolidation with Windows Azure Active Directory migration Services.

Создание учётных записей MSA и gMSA

Для создания учётной записи Managed Service Account (MSA) и Group Managed Service Account (gMSA) требуются права на уровне членства в группе Domain Admins в том случае, если создание учётной записи выполняется в контейнере Active Directory по умолчанию: . Если указанного уровня прав нет, то можно использовать создание учётной записи в любом другом OU в домене, на который есть права уровня Account Operators.

Создание Managed Service Account

При необходимости создать учётную запись Managed Service Account, которая будет ограничена действием только в рамках одного компьютера, то есть учётную запись типа msDS-ManagedServiceAccount, достаточно выполнить команду типа:

New-ADServiceAccount -Name myMSA1 -RestrictToSingleComputer `
-Path "OU=Managed Service Accounts,OU=Service Objects,OU=KOM,DC=holding,DC=com"

Гдe:

– имя создаваемой учётной записи MSA.
Обратите внимание на то, что имя имеет ограничение в 15 символов.

– наличие этого параметра говорит о том, что нужно создать именно учётную запись MSA (не gMSA) действие которой ограничено одним каким-либо сервером. — CN контейнера где будет создана учётная запись MSA, если нет желания использовать контейнер по умолчанию (CN=Managed Service Accounts,DC=holding,DC=com). После успешного выполнения командлета убедимся в наличии объекта класса msDS-ManagedServiceAccount в указанном OU в домене.

После успешного выполнения командлета убедимся в наличии объекта класса msDS-ManagedServiceAccount в указанном OU в домене.

С помощью PowerShell можем запросить информацию о созданной учётной записи MSA командлетом Get-ADServiceAccount.

Командлет New-ADServiceAccount имеет ряд других интересных параметров, узнать о которых можно, например, в онлайн справке.

В последствии созданную учётную запись можно будет привязать только к одному серверу.

Создание Group Managed Service Account

При необходимости создать групповую учётную запись Group Managed Service Account (класса msDS-GroupManagedServiceAccount), которую можно будет использовать в рамках нескольких компьютеров, например, на нескольких узлах какого-либо кластера, выполняем команду типа:

$server1 = Get-ADComputer "<имя сервера 1>"
$server2 = Get-ADComputer "<имя сервера 2>"
New-ADServiceAccount -Name "myGMSA1" -DNSHostName "myGMSA1.holding.com" `
-PrincipalsAllowedToRetrieveManagedPassword $server1,$server2 `
-ManagedPasswordIntervalInDays 60 `
-Path "OU=Managed Service Accounts,OU=Service Objects,OU=KOM,DC=holding,DC=com"

Гдe:

• – имя создаваемой учётной записи gMSA
• — FQDN имя, складывающееся из имени учётной записи (sAMAccountName) и доменного суффикса. Хотя есть разные толкования того, что должно быть указано в этом параметре (здесь и здесь.)

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

-ManagedPasswordIntervalInDays — Период (в днях) действия пароля до его автоматической смены (при смене генерируется стойкий пароль длинной в 240 символов). Если параметр не указан по умолчанию используется значение в 30 дней.

После успешного выполнения командлета убедимся в наличии объекта класса msDS-GroupManagedServiceAccount в указанном OU в домене

Замечания

Создавая учётные записи MSA/gMSA лучше руководствоваться принципом «отдельный сервис – отдельная учётная запись» и не пытаться использовать одну учётную запись MSA/gMSA для разных служб, так как это понижает уровень безопасности всех служб/приложений, совместно использующих одну и туже учётную запись. К тому же даже с точки зрения отладки работы служб и приложений использование разных учётных записей может дать свои преимущества.

Проверено на следующих конфигурациях:

Версия ОС
Windows Server 2012 R2 Standard EN (6.3.9600)

Автор первичной редакции:Алексей Максимов
Время публикации: 30.10.2018 17:21

Создание корневого ключа службы распространения ключей

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

Если корневой ключ для домена уже существует (проверьте с помощью Get-KdsRootKey), перейдите к следующему разделу.

1. Создайте корневой ключ службы распространения ключей (KDS), если это необходимо. Это делается только один раз для каждого домена. Корневой ключ (в сочетании с другими сведениями) используется службой KDS на контроллерах домена для создания паролей. Введите следующую команду PowerShell от имени администратора домена:

   При использовании -EffectiveImmediately возможна задержка длительностью до ~10 часов, так как требуется выполнить репликацию на все контроллеры домена. Для двух контроллеров домена эта задержка составляет примерно 1 час.

   Примечание

   В лабораторной или тестовой среде 10-часовую задержку репликации можно пропустить, выполнив следующую команду:

   Add-KDSRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Создание файла спецификации учетных данных

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

Файл спецификации учетных данных создается с помощью модуля CredentialSpec среды PowerShell на компьютере, присоединенном к домену.
Созданный файл можно скопировать в другие узлы контейнера или оркестратор контейнера.
Файл спецификации учетных данных не содержит секретов, таких как пароль gMSA, так как узел контейнера получает gMSA от имени контейнера.

Docker должен найти файл спецификации учетных данных в каталоге CredentialSpecs каталога данных Docker. В установке по умолчанию эта папка находится по адресу .

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

1. Установите средства удаленного администрирования сервера AD PowerShell:

   • Для Windows Server выполните команду Install-WindowsFeature RSAT-AD-PowerShell.
   • Для Windows 10 версии 1809 или более поздней выполните команду Add-WindowsCapability -Online -Name ‘Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0’ .
   • Для более ранних версий Windows 10 см. статью https://aka.ms/rsat.

2. Выполните следующий командлет, чтобы установить последнюю версию модуля CredentialSpec среды PowerShell:

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

3. Запустите следующий командлет, чтобы создать файл спецификации учетных данных:

   По умолчанию командлет создаст файл спецификации учетных данных, используя предоставленное имя gMSA в качестве учетной записи компьютера контейнера. Файл будет сохранен в каталоге CredentialSpecs Docker с использованием в названии файла имени домена и учетной записи gMSA.

   Если вы хотите сохранить файл в другом каталоге, используйте параметр :

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

   Для получения полного списка поддерживаемых параметров выполните .

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

Вот пример спецификации учетных данных:

как работает MIM PAM?

В основе PAM лежат новые возможности доменных служб Active Directory, в частности авторизация и проверка подлинности учетной записи домена, а также новые возможности MIM. PAM отделяет привилегированные учетные записи от существующей среды Active Directory. Если возникнет необходимость использовать привилегированную учетную запись, ее нужно сначала запросить, а затем утвердить. После утверждения привилегированной учетной записи предоставляется разрешение через внешнюю главную группу в новом лесу-бастионе, а не в текущем лесу пользователя или приложения. Использование леса-бастиона предоставляет организации больше возможностей для контроля. Например, позволяет определять, может ли пользователь быть членом привилегированной группы и как пользователь должен проходить проверку подлинности.

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

В следующем примере применение PIM показано подробнее.

Лес бастиона выдает ограниченное по времени членство в группах, которое, в свою очередь, формирует билеты предоставления билетов (TGT). Приложения и службы на основе Kerberos учитывают и применяют такие TGT, если приложения и службы существуют в лесах, доверяющих лесу бастиона.

Учетные записи обычных пользователей перемещать в новый лес необязательно. То же самое справедливо и для компьютеров, приложений и их групп. Они остаются в существующем лесу. Рассмотрим пример организации, которая озабочена упомянутыми выше проблемами кибербезопасности, но пока не планирует немедленно обновить инфраструктуру серверов до следующей версии Windows Server. Эта организация может воспользоваться описанным здесь комбинированным решением, то есть использовать MIM и новый лес-бастион, чтобы лучше управлять доступом к существующим ресурсам.

PAM предоставляет следующие преимущества.

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

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

• Более подробное ведение журнала. Кроме встроенных рабочих процессов MIM предусмотрены дополнительные записи в журнал для PIM, по которым можно видеть запрос, его авторизацию и события, происходящие после утверждения запроса.

• Настраиваемый рабочий процесс. Рабочие процессы MIM можно настроить для различных сценариев. Можно применять несколько рабочих процессов на основе параметров запрашивающего пользователя или запрошенных ролей.

Автономная дефрагментация базы данных Active Directory

Как говорилось выше, процесс онлайновой дефрагментации не может сократить размер базы данных Active Directory. При нормальных обстоятельствах это не является проблемой, потому что страницы базы данных, которые очищены в процессе онлайновой дефрагментации, просто снова используются по мере добавления новых объектов к Active Directory. Однако, в некоторых случаях, можно использовать автономную дефрагмен-тацию для сокращения полного размера базы данных. Например, если вы удаляете GC-каталог из контроллера домена, нужно выполнить автономную дефрагментацию в базе данных, чтобы очистить место, которое ис-пользовалось в базе данных для хранения информации GC. Потребность в автономной дефрагментации существует в среде, состоящей из нескольких доменов, где GC каталог может стать очень большим.
Чтобы выполнить автономную дефрагментацию, выполните следующие шаги.

1. Сделайте резервную копию информации Active Directory на контроллер домена (см. гл. 15).
2. Перезагрузите контроллер домена. Во время загрузки сервера нажмите клавишу F8, чтобы отобразить меню дополнительных параметров Windows. Выберите режим Directory Services Restore (Восстановление службы каталога) (Только для контроллеров домена с системой Windows).
3. Войдите в систему, используя учетную запись Administrator (Администратор). Используйте пароль, который вы вводили как пароль режима восстановления службы каталога, когда назначали контроллер домена.
4. Откройте командную строку и напечатайте ntdsutil.
5. В командной строке утилиты Ntdsutil напечатайте files.
6. В командной строке утилиты File Maintenance (Обслуживание файлов) напечатайте info. Эта опция отображает текущую информацию о пути и размере базы данных Active Directory и ее журналов.
7. Напечатайте compact to drive:\directory. Выберите диск и каталог, которые имеют достаточно места для хранения всей базы данных. Если название пути каталога содержит пробелы, путь должен быть заключен в кавычки.
8. Процесс автономной дефрагментации создает новую базу данных по имени Ntds.dit в указанном вами месте. По мере копирования базы данных в новое место она дефрагментируется.
9. Когда дефрагментация закончена, напечатайте дважды quit, чтобы возвратиться к приглашению ко вводу команды.
10. Скопируйте дефрагментированный файл Ntds.dit поверх старого файла Ntds.dit в место расположения базы данных Active Directory.
11. Перезагрузите контроллер домена.

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

Примечание. В главе 15 подробно описывается, как используется журнал транзакций в Active Directory.
Чтобы восстановить журнал транзакций, выполните следующие действия.

1. Перезагрузите сервер и выберите загрузку в режиме восстановления службы каталога. Это требуется для работы инструмента Ntdsutil.
2. Откройте командную строку и напечатайте ntdsutil.
3. В командной строке утилиты Ntdsutil напечатайте files.
4. В командной строке File Maintenance напечатайте recover.

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

Проверка для проверки

Перед продолжением развертывания проверьте результаты развертывания, просмотрев следующие элементы:

• Убедитесь, что ферма AD FS использует правильную конфигурацию базу данных.
• Убедитесь, что ферма AD FS имеет достаточное число узлов и нагрузка на нее будет правильно сбалансирована для ожидаемой нагрузки.
• Убедитесь, что на все серверы AD FS в ферме установлены последние обновления.
• Убедитесь, что все серверы AD FS имеют действительный сертификат проверки подлинности
  • Субъект сертификата — это общее имя (полное доменное имя) узла или подстановочное имя.
  • Альтернативное имя сертификата содержит подстановочное имя или полное доменное имя службы федераций

Архитектура центра администрирования Active Directory

Центр администрирования Active Directory исполняемых файлов, DLL

Модуль и базовая архитектура Центра администрирования Active Directory с появлением новой корзины Active Directory, детальной политики паролей и средства просмотра журнала не изменились,

• Microsoft.ActiveDirectory.Management.UI.dll
• Microsoft.ActiveDirectory.Management.UI.resources.dll
• Microsoft.ActiveDirectory.Management.dll
• Microsoft.ActiveDirectory.Management.resources.dll
• ActiveDirectoryPowerShellResources.dll

Базовый Windows PowerShell и слой операций для новой корзины представлены ниже:

Улучшения в области выдачи идентификаторов RID и управления ими

В системе Active Directory в Windows 2000 появился хозяин RID, который выдавал пулы относительных идентификаторов контроллерам домена, чтобы последние могли создавать идентификаторы безопасности (SID) для субъектов безопасности, таких как пользователи, группы и компьютеры. По умолчанию глобальное пространство RID ограничено общим количеством идентификаторов безопасности (230, или 1 073 741 823), которое можно создать в домене. Идентификаторы безопасности нельзя вернуть в пул или выдать повторно. Со временем в большом домене может возникнуть нехватка идентификаторов RID либо их пул может начать иссякать в результате различных происшествий, ведущих к удалению RID.

В Windows Server 2012 решен ряд проблем, связанных с выдачей идентификаторов RID и управлением ими, которые были выявлены клиентами и службой поддержки клиентов Майкрософт с 1999 года, когда были созданы первые домены Active Directory. Сюда входит следующее.

• В журнал событий периодически записываются предупреждения об использовании идентификаторов RID.
• Когда администратор делает пул RID недействительным, в журнале создается событие.
• Ограничение на максимальный размер блока RID теперь устанавливается принудительно в политике RID.
• Искусственный верхний порог RID теперь применяется принудительно, а если глобальное пространство RID истощается, в журнал заносится запись, что позволяет администратору предпринять меры прежде, чем пространство будет исчерпано.
• Глобальное пространство RID теперь можно увеличить на один бит, благодаря чему его размер увеличивается вдвое — до 231 (2 147 483 648 идентификаторов безопасности).

Подробнее об идентификаторах RID и хозяине RID см. в разделе Принципы работы идентификаторов безопасности.

Создание учетных записей, групп и субъекта-службы для службы MIM

Продолжайте использовать PowerShell от имени администратора домена.

1. Создайте группу с именем MIMService_Servers и добавьте в нее все серверы службы MIM. Введите следующие команды PowerShell, чтобы создать группу AD для серверов службы MIM и добавить в эту группу учетную запись компьютера Active Directory на сервере службы MIM, например contoso\MIMPortal$.

2. Создайте учетную запись gMSA для службы MIM.

3. Зарегистрируйте имя субъекта-службы и включите делегирование Kerberos, выполнив следующую PowerShell-команду:

4. Для реализации сценариев SSPR учетная запись службы MIM должна взаимодействовать со службой синхронизации MIM, поэтому нужно включить ее в группу MIMSyncAdministrators или в группу просмотра и сброса паролей службы синхронизации MIM.

5. Перезагрузите сервер службы MIM, чтобы обновить связанный с ним токен Kerberos, так как членство в группе MIMService_Servers изменилось.