Что такое active directory

Введение

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

Пойдем по пути наименьшего сопротивления. Диск С:\ уже настроен, теперь займемся вторым, девственно чистым диском Е:\. Для тех, кто только что включил телевизор, напомню, что диск Е:\ представляет собой массив из четырех SCSI-дисков (RAID 5) и создан только для хранения файлов пользователей, программ, фильмов, музыки и т.д.

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

Условимся, что в предполагаемой конторе есть три подразделения:

1. начальство (группа «HEAD»),
2. бухгалтерия (группа «Бухгалтерия»),
3. экономисты (группа «Экономисты»).

Вот такая странная контора.

Сходство клиентаClient affinity

Контроллеры домена используют сведения о сайте для информирования Active Directory клиентов о контроллерах домена, находящихся на ближайшем сайте в качестве клиента.Domain controllers use site information to inform Active Directory clients about domain controllers present within the closest site as the client. Например, рассмотрим клиент на сайте в Сиэтле, который не знает свое назначение сайта и связывает контроллер домена с сайтом Атланта.For example, consider a client in the Seattle site that does not know its site affiliation and contacts a domain controller from the Atlanta site. Основываясь на IP-адресе клиента, контроллер домена в Атланта определяет сайт, на котором находится клиент, и отправляет сведения о сайте обратно клиенту.Based on the IP address of the client, the domain controller in Atlanta determines which site the client is actually from and sends the site information back to the client. Контроллер домена также информирует клиента о том, является ли выбранный контроллер домена ближайшим к нему.The domain controller also informs the client whether the chosen domain controller is the closest one to it. Клиент кэширует сведения о сайте, предоставляемые контроллером домена в Атланта, запрашивает запись ресурса для конкретного узла (SRV) (запись ресурса службы доменных имен (DNS), используемую для поиска контроллеров домена для AD DS) и находит контроллер домена в пределах одного сайта.The client caches the site information provided by the domain controller in Atlanta, queries for the site-specific service (SRV) resource record (a Domain Name System (DNS) resource record used to locate domain controllers for AD DS) and thereby finds a domain controller within the same site.

Обнаружив контроллер домена на том же сайте, клиент предотвращает обмен данными через WAN Links.By finding a domain controller in the same site, the client avoids communications over WAN links. Если на клиентском сайте не расположены контроллеры домена, контроллер домена с наименьшими затратами по отношению к другим подключенным сайтам объявляет себя (регистрирует запись ресурса службы (SRV) в DNS) на сайте, который не имеет контроллера домена.If no domain controllers are located at the client site, a domain controller that has the lowest cost connections relative to other connected sites advertises itself (registers a site-specific service (SRV) resource record in DNS) in the site that does not have a domain controller. Контроллеры домена, опубликованные в DNS, находятся на ближайшем сайте в соответствии с определением топологии сайта.The domain controllers that are published in DNS are those from the closest site as defined by the site topology. Этот процесс гарантирует, что каждый сайт имеет предпочитаемый контроллер домена для проверки подлинности.This process ensures that every site has a preferred domain controller for authentication.

Дополнительные сведения о процессе поиска контроллера домена см. в разделе Active Directory Collection.For more information about the process of locating a domain controller, see Active Directory Collection.

Приложение к статье. Служба доменных имен (DNS) в Active Directory

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

В операционной системе Windows 2000 служба
DNS осуществляет (может этого и не делать:-) динамическую
регистрацию клиентам своих доменных имен, что существенно
упрощает администрирование таких баз, которые еще принято
называть зонами. В Windows 2000 мы можем
реализовать размещение зоны в рамках службы каталогов
Active Directory (AD), что дает повышение отказоустойчивости,
доступности и управляемости службы. Многие механизмы,
использующие AD, также не могут обойтись без DNS. Суть
в том, что «локализация» ближайшего сервера
скажем глобального каталога (GC) происходит на основе
специального типа ресурсных записей, называемых локаторами
ресурсов, или как и обозначают — SRV-записи.

Эти записи используются для определения
местоположения серверов, предоставляющие услуги определенных
служб. SRV-запись является «синонимом»,
или еще говорят, DNS-псевдонимом службы. Записывается
это так:
 _Service._Protocol.DnsDomainName
где: Service — название службы (это может быть kerberos,gc,
ldap и др.) Protocol — протокол, при помощи которого
клиенты могут подключиться к данной службе ( обычно это tcp,
udp); DnsDomainName — DNS-имя домена, к
которому принадлежит сервер (в нашем случае songi.local).

Для каждого DNS-домена формируется
набор SRV-записей, которые группируются в специальные
поддомены:

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

Благодаря этому клиенты могут осуществлять
поиск серверов, основываясь не на имени службы, а на
роли, исполняемой искомым сервером. Псевдонимы, используемые
для создания ресурсных записей данного поддомена будут
выглядеть так:
_Service._Protocol.Dctype._msdcs.DnsDomainName
Параметр Dctype определяет роль сервера (pdc, dc, gc, domains). Например
сервера, выполняющие функции котроллера домена и принадлежащего к домену
songi.local, будет создан DNS-псевдоним:
_ldap._tcp.dc._msdcs.songi.local _sites — вспомогательный домен, используемый
для группировки ресурсных записей, отражающих физическую структуру
сети (с точки зрения узловой инфраструктуры).

Этот домен выполняет функцию контейнера
для других поддоменов, имена которых соответствуют
именам узлов. Псевдонимы записываются в следующем формате:
_Service._Protocol.SiteName._sites.DnsDomainName
Когда осуществляется обращение к серверу DNS, запрос включает в себя
всю необходимую для поиска информацию (такую как наименование службы,
протокол, имя домена). Служба DNS в первую очередь пытается найти в
базе данных контроллер домена, принадлежащий к тому же узлу, что и «запрашивающий» нужную
службу. Для этого служба DNS просматривает все SRV-записи, ассоциированные
с данным узлом. Если в этом узле поиск оказывается неудачен, служба
DNS начинает просматривать записи других узлов.

Собственно говоря, перечисленные записи
сервисов нам вручную делать не придется, при установке
первого контроллера домена создадутся автоматически.
Однако понимание этих записей важно! Теперь представим
очень маловероятную ситуацию, но все же: некоторые записи
неправильно изменены вручную, или же случайно стерты
вообще. Это не повод паниковать

За формирование записей
отвечает служба NetLogon. В командной строке даем всего
лишь две команды:

net stop netLogon

net start NetLogon

Выполнив перезапуск службы, наши записи
будут автоматически созданы! Разумеется, что если в домене
были записи клиентских машин (А-записи) к примеру, то
их придется восстанавливать отдельно. Но достаточно воспользоваться
службой автоматической раздачи адресов DHCP, как эта
проблема тоже будет легко решена.

Структура OU в Active Directory

В небольших инфраструктурах AD (20-50 пользователей) необязательно создавать новые OU, можно все складывать в дефолтные контейнеры в корне (Users и Computer). В большой инфраструктуре желательно разделить все объекты на разные контейнеры. В основном используется иерархический дизайн Organizational Unit в AD, по географическому или функциональному принципу.

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

Процесс присоединение к домену вне сетиOffline domain join process

Запустите Djoin.exe в командной строке с повышенными привилегиями, чтобы подготавливать метаданные учетной записи компьютера.Run Djoin.exe at an elevated command prompt to provision the computer account metadata. При выполнении команды подготовки метаданные учетной записи компьютера создаются в двоичном файле, указанном в качестве части команды.When you run the provisioning command, the computer account metadata is created in a binary file that you specify as part of the command.

Дополнительные сведения о функции Нетпровисионкомпутераккаунт, которая используется для предоставления учетной записи компьютера во время приподключения к автономному домену, см. в разделе функция нетпровисионкомпутераккаунт ( https://go.microsoft.com/fwlink/?LinkId=162426) .For more information about the NetProvisionComputerAccount function that is used to provision the computer account during an offline domain join, see NetProvisionComputerAccount Function (https://go.microsoft.com/fwlink/?LinkId=162426). Дополнительные сведения о функции Нетрекуестоффлинедомаинжоин, которая выполняется локально на конечном компьютере, см. в разделе функция нетрекуестоффлинедомаинжоин ( https://go.microsoft.com/fwlink/?LinkId=162427) .For more information about the NetRequestOfflineDomainJoin function that runs locally on the destination computer, see NetRequestOfflineDomainJoin Function (https://go.microsoft.com/fwlink/?LinkId=162427).

Разрешения перемещения объектов между подразделениями

«Поддержка»«Computers»особых задач для делегирования«этой папкой, существующими в ней объектами и созданием новых объектов в этой папке»«только следующим объектам в этой папке»«Компьютер объектов»«Удалить из этой папки выбранные объекты»Рис. 15. Страница создания особой задачи для делегирования«Разрешения»«Запись»«Computers»«Active Directory – пользователи и компьютеры»,«Клиенты»«Безопасность»«Добавить»«Элемент разрешения для Computers»«Выберите субъект»«Поддержка»«Применяется к»«Этот объект и все дочерние объекты»«Создание объектов: Компьютер»Элемент разрешения для «Клиенты»Рис. 16. Добавление разрешений для создания объектов компьютеров

Устаревшие функциональные уровни службы репликации файлов (FRS) и Windows Server 2003Deprecation of File Replication Service (FRS) and Windows Server 2003 functional levels

Хотя служба репликации файлов (FRS) и функциональные уровни Windows Server 2003 стали устаревшими в предыдущих версиях Windows Server, она повторяет, что операционная система Windows Server 2003 больше не поддерживается.Although File Replication Service (FRS) and the Windows Server 2003 functional levels were deprecated in previous versions of Windows Server, it bears repeating that the Windows Server 2003 operating system is no longer supported. В результате все контроллеры домена, работающие под управлением Windows Server 2003, необходимо удалить из домена.As a result, any domain controller that runs Windows Server 2003 should be removed from the domain. Режим работы домена и леса должен быть повышен по крайней мере до Windows Server 2008, чтобы не допустить добавления в среду контроллера домена, на котором выполняется более ранняя версия Windows Server.The domain and forest functional level should be raised to at least Windows Server 2008 to prevent a domain controller that runs an earlier version of Windows Server from being added to the environment.

В режимах работы домена Windows Server 2008 и более новых версий для репликации содержимого папки SYSVOL между контроллерами домена используется репликация службы распределенных файловых систем (DFS).At the Windows Server 2008 and higher domain functional levels, Distributed File Service (DFS) Replication is used to replicate SYSVOL folder contents between domain controllers. Если вы создаете домен в режиме работы домена Windows Server 2008 или более новых версий, для репликации SYSVOL автоматически используется репликация DFS.If you create a new domain at the Windows Server 2008 domain functional level or higher, DFS Replication is automatically used to replicate SYSVOL. Если вы создаете домен в более низком режиме работы, необходимо перейти от репликации FRS к DFS для SYSVOL.If you created the domain at a lower functional level, you will need to migrate from using FRS to DFS replication for SYSVOL. Чтобы выполнить миграцию, выполните приведенные ниже действия или ознакомьтесь с упрощенным набором действий в блоге о хранилище файлов группы хранения.For migration steps, you can either follow these steps or you can refer to the streamlined set of steps on the Storage Team File Cabinet blog.

Функциональные уровни домена и леса Windows Server 2003 по-прежнему поддерживаются, но организации должны повысить функциональный уровень до Windows Server 2008 (или более высокий, если возможно), чтобы обеспечить совместимость репликации SYSVOL и поддержку в будущем.The Windows Server 2003 domain and forest functional levels continue to be supported, but organizations should raise the functional level to Windows Server 2008 (or higher if possible) to ensure SYSVOL replication compatibility and support in the future. Кроме того, существует множество других преимуществ и функций, доступных на более высоких функциональных уровнях выше.In addition, there are many other benefits and features available at the higher functional levels higher. Дополнительную информацию можно найти в следующих ресурсах:See the following resources for more information:

Объект ConnectionConnection object

Объект Connection — это Active Directory объект, представляющий подключение репликации с исходного контроллера домена к целевому контроллеру домена.A connection object is an Active Directory object that represents a replication connection from a source domain controller to a destination domain controller. Контроллер домена является членом одного сайта и представлен на сайте объектом сервера в службах домен Active Directory Services (AD DS).A domain controller is a member of a single site and is represented in the site by a server object in Active Directory Domain Services (AD DS). Каждый объект сервера имеет дочерний объект параметров NTDS, представляющий реплицируемый контроллер домена на сайте.Each server object has a child NTDS Settings object that represents the replicating domain controller in the site.

Объект Connection является дочерним по отношению к объекту параметров NTDS на целевом сервере.The connection object is a child of the NTDS Settings object on the destination server. Чтобы репликация выполнялась между двумя контроллерами домена, объект сервера одного из них должен иметь объект Connection, представляющий входящую репликацию из другого.For replication to occur between two domain controllers, the server object of one must have a connection object that represents inbound replication from the other. Все подключения репликации для контроллера домена хранятся в объекте параметров NTDS в виде объектов соединения.All replication connections for a domain controller are stored as connection objects under the NTDS Settings object. Объект Connection определяет исходный сервер репликации, содержит расписание репликации и указывает транспорт репликации.The connection object identifies the replication source server, contains a replication schedule, and specifies a replication transport.

Средство проверки согласованности знаний (KCC) автоматически создает объекты подключения, но их также можно создать вручную.The Knowledge Consistency Checker (KCC) creates connection objects automatically, but they can also be created manually. Объекты подключения, созданные КСС, отображаются в оснастке «сайты и службы» Active Directory «как и» при нормальных условиях работы.Connection objects created by the KCC appear in the Active Directory Sites and Services snap-in as and are considered adequate under normal operating conditions. Объекты соединения, созданные администратором, создаются вручную.Connection objects created by an administrator are manually created connection objects. Объект подключения, созданный вручную, определяется по имени, назначенному администратором при его создании.A manually created connection object is identified by the name assigned by the administrator when it was created. При изменении объекта соединения он преобразуется в административно измененный объект подключения, а объект отображается в виде идентификатора GUID.When you modify a connection object, you convert it into an administratively modified connection object and the object appears in the form of a GUID. KCC не вносит изменения в ручные или измененные объекты подключения.The KCC does not make changes to manual or modified connection objects.