Active Directory

Доверие (trust) — это соглашение между двумя границами аутентификации: доменами, лесами или Kerberos-областями. Оно отвечает на вопрос: может ли контроллер одной стороны принять доказательство личности, выданное другой стороной? Само по себе доверие не выдаёт разрешений на файловую папку, сервер или приложение.

Направление доверия: PARTNER -- trusted by --> CORP
Поток аутентификации: user@PARTNER -------------> ресурс в CORP
Проверка разрешений: ACL ресурса в CORP ----------> разрешить / запретить

Trust = «чьи удостоверения я готов проверить»
ACL = «что это удостоверение может сделать»

В проекте сначала рисуют границы администрирования, безопасности, DNS и жизненного цикла компаний. Только затем решают, нужен ли trust. Он расширяет поверхность атаки и усложняет расследование, поэтому не является способом «быстро объединить две сети».

Одностороннее доверие направлено от доверяющей стороны к доверенной. В двустороннем доверии создаются два односторонних направления. Транзитивность определяет, можно ли «передать» доверие дальше по цепочке.

A доверяет B: A <----- trust ----- B
Доступ пользователей: users B -------------> ресурсы A

Двустороннее: A <===== trust =====> B
  users A -> B; users B -> A

Транзитивная цепочка: A <--> B <--> C
  A может доверять C через B
Нетранзитивная: A <--> B C
  доступ A к C не появляется

Двусторонность удобна, но часто чрезмерна. Если после поглощения сотрудники приобретённой компании должны пользоваться только порталом покупателя, достаточно одностороннего доверия и строго выделенной группы доступа. Обратный поток не создают «на всякий случай».

Тип trust выбирают по границе, протоколу и требуемой области действия, а не по привычному названию.

Лес покупателя  Лес приобретённой компании
corp.example  acquired.example
 na.corp  users.acquired
 \  /
 +====== forest trust =========+
 транзитивный на уровне лесов

Legacy.local -- external trust --> apps.corp.example
Только один домен и один сценарий

Современный базовый выбор — один лес, один домен. Он даёт единый каталог, простую репликацию, один набор UPN, меньше исключений в GPO, PKI, приложениях. Дополнительный домен оправдан только отдельным DNS-именем, автономной политикой паролей/аккаунтов, юридической границей или наследуемым требованием и которое нельзя устранить.

Плохая причина: «в каждом городе свой домен»
moscow.corp spb.corp vlad.corp
 \ | /
 больше trusts, DNS, GPO и администрирования

Обычно лучше:
  corp.example (один домен)
 Sites: Москва | Санкт-Петербург | Владивосток

Лес — настоящая граница безопасности: у него собственные Schema Admins и Enterprise Admins. Несколько доменов одного леса не защищают от компрометации уровня леса.

SID — идентификатор безопасности, который попадает в Kerberos PAC. Атрибут SIDHistory помогает при миграции: пользователь сохраняет старый SID и временно получает доступ к ресурсам, где он записан в ACL. Но при доверии атакующий из другой стороны мог бы попытаться представить привилегированный SID как историю.

Атака без фильтрации:
Токен user@UNTRUSTED:
 SID: UNTRUSTED-1107
 SIDHistory: CORP-512 <-- «Domain Admins» доверяющего домена
  |
  v
 ресурс CORP ошибочно видит привилегированную группу

SID Filtering:
 принимать только SID, допустимые для доверенной стороны
 чужие/поддельные SIDHistory отбрасываются

Проверяйте состояние trust и атрибуты мигрированных объектов. После завершения миграции очищайте SIDHistory по утверждённой процедуре, а не массовой неподтверждённой командой.

Get-ADTrust -Filter * | Select-Object Name, Direction, TrustType, ForestTransitive, SIDFilteringForestAware
Get-ADUser -LDAPFilter "(sIDHistory=*)" -Properties sIDHistory |
 Select-Object SamAccountName, sIDHistory

При слиянии компаний trust — переходный механизм, а не обязательная конечная архитектура. Сначала инвентаризируют идентичности, приложения, DNS, PKI, привилегии, владельцев данных. Затем определяют, какой лес станет целевым а какие ресурсы должны работать во время перехода.

Фаза 1: два независимых леса
BUYER.FOREST TARGET.FOREST
 |  |
 +--- односторонний trust --+
 только к порталу buyer

Фаза 2: миграция аккаунтов и ACL
TARGET users --> BUYER users (SIDHistory под контролем)

Фаза 3: отзыв trust
TARGET forest: архив / вывод из эксплуатации

Устанавливайте дату пересмотра trust, метрики использования и владельца. Если через шесть месяцев ни одно приложение не использует межлесную аутентификацию, trust следует удалить после верификации.

Работоспособность trust зависит не только от объекта в AD: требуются корректные conditional forwarders или зоны DNS, синхронизация времени, доступность DC, Kerberos, сетевые правила. Диагностику ведут по слоям — имя, сеть, билет, токен и ACL.

# Обзор отношений и проверка конкретного trust
Get-ADTrust -Identity "partner.example" -Properties *
netdom trust corp.example /domain:partner.example /verify

# DNS и билет пользователя
Resolve-DnsName dc01.partner.example
klist
whoami /groups

Порядок разбора «доступ запрещён»:
1. Разрешается ли имя DC доверенного домена?
2. Синхронизировано ли время (Kerberos допускает малое расхождение)?
3. Есть ли билет и нужные SID в токене?
4. Разрешён ли вход на этот компьютер/select authentication?
5. Даёт ли ACL ресурса нужное право?

Архитектура доверий начинается с картирования границ, а не с мастера New Trust. Нарисуйте все леса и домены, их владельцев, DNS-пространства, привилегированные группы, приложения и поток обращений. Затем для каждого потока сформулируйте минимальное утверждение: «пользователь из X может аутентифицироваться на Y только для приложения Z». Из него следуют направление trust, необходимость select authentication, группа назначения и ACL ресурса. Фраза «два леса должны видеть друг друга» не является требованием — она не говорит ни о направлении, ни о допустимом масштабе.

Карта решения для партнёра

users@partner.example ---- Kerberos ----> portal.corp.example
   |
   +--> группа CORP\Portal-Partner-Users
   +--> ACL только на Portal
   +--> trust: CORP trusts PARTNER

Не требуется:
users@corp.example --------------X-----> ресурсы PARTNER
партнёрские SID -----------------X-----> административные ACL CORP

Нужно различать доверенную сторону и доверяющую сторону при чтении документации. Если домен A доверяет домену B, A принимает проверку личности B; следовательно, пользователи B потенциально получают доступ к ресурсам A. На схеме стрелка аутентификации поэтому полезнее стрелки «доверия»: она меньше провоцирует ошибку, при которой администратор создаёт trust в обратную сторону и затем расширяет его до двустороннего, чтобы «заработало».

Односторонняя модель, читаемая по доступу:

 Partner user ---- билет/логон ----> CORP resource
   ^
   |
  CORP trusts PARTNER

Двусторонняя модель добавляет второй независимый риск:
 CORP user ------------------------> PARTNER resource

Forest trust — сильное архитектурное утверждение: он говорит, что два леса согласны обрабатывать широкую межлесную идентичность. Выбирайте его, когда организации сохранятся надолго, существует много доменов и многим приложениям нужна предсказуемая межлесная модель. Если один старый домен предоставляет один ресурс, external trust точнее выражает границу. Shortcut trust имеет иной смысл: он сокращает маршрут аутентификации внутри уже существующего леса и не создаёт новую независимую границу безопасности.

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

Контролируемая миграция SIDHistory

старый ACL: FILE01\Share -> OLD\Finance-Read
  |
миграция пользователя + временный SIDHistory
  |
перевод ACL: FILE01\Share -> NEW\Finance-Read
  |
тест нового токена -> удаление SIDHistory -> повторный тест

Нельзя: оставить историю «пока никто не жалуется».

DNS для trust — часть протокола, а не вспомогательная настройка. Conditional forwarder с конкретным владельцем обычно понятнее, чем неограниченное разрешение внешних зон. Проверяйте прямое и обратное разрешение нужных DC, SRV-записи, доступность портов и время. В отчёте об инциденте отделяйте «trust не существует» от «trust существует, но клиент выбрал недоступный DC»: для пользователя оба выглядят как отказ входа, но исправления противоположны.

# Диагностируйте с обеих сторон и фиксируйте результат.
Get-ADTrust -Filter * -Properties Direction,TrustType,SelectiveAuthentication
Resolve-DnsName -Type SRV "_kerberos._tcp.dc._msdcs.partner.example"
netdom trust corp.example /domain:partner.example /verify
klist purge
klist get krbtgt

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

Жизненный цикл настройки AD

Потребность -> модель угроз/ограничений -> pilot
 |   |
 v   v
владелец <- документация <- измерение <- внедрение
 |   |
 +-------- пересмотр / удаление --------+

«Создано без ошибки» не является критерием качества.
Критерий: известны ожидаемый эффект, границы и способ доказать эффект.

Разделяйте плоскости управления. Идентичность отвечает за то, кто предъявляет учётную запись; аутентификация — как система проверяет это предъявление; авторизация — какие операции разрешены; сеть — куда может дойти трафик; журнал событий — как восстановить картину. Попытка заменить одну плоскость другой создаёт ложное чувство защиты. Например, группа AD не заменяет сегментацию сети, а firewall не заменяет разрешение на объект.

Для production-процесса полезна трёхступенчатая модель: лаборатория подтверждает синтаксис, pilot подтверждает совместимость с реальными образами, приложениями, а поэтапное развёртывание ограничивает радиус поражения. Нельзя считать результатом лаборатории доказательство того, что политика, репликация или доверие безопасны для всей организации: в лаборатории обычно нет её задержек, наследованных ACL, исключений DNS и старых клиентов.

# Полезный минимум перед и после изменения:
Get-Date
whoami /all
Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address

# Сохраняйте вывод с номером заявки, а не только в истории консоли.
New-Item -ItemType Directory -Force -Path C:\Temp\AD-Change |
 Out-Null

Качественная документация отделяет факт от предположения. Факт: команда показала конкретный DC, версию или ошибку в указанное время. Предположение: эта ошибка объясняет наблюдаемое поведение. Для предположения нужен следующий тест, который может как подтвердить, так, опровергнуть его. Такой подход особенно важен в AD: один пользователь может попасть на другой контроллер домена, другой site или иметь старый токен и поэтому единичный удачный тест не описывает состояние всей среды.

Минимальная запись в журнале изменений

Время: 2026-07-14 15:00 UTC+3
Объект: имя, GUID и область действия
Гипотеза: какую причину проверяем
До: сохранённый отчёт / экспорт
Действие: одна обратимая операция
После: тот же тест, другой пользователь/узел при необходимости
Откат: условие, команда и ответственный

Такую запись можно передать дежурной смене без устных пояснений.

Права на изменение AD должны быть минимальными и раздельными. Человек, который утверждает нужду в политике или trust, не обязательно должен быть тем, кто имеет право менять все GPO, связи sites или объекты безопасности. Делегируйте операции на конкретную OU, группу или набор объектов, используйте отдельную привилегированную учётную запись и проверяйте членство в группах администрирования так же регулярно, как и рабочие ACL. Широкое членство в Domain Admins ради одной административной операции почти всегда является признаком недоработанного процесса.

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