Когда в компании пять компьютеров, пароли можно хранить в голове. Когда их пять тысяч в десяти городах, голова уже не справляется. Именно из этой задачи вырос Active Directory - каталог, в котором корпорация описывает каждого сотрудника, каждый компьютер, каждый принтер и каждую группу доступа, а затем заставляет всю инфраструктуру спрашивать именно его, можно ли пройти. Эта статья написана с позиции доменного администратора, который много лет разворачивает леса, чинит репликацию и объясняет аудиторам, почему пароль никогда не гуляет по сети в открытом виде.
Домен, лес и деревья как скелет каталога
Active Directory строится иерархично. На вершине стоит лес - граница безопасности, внутри неё общая схема, общий глобальный каталог и общие администраторы. В лесу живут деревья доменов, связанные родительско-дочерними именами и транзитивными довериями Kerberos. На практике у большинства компаний лес один и домен один, потому что плодить домены ради красоты дорого и больно. Внутри домена объекты раскладываются по организационным единицам OU - это папки каталога, на которые удобно вешать групповые политики и делегировать права отделу техподдержки конкретного филиала. Рядом существуют сайты: они описывают физическую топологию сети через IP-подсети и подсказывают клиентам, к какому контроллеру домена обращаться, чтобы не гонять аутентификацию через медленный канал за полтысячи километров. Глобальный каталог заслуживает отдельного упоминания: это урезанная копия всех объектов леса, отвечающая на быстром порту 3268. Именно туда клиенты и Exchange бегут за поиском аккаунтов в другом домене. Без global catalog вход в мультидоменном лесу превращается в лотерею, поэтому старшее поколение администраторов держит его на каждом контроллере на всякий случай - реплик всё равно немного, а выгода очевидна.
Kerberos и билеты вместо паролей
Главное достижение доменной модели заключается в том, что пароль пользователя никогда не бегает по проводам. Действующий протокол Kerberos устроен как касса вокзала. На входе клиент просит у Key Distribution Center билет TGT, шифруя запрос данными, производными от своего пароля, и добавляет штамп времени. Контроллер домена играет роль KDC: он расшифровывает запрос, сверяет время и выписывает TGT, подписанный секретом службы krbtgt. Дальше, когда сотрудник открывает файловый сервер, он предъявляет TGT и получает второй билет TGS, уже для конкретной службы, а служба проверяет билет локально, не спрашивая контроллер каждый раз. Весь трюк держится на штампах времени: если часы клиента и контроллера расходятся больше чем на пять минут, билет объявляют просроченным или пришедшим из будущего, и вход отклоняется. Поэтому требование о синхронизации ±5 минут не придирка, а механизм защиты от повторной отправки перехваченного билета. Время в домене раздаёт иерархия NTP, обычно на базе w32time: рабочие станции берут время у контроллера своего сайта, контроллеры - у PDC-эмулятора, а тот синхронизируется с внешним источником. Утверждение, что Kerberos выдаёт непроверяемые пропуска, неверно: каждый билет зашифрован ключом, который знает только контроллер или служба, и подделать его без компрометации этих секретов невозможно. Отдельная тема - NT хэши. Если атакующий украл хэш пароля, он может имперсонировать пользователя через pass-the-hash, поэтому современный администратор сокращает число мест, где такие хэши кэшируются.
NTLM как наследие и причины отключения
До Kerberos в Windows жил NTLM, и он никуда не исчез: любое подключение по IP-адресу вместо имени, любой старый скрипт, любая работа вне домена свалится в NTLM-аутентификацию с её challenge-response механикой. Проблемы у протокола накопились серьёзные. Хэш NTLM не солён, словарные переборы занимают секунды, relay-атаки позволяют перекинуть чужой отклик на соседний сервер, а канал без подписи SMB остаётся открытым для вмешательства. Аудиторы сегодня требуют протокол NTLMv1 убрать полностью и сузить NTLMv2 через политики Network Security Restrict NTLM, оставив исключения только там, где Kerberos технически недоступен. Последовательная блокировка проходит поэтапно: сначала включают аудит событий 8001-8004, месяц смотрят, кто ещё ходит старым способом, исправляют записи SPN и ссылки по IP, и только потом врубают запрет. Те, кто пропускает этап аудита, получают море звонков от пользователей старого приложения отчётности.
Контроллеры домена, роли FSMO и правила репликации
Контроллер домена - это Windows Server с копией базы NTDS.dit, и писать в эту базу можно с любого контроллера: модель называется мультимастер. Изменения расходятся между партнёрами по топологии, которую строит служба KCC, и конфликт решается по версии атрибута и штампу времени. Но некоторые операции требуют единственной точки истины, и для них существуют пять ролей FSMO. Schema master меняет схему леса при обновлении Exchange или доменных служб. Domain naming master отвечает за создание новых доменов. RID master выдаёт каждому контроллеру пулы относительных идентификаторов, чтобы SID новых объектов не пересекались. Infrastructure master обновляет ссылки на объекты других доменов. PDC emulator самый хлопотный: он первым узнаёт о смене пароля, обслуживает старые клиенты, отвечает за время и ловит блокировки аккаунтов. Когда контроллер с ролью падает, остальные работают, но нюансы заметны: пароль, сменённый удалённым филиалом, локально не сработает, пока филиал не достучится до PDC. Репликация сама по себе не идеал мгновенности - между сайтами она по графику ходит раз в интервал от пятнадцати минут, и администратор научился читать repadmin /showrepl с закрытыми глазами. Удалённый объект не пропадает бесследно: он превращается в tombstone, загробную метку, которая реплицируется по всем партнёрам и живёт по умолчанию сто восемьдесят дней. За этот срок контроллер, вернувшийся из долгого отключения, должен успеть получить удаления; иначе его база становится постаревшей дольше tombstone lifetime, и единственный честный выход - понижение роли и чистое восстановление, а не героические попытки вдохнуть в него жизнь.
Группы безопасности и OU служат разным целям
Начинающие администраторы вечно путают группы и OU. Группа безопасности определяет, к кому относится участник, и она уезжает с билетом Kerberos в виде списка SID; этот список сравнивается с ACL на папке, принтере, приложении. OU - это место, где объект живёт в каталоге, и оно определяет, какие групповые политики GPO к нему применятся и кому делегировано право сбрасывать там пароли. Попытка выдать доступ через OU органично обламывается: нельзя повесить OU на ACL файлового сервера. Попытка применить политику через группу тоже не выходит без обходных путей вроде фильтрации WMI. Устоявшаяся практика выглядит так: структура OU зеркалит географию или отделы для удобства политик, доступ к ресурсам строится по модели AGDLP - пользователи в глобальных группах подразделений, те в доменных локальных группах ресурса, а уж локальная группа получает права. Убрать сотрудника из одной группы гораздо проще, чем вычистить его SID из двухсот ACL.
Присоединение компьютера и машинный пароль
Чтобы рабочая станция считалась доверенной, её присоединяют к домену. В каталоге создаётся компьютерный аккаунт, на клиенте забивается пароль машины, и дальше станция аутентифицируется этой парой так же, как человек своим логином. Машинный пароль по умолчанию сменяется каждые тридцать дней самой станцией, без участия пользователя, и обновление реплицируется. Эта ротация похожа на смену ключей от служебной комнаты - скомпрометированный старый пароль перестаёт открывать дверь. Проблема приходит с клонированными образами и долго выключенными ноутбуками: если у клиента и каталога разъезжаются версии пароля, появляется знакомая ошибка доверительных отношений, и рабочий рецепт - вывести машину из домена и присоединить заново или выполнить Reset-ComputerMachinePassword. Дельный совет звучит просто: образы для развёртывания готовят через sysprep и не присоединяют к домену заранее.
Жизненный цикл сотрудника от приёма до увольнения
Каталог хорош настолько, насколько дисциплинированно в нём ведут учётные записи. Цикл обычно выглядит так: кадровая система создаёт событие найма, скрипт или сервис синхронизации заводит аккаунт с ролью и группами по шаблону должности, к почте подключают через соответствующие группы. Перевод между отделами - самое опасное место, потому что новые права добавляются, а старые забываются снимать; грамотный процесс требует пересмотра членств, а не только правки атрибута department. Увольнение начинается с немедленного disable аккаунта, сброса сессий и смены пароля, затем аккаунт живёт отключенным сколько требует политика хранения почты, и лишь потом удаляется. Удалённый аккаунт превращается в tombstone, и восстановить его с нулевой истории куда сложнее, чем вернуть отключенный.
Типовые боли эксплуатации и инструменты выживания
Реальная эксплуатация приносит повторяющиеся неприятности. Первая - застопорившаяся репликация: контроллеры ошибаются друг про друга, repadmin краснеет, а причина банальна - ошибка DNS, закрытый порт 445 или разрыв сайта. Вторая - DNS вообще. Active Directory не работает без правильного DNS, клиент ищет контроллер через SRV-записи вида _ldap._tcp.dc._msdcs.example.com, и если сетевой админ указал станциям внешний резолвер, вход превращается в квест. Диагностика всегда начинается с nslookup по этим записям и dcdiag /test:dns. Третья боль - локальные администраторы. Когда на всех машинах одинаковый локальный пароль админа, компрометация одной станции открывает все; службу LAPS поставили именно для этого, она генерирует уникальный пароль на каждой машине, хранит его в атрибуте аккаунта компьютера и ротирует автоматически. Четвёртая - забытый пароль пользователя, решаемый делегированной формой сброса на службе поддержки с журналированием, но никак не общим списком на стикере. Пятая - внезапный переезд в облако. Онлайн-идентичность выросла в Azure AD, переименованную позже в Microsoft Entra ID, которая живёт рядом, но не вместо: облачный каталог умеет OAuth, SAML и условный доступ, а классический домен никуда не делся, потому что серверы и старые приложения продолжают требовать Kerberos. Связкой миров служит Entra Connect для синхронизации пользователей и hybrid join, при котором устройство присоединено одновременно к домену и к облачному каталогу, и пользователь получает единый вход в обе среды. Зрелая корпорация не выбирает одно из двух - она строит мост и постепенно сокращает то, что привязано к локальному прошлому.
Резервное копирование и восстановление каталога
Опыт научил администратора относиться к резервным копиям контроллеров домена как к последнему рубежу. Копия делается через System State, в неё входит база NTDS.dit, реестр и SYSVOL, а восстановление бывает двух видов. Неполномочное возвращает контроллер в строй, после чего он честно догоняет актуальные изменения от партнёров. Полномочное применяют, когда удалённые объекты нужно вернуть из небытия: объект помечают повышением версии, и репликация распространяет его поверх свежих удалений, если, конечно, не истёк срок жизни tombstone. Из-за этого срока восстанавливать контроллер из копии старше ста восьмидесяти дней бессмысленно и вредно: вернутся призрачные объекты, и начнётся рассинхронизация базы. Отдельная головная боль - SYSVOL с групповыми политиками: он реплицируется службой DFSR, и после полномочного восстановления его иногда приходится чинить вручную через BurFlags. В зрелой среде минимум два контроллера на сайт, копии лежат вне доменной сети, доступ к ним строже, чем к самим контроллерам, потому что украденная база NTDS.dit отдаёт атакующему хэши всех паролей домена одним махом. Проверять копии тоже надо на деле: раз в квартал поднимают изолированный лес и убеждаются, что схема, политики и аккаунты живы, иначе уверенность в спасении остаётся только на бумаге.