Archive directory что это
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
В наших прошлых материалах мы разобрали общие вопросы касающиеся служб каталогов и Active Directory. Теперь пришла пора переходить к практике. Но не спешите бежать к серверу, перед развертыванием доменной структуры в вашей сети необходимо ее спланировать и иметь четкое представление о назначении отдельных серверов и процессах взаимодействия между ними.
Перед тем как создавать ваш первый контроллер домена необходимо определиться с режимом его работы. Режим работы определяет доступные возможности и зависит от версии применяемой операционной системы. Мы не будем рассматривать все возможные режимы, кроме тех которые имеют актуальность на текущий момент. Таких режимов три: Windows Server 2003, 2008 и 2008 R2.
Режим Windows Server 2003 следует выбирать только тогда, когда в вашей инфраструктуре уже развернуты сервера на данной ОС и планируется использовать один или несколько таких серверов в качестве контроллеров домена. В остальных случаях нужно выбирать режим Windows Server 2008 или 2008 R2 в зависимости от купленных лицензий. Следует помнить, что режим работы домена можно всегда повысить, а вот понизить уже не удастся (разве что восстановив из резервной копии), поэтому подходите к данному вопросу осмотрительно, с учетом возможных расширений, лицензий в филиалах и т.д. и т.п.
Мы сейчас не будем подробно рассматривать сам процесс создания контроллера домена, к этому вопросу мы вернемся позже, а сейчас хотим обратить ваше внимание на то, что в полноценной структуре Active Directory контроллеров домена должно быть не менее двух. В противном случае вы подвергаете себя неоправданному риску, так как в случае отказа единственного контроллера домена ваша структура AD будет полностью уничтожена. Хорошо если будет актуальная резервная копия и из нее удастся восстановиться, в любом случае все это время ваша сеть будет полностью парализована.
Поэтому сразу же после создания первого контроллера домена нужно развернуть второй, вне зависимости от размеров сети и бюджета. Второй контроллер должен быть предусмотрен еще на стадии планирования и без него за развертывание AD даже не стоит браться. Также не стоит совмещать роль контроллера домена с любыми иными серверными ролями, в целях обеспечения надежности операций с базой AD на диске отключается кэширование записи, что приводит к резкому падению производительности дисковой подсистемы (это объясняет и долгую загрузку контроллеров домена).
В итоге наша сеть должна принять следующий вид:
Вопреки распространенному мнению, все контроллеры в домене равнозначны, т.е. каждый контроллер содержит полную информацию о всех объектах домена и может обслужить клиентский запрос. Но это не значит, что контроллеры взаимозаменяемы, непонимание этого момента зачастую приводит к отказам AD и простою сети предприятия. Почему так происходит? Самое время вспомнить про роли FSMO.
Когда мы создаем первый контроллер, то он содержит все доступные роли, а также является глобальным каталогом, с появлением второго контроллера ему передаются роли хозяина инфраструктуры, хозяина RID и эмулятора PDC. Что будет если администратор решил временно вывести из строя сервер DC1, например чтобы почистить от пыли? На первый взгляд ничего страшного, ну перейдет домен в режим «только чтение», но работать то будет. Но мы забыли про глобальный каталог и если в вашей сети развернуты приложения требующие его наличия, например Exchange, то вы узнаете об этом раньше, чем снимете крышку с сервера. Узнаете от недовольных пользователей, да и руководство вряд ли придет в восторг.
Из чего следует вывод: в лесу должно быть не менее двух глобальных каталогов, а лучше всего по одному в каждом домене. Так как у нас домен в лесу один, то оба сервера должны быть глобальными каталогами, это позволит вам без особых проблем вывести любой из серверов на профилактику, временное отсутствие каких либо ролей FSMO не приводит к отказу AD, а лишь делает невозможным создание новых объектов.
Как администратор домена, вы должны четко знать каким образом роли FSMO распределены между вашими серверами и при выводе сервера из эксплуатации на длительный срок передавать эти роли другим серверам. А что будет если сервер содержащий роли FSMO необратимо выйдет из строя? Ничего страшного, как мы уже писали, любой контроллер домена содержит всю необходимую информацию и если такая неприятность все же произошла, то нужно будет выполнить захват необходимых ролей одним из контроллеров, это позволит восстановить полноценную работу службы каталогов.
Проходит время, ваша организация растет и у нее появляется филиал в другом конце города и возникает необходимость включить их сеть в общую инфраструктуру предприятия. На первый взгляд ничего сложного, вы настраиваете канал связи между офисами и размещаете в нем дополнительный контроллер. Все бы хорошо, но есть одно но. Данный сервер вы контролировать не можете, а следовательно не исключен несанкционированный доступ к нему, да и местный админ вызывает у вас сомнения в его квалификации. Как быть в такой ситуации? Для этих целей специально существует особый тип контроллера: контроллер домена доступный только на чтение (RODC), данная функция доступна в режимах работы домена начиная с Windows Server 2008 и выше.
Контроллер домена доступный только для чтения содержит полную копию всех объектов домена и может быть глобальным каталогом, однако не позволяет вносить никаких изменений в структуру AD, также он позволяет назначить любого пользователя локальным администратором, что позволит ему полноценно обслуживать данный сервер, но опять таки без доступа к службам AD. В нашем случае это то, что «доктор прописал».
Следующий фактор, отравляющий нам жизнь в этой ситуации, это репликация. Как известно, все изменения, сделанные на одном из контроллеров домена, автоматически распространяются на другие и называется этот процесс репликацией, он позволяет иметь на каждом контроллере актуальную и непротиворечивую копию данных. Служба репликации не знает о нашем филиале и медленном канале связи и поэтому все изменения в офисе тут же будут реплицироваться в филиал, загружая канал и увеличивая расход трафика.
Здесь мы вплотную подошли к понятию сайтов AD, которые не следует путать с интернет сайтами. Сайты Active Directory представляют способ физического деления структуры службы каталогов на области отделенные от других областей медленными и/или нестабильными каналами связи. Сайты создаются на основе подсетей и все клиентские запросы отправляются в первую очередь контроллерам своего сайта, также крайне желательно иметь в каждом сайте свой глобальный каталог. В нашем случае потребуется создать два сайта: AD Site 1 для центрального офиса и AD Site 2 для филиала, точнее один, так как по умолчанию структура AD уже содержит сайт, куда входят все ранее созданные объекты. Теперь рассмотрим как происходит репликация в сети с несколькими сайтами.
Будем считать, что наша организация немного подросла и главный офис содержит целых четыре контроллера домена, репликация между контроллерами одного сайта называется внутрисайтовой и происходит моментально. Топология репликации строится по схеме кольца с условием, чтобы между любыми контроллерами домена было не более трех шагов репликации. Схема кольца сохраняется до 7 контроллеров включительно, каждый контроллер устанавливает связь с двумя ближайшими соседями, при большем числе контроллеров появляются дополнительные связи и общее кольцо как бы превращается в группу наложенных друг на друга колец.
Межсайтовая репликация происходит иначе, в каждом домене автоматически выбирается один из серверов (сервер-плацдарм) который устанавливает связь с аналогичным сервером другого сайта. Репликация по умолчанию происходит раз в 3 часа (180 минут), однако мы можем установить собственное расписание репликации и для экономии трафика все данные передаются в сжатом виде. При наличии в сайте только RODC репликация происходит однонаправленно.
Безусловно, затронутые нами темы весьма глубоки и в данном материале мы только слегка их коснулись, однако это тот необходимый минимум знаний, который нужно иметь перед практическим внедрением Active Directiry в инфраструктуру предприятия. Это позволит избежать глупых ошибок при развертывании и авральных ситуаций при обслуживании и расширении структуры, а каждая из поднятых тем еще будет обсуждаться более подробно.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Active Directory vs. Azure Active Directory
Традиционно, для управления корпоративной сетью используется Active Directory. Но все чаще организации внедряют в свою работу различные облачные службы, которые требуют создания своих учетных записей. Инструментом для создания и управления учетными записями пользователей, применыемых в различных облачных службах Microsoft, которые приобретает организация, является Azure Active Directory. В этой статье мы поговорим о некоторых отличиях между Active Directory и Azure Active Directory, а также рассмотрим основные сценарии их синхронизации.
Я уверена, что подавляющее большинство тех, кто читает эту статью, знакомы с Active Directory, которая является частью операционных систем Windows Server и представляет собой службу каталогов, предлагаемую компанией Microsoft. Имея учетную запись AD, пользователь аутентифицируется в системе и получает доступ к приложениям, файловым службам, принтерам и другим локальным ресурсам.
Так же, как и локальная Active Directory, Azure Active Directory аутентифицирует пользователей и предоставляет им доступ к приложениям. Однако, Azure Active Directory предназначена для работы пользователь не в локальной инфраструктуре, а при работе со сторонними облачными приложениями, такими как Office365 и Windows Intune.
Например, ваша организация приобретает подписку на Windows Intune. При этом вы, как администратор, получаете доступ к порталу управления Windows Intune и должны предоставить доступ другим пользователям в вашей сети (всем или нескольким – это уже детали). Windows Intune – это облачная служба Microsoft, которая не работает с локальной Active Directory. Для того, чтобы создать учетные записи пользователей для доступа к облачным службам, которые внедряет и использует организация, необходимо использовать Azure Active Directory.
C технической точки зрения, нужно отметить, что для доступа к данным в локальной службе Active Directory бизнес-приложения могут использовать LDAP, а сторонние облачные приложения могут взаимодействовать с данными с помощью API Graph. Для аутентификации в AD DS используется протокол Kerberos, а в Azure Active Directory – OAuth 2.0. На схеме далее показано, как приложения, размещенные либо локально, либо в облаке, используют похожие методологии для доступа к данными удостоверений, которые хранятся в наиболее подходящей для них службе удостоверений.
Но вернемся к нашему примеру. Компания приобрела подписку на Windows Intune, и теперь системный администратор должен создать в Azure AD учетные записи для пользователей. Сделать он это может конечно ручками через графический интерфейс или даже использовать командлеты и скрипты PowerShell. Но, используя этот вариант добавления пользователей, вы создаете абсолютно самостоятельных пользователей, никак не связанных с теми, что давно уже существуют в вашей локальной сетке. Да, логины могут совпадать, но могут и отличаться; пароли – тем более. Все это – огромный источник потенциальной головной боли для админа и регулярных обращений от пользователей в службу поддержки. Для того, чтобы эти проблемы минимизировать предлагается три сценария синхронизации AD и Azure AD, о которых мы поговорим далее.
Синхронизация Active Directory и Azure Active Directory
1 Сценарий синхронизации каталога
Сценарий синхронизации каталогов используется для синхронизации локальных объектов доменной сети в облако. При реализации этого сценария в итоге вы получите учетную запись пользователя в Azure Active Directory, которая будет совпадать с локальной учетной записью во всем, кроме пароля. Пароли при реализации сценария синхронизации каталога НЕ синхронизируются. Поэтому теперь вы говорите вашим пользователям, что для доступа, например, к Windows Intune можно использовать свой обычный логин, а вот пароль нужно будет придумать другой. В этом случае, пользователь при доступе к облачной службе будет аутентифицирован с помощью именно Azure Active Directory. Примерная схема того, как работает этот процесс, представлена ниже.
После того, как настройка выполнена, администраторы могут управлять объектами каталога, используя локальную Active Directory, и эти изменения будут синхронизированы с клиентскими компьютерами. Синхронизация службы каталогов выполняется по расписанию и синхронизируются с Azure AD.
2 Синхронизация Active Directory с помощью сценария синхронизации паролей
Все-таки больным местом учетных записей пользователей являются не логины, а пароли. Логин обычно запомнить не сложно, а вот иметь разные пароли для доступа к разным ресурсам – испытание для пользователя. Поэтому он либо придумывает простые пароли, либо пишет их на стикерах и клеит на монитор, либо догадывается использовать везде один и тот же пароль. Существует расширение сценария синхронизации каталога – сценарий синхронизации паролей. Если на компьютере с уже реализованной синхронизацией каталогов включить синхронизацию паролей, то сотрудники вашей организации смогут подключаться к облачными службам Microsoft (например, Office 365, Dynamics CRM, Windows InTune), используя пароль от локальной учетной записи. Изменение пароля в локальной корпоративной сети будут синхронизированы с облаком, причем пароли синхронизируются чаще, чем другие данные каталогов.
Ниже приведена схема синхронизации Active Directory с помощью сценария синхронизации паролей. Чтобы пароль был синхронизирован, средство синхронизации каталогов извлекает хэш пароля пользователя из локальной службы Active Directory и синхронизирует его с Azure Active Directory.
Теперь со спокойной душой говорим пользователям, что мы используем новую облачную службу, доступ к которой можно получить со своим обычным логином и паролем. Все довольны, все счастливы.
Тем не менее, при реализации сценария синхронизации паролей, пользователь все равно проходит процесс аутентификации с помощью учетной записи Azure Active Directory, а мы хотим пойти дальше, и использовать для аутентификации именно локальную Active Directory. Для того, чтобы нашу задумку осуществить, необходимо использовать сценарий синхронизации Active Directory с помощью единого входа.
3 Синхронизация Active Directory с помощью сценария единого входа
Для реализации единого входа должен быть реализован сценарий синхронизации каталога и построена инфраструктура службы токенов безопасности (STS). Azure AD поддерживает сценарии единого входа, которые используют одну из следующих служб токенов безопасности: Active Directory Federation Services, поставщик удостоверений Shibboleth, а также сторонние поставщики удостоверений.
Процесс работы сценария единого входа представлен на следующей схеме.
При реализации сценария единого входа настраиваются федеративные отношения между службой STS (Security Token Service) и системой проверки подлинности Azure Active Directory. Пользователь при попытке подключения к облачной службе будет перенаправлен на сервер службы STS. Например, при использовании службы ADFS, пользователь будет перенаправлен на ADFS сервер, что можно будет увидеть по изменению адреса в браузере:
После успешной аутентификации, пользователь с учетной записью локального каталога Active Directory получит токен проверки подлинности от локальной службы STS и с помощью которого получит доступ к облачной службе. Принципиальным отличием от первых двух сценариев является то, что в сценарии единого входа пользователь аутентифицируется с помощью Windows Server Active Directory.
Надеюсь, данная статья дала вам представление о разнице между Active Directory и Azure Active Directory и сценариях их синхронизации.
Разворачиваем Active Directory всеми возможными методами
Одним из реально полезных нововведений в Windows Server 2019 является возможность вводить серверы, не делая Sysprep или чистую установку. Развернуть инфраструктуру на виртуальных серверах с Windows Server никогда еще не было так просто.
Устанавливаем роль
RSAT или локальный сервер с GUI:
Переходим в добавление компонентов и выбираем AD DS.
Если вы не знаете, как называется компонент системы, можно выполнить команду и получить список доступных компонентов, их зависимостей и их имена.
Копируем имя компонента и приступаем к установке.
Windows Admin Center:
Переходим в «Роли и компоненты» и выбираем ADDS (Active Directory Domain Services).
И это буквально всё. Управлять Active Directory через Windows Admin Center на текущий момент невозможно. Его упоминание не более чем напоминание о том, насколько он пока что бесполезен.
Повышаем сервер до контроллера домена
А для этого создаем новый лес.
RSAT или локальный серверс GUI:
Очень рекомендуем оставлять все по умолчанию, все компоненты из коробки прекрасно работают и их не нужно трогать без особой на то необходимости.
Сначала нужно создать лес и установить пароль от него. В Powershell для паролей есть отдельный тип переменной – SecureString, он используется для безопасного хранения пароля в оперативной памяти и безопасной его передачи по сети.
Любой командлет который использует чей угодно пароль нужно вводит таким образом. Сначала записываем пароль в SecureString, а затем указываем эту переменную в командлет.
Как и в установке через GUI, даже вывод в консоль один и тот же. В отличие от сервера с GUI, как установка роли, так и установка сервера в качестве контроллера домена не требует перезагрузки.
Установка контроллера с помощью RSAT занимает больше времени, чем через Powershell.
Управляем доменом
Теперь, чтобы понять насколько сильно различается управление Active Directory через Powershell и AD AC (Active Directory Administrative Center), рассмотрим пару рабочих примеров.
Создание нового пользователя
Отличий между AD DC и Powershell никаких.
Включить пользователя
RSAT или локальный серверс GUI:
Через GUI пользователю нужно сначала задать пароль отвечающий GPO и только после этого его можно будет включить.
Через Powershell почти то же самое, только пользователя можно сделать активным даже без пароля.
Добавляем пользователя в группу
RSAT или локальный сервер с GUI:
С помощью AD DC нужно перейти в свойства пользователя, найти графу с членством пользователя в группах, найти группу в которую мы хотим его поместить и добавить его наконец, а затем кликнуть OK.
Если мы не знаем как называется нужная нам группа, получить их список мы можем с помощью:
Получить группу со всеми свойствами можно так:
Ну и наконец добавляем пользователя в группу:
Далее, из-за того, что в Powershell все является объектами, мы как и через AD DC должны сначала получить группу пользователя, а затем добавить его в неё.
Затем добавляем этот объект в группу:
Как видим, отличий в управлении AD через AD AC и Powershell почти нет.
Вывод:
Если вы уже сталкивались с развертыванием AD и других служб, то вы, возможно подмечали сходство развертывания через RSAT и Powershell, и насколько на самом деле все похоже. GUI в ядре, как никак.
Надеемся, статья была полезна или интересна.
Ну и напоследок пару дельных советов:
Предлагаем обновлённый тариф UltraLite Windows VDS за 99 рублей с установленной Windows Server 2019 Core.
Описание Active Directory
Active Directory содержит иерархическую структуру для администратора, позволяющую организовывать объекты в его домене. Должное планирование структуры этого каталога позволяет администратору упростить делегирование администрирования и облегчить управление настольными системами.
Структура Active Directory
Оснастка Active Directory Users and Computers
Организационные единицы
Администратор может также создавать организационные единицы (OU). Обычно OU создаются для упрощения административного управления доменом. Для создания OU выполните следующие шаги.
Вы можете создавать вложенные OU, помещая их внутри этой OU, но обычно при создании структуры OU не рекомендуется создавать более 5 уровней вложенности.
Контейнеры
Контейнеры создаются системой Windows Server 2003 по различным причинам. По умолчанию создаются следующие контейнеры.
Если выбрать View/Advanced Features (Вид/Дополнительно) в Active Directory Users and Computers, то вы увидите следующие дополнительные контейнеры.
Объекты Active Directory
Еще одним элементом, содержащимся в Active Directory, являются объекты. Объекты размещаются внутри организационных единиц и контейнеров Active Directory. Вы можете помещать объекты в определенной OU и определять групповую политику по этой OU, чтобы упрощать задачи администрирования или управлять компьютерной средой. К примерам объектов можно отнести принтеры, пользовательские учетные записи, компьютерные учетные записи и группы безопасности.
LDAP и Active Directory
Отличительные имена
Ниже приводится пример того, как выглядит DN для организационной единицы Domain Controllers в Active Directory для вымышленного домена company.com:
Так что же описывает это DN? Глядя на него, вы можете сказать, что организационная единица Domain Controllers находится в домене company.com.
В качестве еще одно примера предположим, что у вас имеется структура OU Sales в домене company.com. Внутри OU Sales находится еще одна OU с именем West. Внутри OU West у вас имеется учетная запись с именем Mary Smith. Для доступа к этой учетной записи используется следующее DN:
Как видно из этих примеров, описание DN дается снизу вверх по пути в Active Directory, начиная с объекта и вплоть до корня домена.
Относительные отличительные имена
Относительное отличительное имя (relative distinguished name) в пути LDAP содержит информацию об объекте Active Directory в контексте текущего рассматриваемого пути. Если взять предыдущий пример получения объекта с помощью отличительного имени (DN) для пользовательской учетной записи Mary Smith, то DN описывалось как
Относительное отличительное имя для этого объекта