Что такое Active Directory: домен, учётные записи, группы и GPO

Зачем бизнесу Active Directory

Active Directory Domain Services, или AD DS, — служба каталога Microsoft для управления доменными учётными записями, компьютерами, группами и связанными параметрами. Она помогает выстроить общий порядок доступа вместо отдельных паролей и ручных настроек на каждом рабочем месте.

• Приём сотрудника: создать личную учётную запись и выдать согласованные роли.
• Доступ к ресурсам: управлять правами через группы, а не случайные исключения на каждой папке.
• Настройки компьютеров: применять проверенные политики к нужным объектам.
• Эксплуатация: расследовать изменения, контролировать состояние каталога и восстанавливать его по плану.

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

Лес, домен, OU и контроллер: не путать уровни

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

Контроллер домена, DC, — сервер, предоставляющий службы AD DS. Один домен может иметь несколько DC, а один отдел не обязан иметь собственный домен. Не проектируйте лес и домены как буквальную копию оргструктуры без требований к границам управления и безопасности.

Логическую схему отделяют от физической: Sites и подсети описывают сетевую топологию, а не заменяют домены или OU. В учебных примерах используется имя ad.example.com; реальное пространство имён выбирают осознанно и согласуют с DNS.

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

Доменный клиент ищет контроллер через DNS и специальные записи служб. Если имя файлового сервера разрешается, это ещё не доказывает корректное обнаружение DC, Kerberos и других доменных зависимостей.

Клиентам задают DNS-серверы, которые умеют правильно обслуживать доменную зону и внешние запросы по согласованной схеме. Случайный публичный DNS как «запасной» доменному клиенту может давать непредсказуемые отказы: внешний сервер не знает внутренних SRV-записей. Резервируют доменно-осведомлённый DNS, а внешнее разрешение организуют отдельно.

Resolve-DnsName -Name _ldap._tcp.dc._msdcs.ad.example.com -Type SRV
nltest /dsgetdc:ad.example.com
w32tm /query /status

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

Часы важны для аутентификации и сопоставления журналов. Настройку времени планируют по доменной иерархии и внешнему источнику соответствующей роли; не направляют каждый DC и клиент на случайные независимые источники.

LDAP, Kerberos и SMB — технологии, а не синонимы AD

LDAP используется для доступа к данным каталога. Kerberos участвует в доменной аутентификации и выдаче билетов для сервисов. SMB обеспечивает доступ к файловым ресурсам и другим функциям Windows. Службы AD DS объединяют несколько механизмов и зависимостей.

Поэтому «LDAP-запрос прошёл» не означает «пользователь вошёл в домен», а успешный вход не подтверждает права на папку. Для SSO приложение должно поддерживать нужную интеграцию, а для Kerberos важны имена сервисов, SPN, время и реальная конфигурация.

Старые приложения могут зависеть от NTLM или других способов проверки. Их инвентаризируют и модернизируют по плану, а не отключают механизмы на всём домене без проверки зависимостей. Для защищённого LDAP и современных требований безопасности также учитывают сертификаты, подпись и настройки клиентов.

Пользователь, компьютер и сервисная учётная запись

• Пользователь: личная идентичность сотрудника; общая учётная запись затрудняет отзыв и расследование.
• Компьютер: отдельный объект и доверенные отношения с доменом. Имя ПК не заменяет его состояние присоединения.
• Сервисная учётная запись: идентичность приложения с владельцем, назначением и ограниченными правами.
• Административная: отдельная привилегированная роль; не нужна для повседневной почты и браузера.

Одно и то же видимое имя на локальном ПК и в домене не делает учётные записи одинаковыми. У них могут быть разные SID и права. Удаление и создание «такого же пользователя» не является простым восстановлением прежней идентичности.

whoami /user
whoami /groups
Get-CimInstance Win32_ComputerSystem |
    Select-Object Name, Domain, PartOfDomain

В командной строке или PowerShell первые две команды показывают текущую идентичность и группы её контекста. PowerShell-запрос читает принадлежность компьютера к домену. Эти команды не создают учётные записи и не присоединяют ПК. В текущем токене группы могут отличаться от недавно изменённого состояния каталога.

Права через группы: понятный пример AGDLP

Сотрудника бухгалтерии включают в GG_Finance. Эту глобальную группу включают в DL_Finance_Read, а уже группе ресурса назначают чтение папки Finance. При переводе сотрудника проще менять членство в бизнес-роли, чем искать индивидуальные записи ACL на десятках ресурсов.

AGDLP — полезный шаблон для конкретного однодоменного сценария, а не универсальная полная модель всех лесов. В многодоменной схеме области групп и универсальные группы требуют отдельного проектирования. Security groups используются для прав; distribution groups не стоит автоматически считать группами безопасности.

У Windows есть явные запреты, наследование и сочетание разрешений общего ресурса и файловой системы. Эффективный доступ проверяют для реального пользователя и операции. Наличие одной разрешающей группы не даёт гарантии итогового права при любой ACL.

Группа есть — доступ действительно появился?

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

Для приёмки нужны два случая: допущенный сотрудник выполняет согласованную операцию, а пользователь без роли не получает её. Успех входа Windows не является проверкой всех файловых, SQL-, VPN- и облачных разрешений.

OU и делегирование: структура для управления

OU удобно разделять по задачам управления и политикам: рабочие станции, серверы, пользователи, сервисные учётные записи. Это не обязательно буквальная копия каждого отдела и кабинета. У структуры должны быть владельцы и объяснимые причины.

Например, службе поддержки можно делегировать определённые операции с пользовательскими объектами в ограниченной OU, не выдавая Domain Admins. Делегирование проверяют на реальной задаче и на том, что сотрудник не может сделать за её пределами.

OU и группа не взаимозаменяемы. OU определяет размещение объекта и часть административной области, группа — членство и возможную роль доступа. Один пользователь размещён в одной OU в этой иерархии, но может входить в несколько групп.

Стандартные контейнеры вроде Computers не следует путать с OU: возможность прямого связывания GPO и организация управления различаются. Не переносите контроллеры домена и не меняйте их политики ради одинакового вида дерева с рабочими станциями.

GPO: политика применяется к объектам, а не по названию группы

Group Policy позволяет централизованно задавать параметры пользователей и компьютеров. GPO содержит настройки и область применения; связи с Site, доменом и OU, фильтры, наследование и порядок влияют на результирующее состояние.

• Разделять компьютерные и пользовательские параметры.
• Проверять link, область, security filtering и при необходимости WMI-фильтры.
• Сначала испытывать изменение на пилотной группе устройств.
• Документировать цель, владельца, ожидаемый результат и возврат.
• Проверять результат на клиенте, а не только наличие GPO в консоли.

gpresult /r
gpresult /h "$env:TEMP\ad-gpo-report.html"

Первый вызов показывает сводку результирующих политик. Второй — вариант для PowerShell, который создаёт HTML-отчёт в TEMP; для части компьютерных данных нужны соответствующие права. Файл может содержать внутренние сведения, поэтому его не публикуют без обработки.

Обновление политик не означает, что любой параметр вступит в силу без нового входа или перезагрузки. Массовая настройка firewall, прав входа или RDP через ошибочную GPO способна нарушить доступ сразу многим устройствам. Сохранённый предыдущий вариант и пилот важнее скорости развёртывания.

Два контроллера и репликация: не главный и запасной

Для доступности обычно планируют несколько DC с учётом масштаба, площадок и отказов. Изменения каталога реплицируются, но не становятся мгновенно видимыми в любой точке при любых условиях. Отдельно контролируют DNS и SYSVOL, от которого зависит часть Group Policy.

Не описывайте все DC как одну постоянную пару «главный/резервный». В AD DS есть репликация и отдельные специальные роли FSMO. Размещение и восстановление ролей планируют; например, PDC Emulator имеет особое значение для ряда доменных функций и иерархии времени.

Доступность второго DC не доказывает, что к нему могут обратиться все клиенты. Нужны корректные DNS, сетевой путь, реклама служб, сайт клиента и работа зависимостей. Отдельно испытывают отказ узла и DNS, а не только питание одной VM.

Sites и подсети для офиса и филиалов

Site отражает физическую сетевую топологию для доменных служб. Подсети сопоставляют сайтам, чтобы обнаружение подходящего DC и репликация учитывали расположение и связи. Номер VLAN сам по себе не назначает AD Site.

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

Локальный контроллер в филиале не является обязательным ответом на любую задержку. Сначала оценивают канал, безопасность помещения, обслуживание, RODC-сценарий, доступность DNS и требования при обрыве WAN. Роли и размещение выбирают по риску и эксплуатационным возможностям.

Приём, перевод и увольнение сотрудника

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

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

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

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

Административные права и безопасность каталога

• Разделить обычные и привилегированные действия; не работать постоянно под Domain Admins.
• Делегировать конкретные задачи, а не выдавать максимально широкую группу.
• Контролировать сервисные учётные записи, их владельцев и допустимые входы; рассмотреть gMSA там, где это поддерживается.
• Защищать DC, управление, резервные копии и административные рабочие места.
• Собирать события изменения групп, политик и привилегий; проверять восстановимость.

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

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

Почему второй DC и снимок VM не заменяют backup

Сначала определяют сценарий: удалён один объект, повреждён DC, потеряна площадка или скомпрометирован лес. От этого зависит процедура восстановления и необходимость изоляции. Универсальная команда «вернуть снимок» не покрывает эти случаи.

Для DC нужны поддерживаемые средства резервирования, подходящий состав копии, защита доступа и план с необходимыми секретами восстановления, включая DSRM. Поддержка безопасной виртуализации и VM-Generation ID не превращает любой snapshot в полноценный backup.

Проверяют восстановление в изолированном контуре: AD, DNS, SYSVOL, роли и зависимые приложения. После компрометации важно не только поднять службы, но и восстановить доверенное состояние. Microsoft публикует отдельный план forest recovery; его адаптируют и испытывают под свою инфраструктуру.

AD DS и Microsoft Entra ID: похожие задачи, разные модели

Microsoft Entra ID, ранее Azure AD, — облачная служба идентификации. Её не стоит описывать как обычный локальный контроллер AD DS, перенесённый на сайт Microsoft. Способы присоединения устройств, управления и интеграции приложений различаются.

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

Если компании нужны преимущественно SaaS и современные устройства, сравнивают облачную модель с локальным доменом по приложениям и эксплуатации. Если есть зависимости от Kerberos, GPO или старых серверных приложений, проверяют их явно. Слово «облако» не устраняет DNS, права, backup и требования к защищённому управлению.

Диагностика AD без изменения домена

Get-ADDomain -Current LocalComputer
Get-ADDomainController -Filter * |
    Select-Object HostName, Site, IPv4Address, IsGlobalCatalog
repadmin /replsummary
repadmin /showrepl

AD-командлетам нужен установленный модуль ActiveDirectory, соответствующий контекст и права чтения. Первый показывает домен компьютера, второй — контроллеры и их параметры. repadmin читает сводку и подробности репликации; наличие инструмента и доступ проверяют на управляемом административном узле.

Результаты не следует заменять одним «ping DC прошёл». Причина жалобы может находиться в DNS, времени, обнаружении DC, репликации, SYSVOL, группах, GPO или в самом приложении.

• Не входит пользователь — определить локальный или доменный контекст, ошибку, состояние учётной записи и доступность нужных служб.
• Не открывается папка — проверить текущий токен, группы, share/NTFS-права и путь к ресурсу.
• Не применяется GPO — проверить объект, link, фильтры, обработку и результат на клиенте.
• В одном филиале иначе — проверить Site/Subnet, DNS, выбранный DC и репликацию.
• После изменения результат плавает — сопоставить время, DC, токены и активные сессии.

Команды приведены как диагностические примеры для современных Windows/Windows Server и AD DS; к рабочему домену при подготовке мы не подключались. Имена, отчёты и журналы не публикуют с внутренними данными.

Что принять после внедрения и как проверить модель

1. Утвердить структуру, DNS, DC/Sites, владельцев и границы делегирования.
2. Проверить вход клиента, выдачу доступа по группе и отказ постороннему пользователю.
3. Проверить пилотную GPO и правильное разделение пользовательских и компьютерных параметров.
4. Испытать отзыв новых и действующих подключений по согласованной процедуре.
5. Проверить отказ DC/DNS и восстановление необходимых зависимостей.
6. Отдельно испытать восстановление, защиту копий, мониторинг и порядок изменений.

# Офлайн-модель из ZIP, Windows
py -3 ad-group-model.py
# Linux: соответствующая команда вместо Windows-варианта
python3 ad-group-model.py

Модель выполняет 10 проверок цепочки групп и планируемого нового доступа. Она не читает AD, не выполняет вход, не рассчитывает полную Windows ACL и не моделирует немедленный отзыв токенов. PASS_OFFLINE_GROUP_MODEL — проверка учебных файлов, а не работающего домена.

Первичные источники: AD DS, группы безопасности, Group Policy, forest recovery, AD и Entra ID. Сверены 14 ноября 2026 года; конкретные функции и процедуры зависят от версии и архитектуры.

Скачать проект структуры и карточку приёмки

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

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

Вопросы и ответы