Домен основные компоненты способы администрирования

Основные понятия управления учетными записями пользователей, паролями и администрирование в доменных службах Azure Active Directory.

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

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

управление доменами;

Управляемый домен представляет собой пространство имен DNS с соответствующим каталогом. В управляемом домене контроллеры домена, которые содержат все ресурсы, такие как пользователи и группы, учетные данные и политики, являются частью управляемой службы. Для обеспечения избыточности в составе управляемого домена создаются два контроллера домена. Вы не можете входить в эти контроллеры домена для выполнения задач управления. Вместо этого создайте виртуальную машину управления, присоединенную к управляемому домену, а затем установите стандартные средства управления AD DS. Можно использовать центр администрирования Active Directory или оснастки консоли управления Microsoft (MMC), например, объекты DNS или групповой политики.

Создание учетной записи пользователя

Есть несколько способов создания учетных записей пользователей в управляемом домене. Большинство учетных записей пользователей синхронизируются из Azure AD, что также может предполагать синхронизацию учетной записи пользователя из локальной среды AD DS. Кром того, можно вручную создавать учетные записи непосредственно в управляемом домене. Некоторые функции, такие как исходная синхронизация паролей или политика паролей, действуют по-разному в зависимости от того, как и где создаются учетные записи пользователей.

• Учетную запись пользователя можно синхронизировать из Azure AD. Эта процедура включает облачные учетные записи пользователей, созданные непосредственно в Azure AD, а также гибридные учетные записи пользователей, синхронизированные из локальной среды AD DS с помощью Azure AD Connect.
  • Большинство учетных записей пользователей в управляемом домене создается с помощью процесса синхронизации в Azure AD.
• Учетная запись пользователя может быть создана вручную в управляемом домене и не существует в Azure AD.
  • Если необходимо создать учетные записи служб для приложений, которые работают только в управляемом домене, их можно создать вручную в управляемом домене. Учитывая, что синхронизация выполняется в Azure AD в одностороннем режиме, учетные записи пользователей, созданные в управляемом домене, не синхронизируются с Azure AD.

Политика паролей

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

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

Дополнительные сведения о различиях в применении политик паролей в зависимости от источника создания пользователей см. в статье Политики блокировки паролей и учетных записей в управляемых доменах.

Синхронизация хэшей паролей

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

При использовании облачных учетных записей пользователям нужно сменить пароль, чтобы получить доступ к управляемому домену. При смене пароля хэши паролей автоматически создаются и сохраняются в Azure AD для аутентификации Kerberos и NTLM. Данные об учетной записи не синхронизируются из Azure AD в Azure AD DS, пока пароль не будет изменен.

Для пользователей, синхронизированных из локальной среды AD DS с помощью Azure AD Connect, следует включить синхронизацию хэшей паролей.

При включении Azure AD DS для арендатора Azure AD служба Azure AD Connect синхронизирует хэши только устаревших паролей. Хэши устаревших паролей не используются, если Azure AD Connect используется только для синхронизации локальной среды AD DS с Azure AD.

Если устаревшие приложения не используют проверку подлинности NTLM или простые привязки LDAP, рекомендуется отключить синхронизацию хэшей паролей NTLM для Azure AD DS. Дополнительные сведения см. в статье Отключение слабых комплектов шрифтов и синхронизации хэшей учетных данных NTLM.

После настройки хэши паролей в требуемом формате сохраняются в управляемом домене. Если вы удалите управляемый домен, вместе с ним будут удалены все сохраненные хэши паролей. Синхронизированные в Azure AD учетные данные нельзя использовать повторно, если вы создадите еще один управляемый домен. Вам придется повторно настраивать синхронизацию хэшей паролей, чтобы сохранить их. Ранее присоединенные к домену виртуальные машины и пользователи не смогут сразу выполнить аутентификацию, пока Azure AD не создаст и не сохранит хэши паролей в новом управляемом домене. См. сведения о синхронизации хэшей паролей в Azure AD DS и Azure AD Connect.

Azure AD Connect следует устанавливать и настраивать только для синхронизации с локальными средами AD DS. Установка Azure AD Connect в управляемом домене для синхронизации объектов обратно в Azure AD не поддерживается.

Леса и отношения доверия

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

В Azure AD DS лес содержит только один домен. Локальные леса AD DS часто содержат много доменов. В крупных организациях, особенно после слияния и приобретения, у вас может быть несколько локальных лесов, каждый из которых будет содержать несколько доменов.

По умолчанию управляемый домен создается как лес объектов пользователя. Лес этого типа синхронизирует все объекты из Azure AD, включая учетные записи пользователей, созданные в локальной среде AD DS. Учетные записи пользователей могут напрямую проходить проверку подлинности в управляемом домене, например для входа в виртуальную машину, присоединенную к домену. Лес пользователей работает, когда хэши паролей можно синхронизировать и пользователи не используют единственный метод входа, например проверку подлинности с помощью смарт-карты.

В лесу ресурсов Azure AD DS проверка подлинности пользователей осуществляется с помощью одностороннего доверия леса из локальных AD DS. При таком подходе пользовательские объекты и хэши паролей не синхронизируются с Azure AD DS. Пользовательские объекты и учетные данные существуют только в локальных AD DS. Такой подход позволяет предприятиям размещать в Azure ресурсы и платформы приложений, которым требуется классическая проверка подлинности, например LDAPS, Kerberos или NTLM, при этом устраняются проблемы проверки подлинности.

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

Номера SKU Azure AD DS

В Azure AD DS доступные характеристики и производительность определяются номерами SKU. Номер SKU выбирается при создании управляемого домена. После развертывания управляемого домена можно выбрать другие номера SKU по мере изменения бизнес-требований. В следующей таблице приведены доступные номера SKU и различия между ними.

Номер SKU	Максимальное число объектов	Частота резервного копирования
Standard	Неограниченно	Раз в 5 дней
Предприятие	Неограниченно	Раз в 3 дня
Премиум	Неограниченно	Ежедневно

До использования этих номера SKU Azure AD DS использовалась модель выставления счетов на основе числа объектов (учетных записей пользователей и компьютеров) в управляемом домене. Переменное ценообразование с учетом количества объектов в управляемом домене больше не используется.

Дополнительные сведения см. на странице цен на Azure AD DS.

Производительность управляемого домена

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

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

Частота резервного копирования

Интервал резервного копирования указывает, насколько часто создается моментальный снимок управляемого домена. Создание резервных копий — это автоматизированный процесс, управляемый платформой Azure. Если возникла проблема с управляемым доменом, служба поддержки Azure может помочь вам восстановить его из резервной копии. Так как синхронизация из Azure AD всегда выполняется в одностороннем режиме, все проблемы, возникшие в управляемом домене, не влияют на Azure AD или локальные среды и функции AD DS.

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

Источник

Упрощенное администрирование доменных служб Active Directory

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

в этом разделе объясняются возможности и преимущества Windows Server 2012 развертывания и администрирования контроллера домена, а также различия между предыдущими развертываниями контроллеров операционной системы и новой реализацией Windows Server 2012.

Windows Server 2012 представила упрощенное администрирование служб домен Active Directory Services, и это было наиболее коренным путем повторного формирования доменов с момента Windows 2000 Server. Упрощенное администрирование доменных служб Active Directory было разработано с учетом двенадцатилетнего опыта работы с Active Directory. Оно улучшает поддержку административных возможностей для архитекторов и администраторов, делает их более гибкими и интуитивно понятными. Достигнуто это было путем создания новых версий существующих технологий, а также расширения возможностей компонентов, появившихся в Windows Server 2008 R2.

Упрощенное администрирование доменных служб Active Directory — это новый подход к развертыванию доменов.

• Развертывание роли доменных служб Active Directory теперь является частью архитектуры диспетчера сервера и допускает удаленную установку.
• Модуль развертывания и настройки доменных служб Active Directory теперь основан на Windows PowerShell даже при использовании нового мастера настройки доменных служб Active Directory.
• Расширение схемы, подготовка леса и домена производятся автоматически в ходе повышения роли контроллера домена и больше не требуют выполнения отдельных задач на специальных серверах, таких как хозяин схемы.
• При повышении роли теперь проводится проверка предварительных требований, с помощью которой подтверждается готовность леса и домена к установке нового контроллера домена, что снижает вероятность сбоев.
• Модуль Active Directory для Windows PowerShell теперь включает командлеты для управления топологией репликации, динамического контроля доступа и других операций.
• В режиме работы леса Windows Server 2012 новые функции не реализуются, а режим работы домена необходим только для подмножества новых функций Kerberos, что упрощает создание однородных сред контроллеров доменов для администраторов.
• Добавлена полная поддержка виртуализированных контроллеров домена, включая автоматическое развертывание и защиту от отката.
  • Дополнительные сведения о виртуализированных контроллерах домена см. в статьях введение в домен Active Directory Services (AD DS) виртуализации (уровня 100).

Кроме того, реализовано множество улучшений, касающихся администрирования и обслуживания:

• Центр администрирования Active Directory включает в себя корзину Active Directory с графическим интерфейсом, управление детальной политикой паролей и средство просмотра журнала Windows PowerShell.
• Новый диспетчер сервера имеет специальные интерфейсы для доменных служб Active Directory, позволяющие отслеживать производительность, проводить анализ на основе рекомендаций, определять критические службы и просматривать журналы событий.
• Групповые управляемые учетные записи служб поддерживают несколько компьютеров, использующих одни и те же субъекты безопасности.
• Оптимизированы выдача и мониторинг относительных идентификаторов (RID) для более эффективного управления существующими доменами Active Directory.

AD DS прибыли от других новых функций, входящих в Windows Server 2012, например:

• объединение сетевых карт и мост для центра обработки данных;
• безопасность DNS и более быстрая доступность зон, интегрированных с Active Directory, после загрузки;
• улучшенная надежность и масштабируемость Hyper-V;
• Сетевая разблокировка BitLocker
• дополнительные модули администрирования компонентов Windows PowerShell.

Интеграция ADPREP

Расширение схемы леса Active Directory и подготовка домена теперь интегрированы в процесс настройки контроллера домена. При повышении роли нового контроллера домена в существующем лесу процесс определяет состояние обновления и этапы расширения схемы и подготовки домена происходят автоматически. Пользователь, устанавливающий первый контроллер домена Windows Server 2012, по-прежнему должен входить в группы «Администраторы предприятия» и «Администраторы схемы» или предоставить альтернативные действительные учетные данные.

Средство Adprep.exe остается на DVD-диске для подготовки отдельных лесов и доменов. Версия средства, включенная в Windows Server 2012, имеет обратную совместимость с Windows Server 2008 x64 и Windows Server 2008 R2. Adprep.exe также поддерживает удаленные команды forestprep и domainprep, так же как средства настройки контроллера домена на основе ADDSDeployment.

Информацию о средстве Adprep и подготовке леса в предыдущих операционных системах см. в разделе Работа с программой Adprep.exe (Windows Server 2008 R2).

Интеграция диспетчера сервера и доменных служб Active Directory

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

Домен Active Directory Services — одна из этих ролей концентратора; запустив диспетчер сервера на контроллере домена или средства удаленного администрирования сервера на Windows 8, вы увидите важные проблемы на контроллерах домена в лесу.

Эти представления включают в себя:

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

Корзина в центре администрирования Active Directory

В Windows Server 2008 R2 впервые появилась корзина Active Directory, которая позволяет восстанавливать удаленные объекты Active Directory без восстановления из резервной копии, перезапуска доменных служб Active Directory или перезагрузки контроллеров домена.

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

Детальная политика паролей в центре администрирования Active Directory

В Windows Server 2008 появилась детальная политика паролей, которая позволяет администраторам настроить несколько политик паролей и блокировки учетных записей в домене. Это решение позволило гибко управлять более или менее строгими правилами паролей на основе пользователей и групп. У него не было отдельного интерфейса управления, и администраторам приходилось настраивать его с помощью средства Ldp.exe или Adsiedit.msc. В Windows Server 2008 R2 появился модуль Active Directory для Windows PowerShell, который позволил администраторам использовать интерфейс командной строки для управления детальной политикой паролей.

В Windows Server 2012 реализован графический интерфейс для настройки детальной политики паролей. Центр администрирования Active Directory теперь является отправной точкой упрощенного управления детальной политикой паролей для всех администраторов.

Средство просмотра журнала Windows PowerShell в центре администрирования Active Directory

В Windows Server 2008 R2 появился центр администрирования Active Directory, который заменил известную администраторам еще со времен Windows 2000 оснастку «Пользователи и компьютеры Active Directory». Центр администрирования Active Directory предоставляет графический интерфейс для модуля Active Directory для Windows PowerShell.

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

Репликация 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.

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

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

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

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

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

Архитектура развертывания роли доменных служб Active Directory и управления ею

Функциональные возможности диспетчера сервера и модуля Windows PowerShell ADDSDeployment, связанные с развертыванием роли доменных служб Active Directory и управлением ею, обеспечиваются следующими основными сборками:

• Microsoft.ADroles.Aspects.dll
• Microsoft.ADroles.Instrumentation.dll
• Microsoft.ADRoles.ServerManager.Common.dll
• Microsoft.ADRoles.UI.Common.dll
• Microsoft.DirectoryServices.Deployment.Types.dll
• Microsoft.DirectoryServices.ServerManager.dll
• Addsdeployment.psm1
• Addsdeployment.psd1

Оба компонента используют среду Windows PowerShell и ее механизм удаленного вызова команд для удаленной установки и настройки роли.

В Windows Server 2012 также перестроен ряд операций повышения роли, которые ранее обеспечивались программой LSASS.EXE и входили в состав следующих компонентов:

• служба сервера с ролью доменных служб (DsRoleSvc);
• библиотека DSRoleSvc.dll (загружаемая службой DsRoleSvc).

Эта служба должна быть установлена и запущена для повышения и понижения роли, а также клонирования виртуальных контроллеров домена. При установке роли доменных служб Active Directory эта служба добавляется по умолчанию и для нее устанавливается тип запуска «Вручную». Не отключайте эту службу.

Архитектура 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.

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

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

Результаты этих тестов регистрируются через канал операционного журнала событий DirectoryServices-Deployment в категории задач Основные и всегда имеют код события 103.

Проверка предварительных требований с помощью Windows PowerShell

В модуле Windows PowerShell ADDSDeployment есть командлеты для проверки выполнения каждого командлета развертывания контроллера домена. Их аргументы почти полностью совпадают с аргументами проверяемых командлетов.

• Test-ADDSDomainControllerInstallation
• Test-ADDSDomainControllerUninstallation
• Test-ADDSDomainInstallation
• Test-ADDSForestInstallation
• Test-ADDSReadOnlyDomainControllerAccountCreation

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

Источник