Установка нового дочернего объекта active directory или домена дерева в windows server 2012 (уровень 200)

Выбор лучших инструментов для безопасности Active Directory

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

Вот несколько наиболее распространенных:

• Анализаторы разрешений: Этот инструмент помогает быстро и легко определить, какие права и группы доступа кому-то назначены. Просто введите имя пользователя, и программное обеспечение предоставит иерархическое представление действующих разрешений и прав доступа, что позволит вам быстро определить, как каждый пользователь получил свои права.
• Менеджеры прав доступа: Внедрение менеджера прав доступа может помочь вам управлять разрешениями пользователей, удостовериться что доступ в нужных руках и предоставить вам возможность отслеживать общую активность вашей AD. Эти инструменты также оснащены интуитивно понятными панелями оценки рисков и настраиваемыми отчетами, что позволяет легко продемонстрировать соответствие нормативным требованиям.
• Платформы мониторинга: программное обеспечение для управления серверами и приложениями позволяет быстро и легко получить снимок общего состояния вашего каталога, а также предоставляет способы углубленного изучения контроллеров домена. Вы можете использовать эти платформы для создания пользовательских порогов оповещений и определения того, что является нормальным для вашего сервера, что позволяет избежать невосприимчивости к оповещениям. Они помогают быть на шаг впереди и принимать превентивные меры.
• ПО для удаленного управления: данное ПО разработано, чтобы помочь вам решить проблемы быстро и из любой точки мира. С помощью удаленного доступа вы можете получить контроль над компьютерами, когда пользователь вошел в систему, что дает вам возможность взглянуть на проблемы, с которыми они сталкиваются. Это дает вам лучшее представление о проблеме.
• Менеджеры автоматизации: эти инструменты довольно просты и часто включают в себя интерфейс интерактивных сценариев для создания повторяющихся процессов. У вас есть много задач, которые нужно выполнять на регулярной основе? Менеджер автоматизации позволит вам свернуть эти задачи в «политику», а затем настроить расписание для этой политики.

Физическая структура

Сайты — это физические (а не логические) группы, определяемые одной или несколькими IP- подсетями. AD также содержит определения соединений, отделяя низкоскоростные (например, WAN , VPN ) от высокоскоростных (например, LAN ) каналов. Определения сайтов не зависят от домена и структуры подразделений и являются общими для всего леса. Сайты используются для управления сетевым трафиком, генерируемым репликацией, а также для направления клиентов к ближайшим контроллерам домена (DC). Microsoft Exchange Server 2007 использует топологию сайта для маршрутизации почты. Политики также могут быть определены на уровне сайта.

Физически информация Active Directory хранится на одном или нескольких контроллерах однорангового домена , заменяя модель NT PDC / BDC . Каждый DC имеет копию Active Directory. Серверы, присоединенные к Active Directory и не являющиеся контроллерами домена, называются рядовыми серверами. Подмножество объектов в разделе домена реплицируется на контроллеры домена, настроенные как глобальные каталоги. Серверы глобального каталога (GC) предоставляют глобальный список всех объектов в лесу. Серверы глобального каталога реплицируют на себя все объекты из всех доменов и, следовательно, предоставляют глобальный список объектов в лесу. Однако для минимизации трафика репликации и сохранения небольшого размера базы данных GC реплицируются только выбранные атрибуты каждого объекта. Это называется частичным набором атрибутов (PAS). PAS можно изменить, изменив схему и пометив атрибуты для репликации в GC. В более ранних версиях Windows для связи использовался NetBIOS . Active Directory полностью интегрирована с DNS и требует TCP / IP — DNS. Для полноценной работы DNS-сервер должен поддерживать записи ресурсов SRV , также известные как служебные записи.

Репликация

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

У каждого канала может быть «стоимость» (например, DS3 , T1 , ISDN и т. Д.), И KCC соответственно изменяет топологию канала связи. Репликация может происходить транзитивно через несколько связей сайтов на мостах связей сайтов с одним и тем же протоколом , если стоимость невысока, хотя KCC автоматически стоит за прямую связь между сайтами меньше, чем за транзитивные соединения. Репликацию между сайтами можно настроить так, чтобы она происходила между сервером-плацдармом на каждом сайте, который затем реплицирует изменения на другие контроллеры домена в пределах сайта. Репликация для зон Active Directory настраивается автоматически при активации DNS в домене на основе сайта.

Репликация Active Directory использует удаленные вызовы процедур (RPC) по IP (RPC / IP). Между сайтами SMTP можно использовать для репликации, но только для изменений в GC схемы, конфигурации или частичного набора атрибутов (глобального каталога). SMTP нельзя использовать для репликации раздела Домена по умолчанию.

Доверительные отношения (и типы доверия)

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

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

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

Типы доверия 

Существует несколько типов доверия в Active Directory. Мы перечислили их в таблице ниже:

Подготовка доменов Active Directory

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

Если в лесу Active Directory несколько доменов, их можно подготовить несколькими способами. Выберите тот вариант, который соответствует вашим целям. Если домен всего один, вы можете пропустить этот шаг, так как команда PrepareAD на шаге 2 уже подготовила для вас домен.

Общее

C помощью службы Active Directory создаются учетные записи компьютеров, проводится подключение их к домену, производится управление компьютерами, контроллерами домена и организационными подразделениями (ОП).
Для управления Active Directory предназначены средства администрирования и поддержки. Перечисленные ниже инструменты реализованы и виде оснасток консоли ММС (Microsoft Management Console):

• Active Directory — пользователи и компьютеры (Active Directory Users and Computers) позволяет управлять пользователями, группами, компьютерами и организационными подразделениями (ОП);
• Active Directory — домены и доверие (Active Directory Domains and Trusts) служит для работы с доменами, деревьями доменов и лесами доменов;
• Active Directory — сайты и службы (Active Directory Sites and Services) позволяет управлять сайтами и подсетями;
• Результирующая политика (Resultant Set of Policy) используется для просмотра текущей политики пользователя или системы и для планирования изменений в политике.

В Microsoft Windows 2003 Server можно получить доступ к этим оснасткам напрямую из меню Администрирование (Administrative Tools).
Еще одно средство администрирования — оснастка СхемаActive Directory (Active Directory Schema) — позволяет управлять и модифицировать схему каталога.

Как соотносятся Active Directory, домен и контроллер домена

Главной единицей, в которой происходят основные процессы по управлению пользователями, компьютерами, оборудованием, процессами и прочим является домен. Ядром домена является контроллер домена, который, собственно, и отвечает за управление перечисленными элементами. Поэтому при изучении Active Directory фокус направлен на объекты, которыми управляет контроллер домена. Наиболее часто используемые объекты:

• пользователи
• компьютеры
• группы
• периферийные устройства
• сетевые службы

Каждый объект уникально идентифицируется своим именем и атрибутами.

Эти объекты могут быть сгруппированы в организационные подразделения (OU) по любому количеству логических или бизнес-потребностей. Затем объекты групповой политики (GPO) можно связать с организационным подразделением, чтобы централизованно настроить различных пользователей или компьютеры в организации.

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

Несколько лесов

Лес — это не просто описание всех деревьев, управляемых одной и той же группой администрирования, это общие элементы для всех доменов, которые находятся на уровне леса. Эти общие черты описаны как ‘схема.Схема содержит схему леса и всех баз данных контроллера домена в нем. Это имеет объединяющий эффект, который выражается в общем GC, который реплицируется на все контроллеры в одном лесу.

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

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

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

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

Сетевые порты, используемые отношениями доверия

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

Важно!

Доменные службы Active Directory не поддерживают ограничение трафика удаленного вызова процедур Active Directory определенными портами.

Ознакомьтесь с разделом Windows Server 2008 и более поздних версий статьи службы поддержки Майкрософт Настройка брандмауэра для доменов и отношений доверия Active Directory, чтобы узнать о портах, необходимых для доверия лесов.

Развертывание управляемого домена

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

1. Чтобы создать управляемый домен, щелкните Создать. Отобразится примечание о том, что некоторые параметры конфигурации, такие как DNS-имя или виртуальная сеть, нельзя изменить после создания управляемого домена Azure AD DS. Чтобы продолжить, нажмите кнопку ОК.

2. Процесс подготовки управляемого домена может занять до одного часа. На портале отображается уведомление, которое демонстрирует ход выполнения развертывания Azure AD DS. Щелкните это уведомление, чтобы просмотреть подробное описание процесса развертывания.

3. Выберите группу ресурсов, например myResourceGroup, а затем в списке ресурсов Azure выберите управляемый домен, например aaddscontoso.com. На вкладке Обзор можно увидеть, что сейчас выполняется развертывание управляемого домена. Настроить управляемый домен можно только после его полной подготовки.

4. После полной подготовки управляемого домена на вкладке Обзор состояние домена отображается как Выполняется.

Важно!

Управляемый домен связан с вашим клиентом Azure AD. В процессе подготовки Azure AD DS создает в вашем клиенте Azure AD два корпоративных приложения с именами Domain Controller Services и AzureActiveDirectoryDomainControllerServices. Эти корпоративные приложения нужны для обслуживания управляемого домена. Не удаляйте эти приложения.

Улучшения в области выдачи идентификаторов 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 см. в разделе Принципы работы идентификаторов безопасности.

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

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

• Общие сведения о требованиях к DNS для управляемого домена
• Создание управляемого домена
• Добавление пользователей с правами администратора в службу управления доменами
• Включение учетных записей пользователей для Azure AD DS и создание хэшей паролей

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

Tutorial: Configure virtual networking for an Azure Active Directory Domain Services instance (Учебник по настройке виртуальных сетей для экземпляра доменных служб Azure Active Directory)

Windows Server 2008 R2

Поддерживаемые операционные системы контроллера домена:

• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2

Функции режима работы домена Windows Server 2008 R2

• Все функции Active Directory по умолчанию, все функции из режима работы домена Windows Server 2008, а также:
  • Контроль механизма проверки подлинности, добавляющий в пакет сведения о способе входа в систему (смарт-карта или имя пользователя и пароль), который используется для проверки подлинности пользователей домена в маркере Kerberos каждого пользователя. Если эта функция включена в сетевой среде, в которой развернута инфраструктура управления федеративными удостоверениями, например службы федерации Active Directory (AD FS), то данные маркера могут извлекаться при каждой попытке доступа пользователя к поддерживающим утверждения приложениям, которые были разработаны для определения авторизации на основе способа входа пользователя в систему.
  • Автоматическое управление именем субъекта-службы для служб, запущенных на определенном компьютере в контексте управляемой учетной записи службы при изменении имени или имени узла DNS-сервера учетной записи компьютера. Дополнительные сведения об управляемых учетных записях службы см. в статье Service Accounts Step-by-Step Guide (Пошаговое руководство по учетным записям служб).

История

Как и многие другие усилия в области информационных технологий, они возникли в результате с использованием запросов на комментарии (RFC). Engineering Task Force Интернета (IETF), который контролирует процесс RFC, принял многочисленные РЛК инициированных распространёнными участниками. Например, LDAP лежит в основе Active Directory. Также каталоги X.500 и организационная единица предшествовали концепции Active Directory, которая использует эти методы. Концепция LDAP начала появляться еще до основания Microsoft в апреле 1975 года, а RFC появились еще в 1971 году. RFC, вносящие вклад в LDAP, включают RFC 1823 (по API LDAP, август 1995 года), RFC 2307, RFC 3062 и RFC 4533.

Microsoft представила Active Directory в 1999 году, впервые выпустила ее с выпуском Windows 2000 Server и изменила ее, чтобы расширить функциональные возможности и улучшить администрирование в Windows Server 2003 . Поддержка Active Directory была также добавлена ​​в Windows 95, Windows 98 и Windows NT 4.0 с помощью патча, при этом некоторые функции не поддерживаются. Дополнительные улучшения появились в последующих версиях Windows Server . В Windows Server 2008 в Active Directory были добавлены дополнительные службы, такие как службы федерации Active Directory . Часть каталога, отвечающая за управление доменами, которая ранее была основной частью операционной системы, была переименована в доменные службы Active Directory (ADDS) и стала ролью сервера, как и другие. «Active Directory» стала общим названием для более широкого диапазона служб каталогов. По словам Байрона Хайнса, все, что связано с идентификацией, было перенесено под знамя Active Directory.

Включение учетных записей пользователей для Azure AD DS

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

Примечание

После настройки хэши паролей в требуемом формате сохраняются в управляемом домене. Если вы удалите управляемый домен, вместе с ним будут удалены все сохраненные хэши паролей.

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

[/azure/active-directory/cloud-sync/what-is-cloud-sync#comparison-between-azure-ad-connect-and-cloud-sync]. Для доступа к присоединенным к домену виртуальным машинам локальные пользователи должны быть синхронизированы с помощью Azure AD Connect. См. сведения о .

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

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

Совет

Если клиент Azure AD содержит и пользователей в облаке, и пользователей из локального каталога Azure AD, необходимо выполнить оба блока действий.

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

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

Чтобы изменить пароль для облачного пользователя, выполните от его имени следующие действия:

1. Откройте Панель доступа Azure AD по адресу https://myapps.microsoft.com.

   

   

   

   

   

   

   

   

   

2. Вверху справа щелкните имя и выберите Профиль в раскрывающемся меню.

3. На странице Профиль щелкните Изменить пароль.

4. На странице Изменение пароля введите существующий (старый) пароль, а затем введите и подтвердите новый пароль.

5. Нажмите кнопку Submit (Отправить).

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

Корзина в центре администрирования 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 см. в пошаговом руководстве по работе с корзиной Active Directory (Windows Server 2008 R2).