Руководство администратора

Содержание

1. Начало работы

Откройте веб‑интерфейс (Admin Center) в браузере и войдите под учётной записью панели. По умолчанию: admin / Admin123!. Это учётная запись панели администрирования, она отличается от доменной учётки Administrator.

Первый вход и смена пароля

Пока заводской пароль не сменён, на странице входа показывается информационный блок с учётными данными по умолчанию. При первом входе под admin панель сразу требует задать новый пароль (не короче 8 символов) — работать с заводским паролем нельзя. После смены информационный блок на странице входа больше не показывается.

Восстановление доступа к панели

Ссылка «Забыли пароль?» на странице входа открывает два способа:

• «По почте» — для учётной записи панели генерируется одноразовая ссылка сброса пароля (действует 30 минут). Почтового сервера у HopeDC нет, поэтому ссылка записывается на сервере в файл password_reset_link.txt в каталоге данных (доступен только root/пользователю службы).
• «Аварийное» — когда нет ни почты, ни доступа к серверу, или сервер в закрытом контуре. Панель показывает код запроса (привязан к оборудованию, как запрос лицензии). Код передаётся вендору любым каналом; вендор выпускает подписанный токен восстановления с новым паролем admin. Токен вставляется на этой же вкладке: перед применением панель показывает, для какого сервера он выпущен, и предупреждает, если отпечаток не совпадает.

Аварийный токен проверяется вшитым ключом вендора, действует только для этого сервера, ограничен по сроку и применяется один раз. Пароль admin становится тем, что указан в токене; если учётную запись admin удалили, она создаётся заново с ролью «Администратор». Сразу после входа смените пароль.

Двухфакторная аутентификация (MFA/TOTP) (v174)

Второй фактор — одноразовый код из приложения-аутентификатора (TOTP, RFC 6238: Google Authenticator, FreeOTP, Яндекс.Ключ и т. п.). Применяется при входе в веб-панель и при LDAP simple bind. Вход в саму ОС по Kerberos/NTLM вторым фактором не затрагивается (протокол не предусматривает ввод кода в окне входа Windows); для входа в ОС вторым фактором служат смарт-карты/PKINIT (v167).

Раздел «Двухфакторная (MFA)» в меню. Самообслуживание (любой вошедший): «Включить второй фактор» → отсканировать QR (или ввести секрет вручную) → подтвердить кодом → сохранить одноразовые резервные коды (показываются один раз). Отключение — с подтверждением текущим кодом.

Политика и управление (администратор). Можно требовать второй фактор: для всех администраторов, для перечисленных учёток или для групп (по DN). Если MFA требуется, но у учётки ещё не настроена, после входа по паролю открывается только страница привязки второго фактора (без меню) — остальные разделы панели и их API недоступны (сервер отвечает 403, код mfa_enroll_required), пока пользователь не подтвердит первый код и не сохранит резервные коды. Заблокировать себя так нельзя: войти и привязать приложение можно всегда, а на странице есть кнопка «Выйти». Политика действует и на уже открытые сеансы — не позже чем через 15 секунд. Обязательную MFA пользователь сам не отключает: при утере телефона её сбрасывает администратор. (v183; раньше обязательность была только подсказкой.)

Для доменных учёток, не входящих в панель (им нужен только LDAP-bind с кодом), администратор назначает MFA: панель генерирует секрет, QR и резервные коды — их передают пользователю. При утере устройства администратор снимает MFA с учётки (кнопка «✕» у учётки или «Снять»), после чего вход снова идёт обычным образом — так пользователь не остаётся заблокированным.

Портал смены пароля для пользователей (v175)

Отдельная страница для пользователей домена: https://<адрес DC>:9443/password. Пользователь меняет свой пароль, зная текущий — когда срок действия истёк, когда администратор отметил «сменить при следующем входе» или просто по желанию. Входить в панель администратора не нужно, сама панель на этой странице не загружается.

• Требования к паролю показываются сразу после ввода имени (пользователь@домен): длина, сложность, разнообразие символов, история, словарь, сроки. Выполненные условия отмечаются по мере набора. Окончательную проверку делает сервер — по действующей для учётки политике, включая PSO.
• Второй фактор: если у учётки включена MFA, страница попросит код из приложения.
• Защита от перебора: неверный текущий пароль увеличивает счётчик блокировки учётки (как вход), а с одного адреса — не более 20 попыток смены за 5 минут.
• Журнал безопасности: событие 4723 (смена пароля пользователем) — успех и отказ с причиной, с адресом клиента.
• Для доменов, интегрированных с MS AD, страница подсказывает менять пароль в AD (Ctrl+Alt+Del → «Изменить пароль»).

Сетевой доступ. Страница доступна адресам из списка панели или из списка клиентов домена (раздел «Сетевой доступ»). Так пользователи из своих подсетей дойдут до неё, даже если панель администратора закрыта для них. Если список клиентов домена выключен (открыт всем), страница тоже открыта всем — как и вход по Kerberos/LDAP.

Ссылку можно дать пользователям напрямую; к ней можно добавить имя: /password?user=ivanov@corp.local. Кнопка «Сменить пароль пользователя домена» на странице входа панели тоже ведёт сюда.

Путеводитель: «Начало работы» и подсказки (v153)

В панель встроен путеводитель, который ведёт оператора с первого входа. У него две части.

1. Панель «Начало работы» — чек-лист первичной настройки сервера. Кнопка «Начало работы N/M» находится в шапке панели (и в шапке рабочей области домена), N/M — сколько обязательных пунктов выполнено. При первом входе полного администратора панель открывается сама. Каждый пункт объясняет, зачем он нужен и где настраивается; кнопка «Перейти» открывает нужный раздел.

Состояние пунктов определяется по реальным настройкам сервера при каждом открытии панели — отмечать вручную ничего не нужно. Если пункт сделан иначе, чем проверяет панель (например, время синхронизируется внешним NTP, а резервные копии делает система бэкапа предприятия), полный администратор может нажать «Отметить». Ручные отметки общие для сервера; снимаются кнопкой «Снять отметку». Чек-лист виден только полному администратору панели (роль с полным доступом).

2. Подсказки по страницам — пошаговые экскурсии. При первом открытии каждого раздела (и каждой вкладки рабочей области домена) панель подсвечивает ключевые элементы страницы и в карточке объясняет, что с ними делать. Управление: Далее / Назад (или стрелки ←/→), Пропустить или Esc — закрыть подсказку этой страницы, «Не показывать подсказки» — выключить подсказки для своей учётной записи. Кнопка «?» в шапке в любой момент повторяет подсказку текущей страницы. Повторить все подсказки заново можно в панели «Начало работы» (ссылка внизу) — для этого же предназначено действие tours_reset.

Подсказки показываются всем пользователям панели, но только по тем разделам, которые разрешены их ролью. Прогресс (какие подсказки пройдены, выключены ли они, открывался ли чек-лист) хранится на сервере отдельно для каждой учётной записи — в файле onboarding.json каталога данных (зашифрован, как остальные настройки). Поэтому на другом компьютере или в другом браузере подсказки повторно не показываются, а у нового оператора начинаются сначала.

Первые шаги после установки

Тот же порядок ведёт панель «Начало работы» (см. выше).

1. Задайте свой пароль панельного admin — панель потребует это при первом входе.
2. Смените пароль доменного Administrator — Домены → hope.local → Структура домена.
3. При необходимости настройте Сетевой доступ (белый список IP клиентов домена).
4. Для работы с существующим доменом Microsoft AD настройте Интеграцию.
5. Загрузите лицензию (раздел Лицензия), если требуется снять ограничения.
6. Сохраните копию мастер‑ключа шифрования: Резервное копирование → «Скачать мастер‑ключ (под паролем)» (см. раздел 7). Без него базу и бэкапы не восстановить.

2. Обзор DC (дашборд)

Стартовый раздел «Обзор DC» показывает сводное состояние контроллера домена: активные службы, число объектов каталога, состояние интеграции и репликации. Используйте его как точку быстрой проверки «всё ли в норме» перед началом работ. Право доступа: dashboard.view.

3. Интеграция с AD

Глобальный раздел интеграции описывает подключение HopeDC к существующему домену Microsoft Active Directory: параметры контроллера‑источника (PDC), учётную запись и режим синхронизации. После настройки HopeDC зеркалирует объекты домена AD в собственный каталог и может служить дополнительным узлом обслуживания клиентов.

4. Домены и рабочая область домена

Раздел Домены — центральный. Здесь перечислены все домены, которыми управляет HopeDC (локальные и интегрированные). Возможности списка:

• Открыть домен — вход в изолированную рабочую область (workspace) с вкладками управления.
• Группировка по лесам (v196). Домены сгруппированы по лесам: строка-заголовок «Лес <корневой домен> · N доменов», под ней корневой домен леса (метка «★ корневой домен леса»), затем его поддомены — с отступом под своим родителем — и отдельные деревья леса (метка «🌲 отдельное дерево леса»). Леса из нескольких доменов показаны первыми. Делегат видит только свои домены; если корневой домен леса вне его области, в заголовке так и указано.
• Столбец «Доверия» (v196) — есть ли у домена доверительные отношения: «нет» или «есть: N» и до трёх партнёров (остальные — «+N», список во всплывающей подсказке). Значок‑ёлка (серый) — доверие внутри леса, созданное автоматически; значок‑ссылка (фиолетовый) — внешнее доверие, доверие лесов или Kerberos‑область; число внешних выводится отдельно. Стрелка — направление: ⇄ двустороннее, → исходящее, ← входящее. Без права «Доверия: просмотр» колонка пустая (—). Управление доверием — во вкладке домена «Доверие (Trusts)».
• Столбец «Linux» — показывает, поддерживает ли домен обслуживание Linux‑клиентов (локальный домен или домен, где HopeDC принял роль KDC).
• «Создать домен» — создание нового локального домена (важно: позволяет пересоздать домен, если удалить hope.local). В модалке переключатель «Где создать домен»: новый лес, дочерний домен в существующем лесу (напр. corp.lol.local) или новое дерево в существующем лесу (напр. lol.ru в лесу lol.local), см. п.4.12. Пароль администратора скрыт, с переключателем показа.
• Поддомены / лес. При создании поддомена автоматически: сид дочернего домена (свой krbtgt/administrator), DNS‑делегирование (зона потомка + NS в родительской зоне), двустороннее доверие родитель↔потомок и меж‑реалмовые ключи для кросс‑реалм Kerberos. Раздел «Сайты» у потомка показывает общие сайты корня леса. В списке доменов у потомка бейдж «↳ поддомен · родитель: …».
• Удаление домена — удаляет объекты домена (и его дочерних доменов), а с v125 также его DNS‑зоны (сам домен и _msdcs), делегирование в родительской зоне, PTR‑записи на его имена, записи доверий и межреалмовые учётки krbtgt/… в оставшихся доменах. Зоны доменов, удалённых предыдущими версиями, убираются при запуске ядра. Пулы DHCP не удаляются. Защищённый от удаления домен (см. 4.10) удалить нельзя; делегат удалить домен не может.
• «Принять роль KDC» — для интегрированного домена: HopeDC создаёт собственный ключ krbtgt (RC4 и AES) и начинает обслуживать Kerberos этого домена (сценарий вывода Windows‑DC из эксплуатации, см. п.4.9 «Вывод Windows‑DC»). Рядом — индикатор готовности: сколько активных пользователей уже имеют кэшированные ключи. У домена, отключённого от AD, в столбце типа — «Мигрирован из AD».

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

4.1. Структура домена

Аналог «Active Directory Users and Computers». Слева — дерево OU/контейнеров (ширину можно тянуть мышью), справа — таблица объектов выбранного узла.

Возможности

• Создание объектов: пользователь, группа, подразделение (OU).
• Поиск и фильтры: строка поиска (глобальный поиск по домену), фильтр по типу (Пользователи / Группы / Компьютеры / Подразделения), переключатель «Сервисные» — по умолчанию скрывает служебные записи (GPO‑контейнеры с GUID‑именами, System/Exchange‑контейнеры, служебные объекты политик Linux).
• Различие ОС компьютеров: Linux‑хосты помечаются иконкой терминала и бейджем «Linux», Windows — синим бейджем «Windows» (по атрибуту operatingSystem, который заполняют realm/adcli при вводе).
• Перемещение объектов между OU перетаскиванием (drag&drop).
• Редактирование карточек пользователя, группы, компьютера и OU (вкладки General, членство, Attribute Editor и т.д.).
• «Локальный пароль» (иконка ключа): задаёт пароль объекту прямо в HopeDC. Пароль сохраняется как NT‑хэш (NTLM/Kerberos), AES‑ключи и bcrypt (веб‑вход). Учётка сможет аутентифицироваться даже после отключения Windows‑DC; в MS AD пароль при этом не меняется.

Контроллеры домена: OU «Domain Controllers» (v192)

Как в MS AD, в каждом собственном домене HopeDC есть подразделение Domain Controllers, а в нём — учётная запись компьютера каждого контроллера HopeDC, который держит этот домен (метка «Контроллер домена» и значок сервера). Запись создаётся сама: при создании домена (любого вида — новый лес, поддомен, дерево), при запуске службы и в фоне раз в 2 минуты — так в OU появляются и узлы кластера, и региональные контроллеры. Имя записи — имя узла из «Кластер (HA)» (NetBIOS: латиница, цифры и дефис, до 15 символов); если узел переименован, запись переименовывается. Атрибуты — как у DC Windows: userAccountControl 532480 (учётная запись контроллера, доверенная для делегирования), первичная группа Domain Controllers (516), dNSHostName (hopedc.<домен>), operatingSystem «HopeDC» и версия. К OU привязана Default Domain Controllers Policy, в корне домена — wellKnownObjects на OU (как в AD).

• Защита. OU «Domain Controllers» и записи контроллеров нельзя удалить, переместить или переименовать — ни из панели (вместо кнопки удаления — замок), ни по LDAP (ADUC, PowerShell), ни через SAMR. У записи контроллера меняются только описательные атрибуты (description, info, location, managedBy); у OU — описание и привязка групповых политик. Пароль записи задать нельзя.
• Вход и службы не меняются. У записи нет SPN, а её ключи случайные и никому не известны: службы контроллера (LDAP, Kerberos, SMB/SYSVOL) по‑прежнему работают под служебной учёткой hopedc-ldap-svc, и войти под записью контроллера нельзя. SPN, добавленные к ней вручную, снимаются автоматически.
• Выведенный узел. Запись другого узла (например, выведенного из кластера) может удалить только полный администратор панели; если этот узел ещё работает, он создаст запись снова. Запись узла, на котором открыта панель, не удаляется никем.
• Для доменов, интегрированных с MS AD, подразделение не создаётся — там свои контроллеры MS AD. RODC свою запись не создаёт.

4.2. Групповые политики (Windows GPO)

Управление объектами групповых политик Windows. Три вкладки:

• Объекты GPO — список GPO (имя, GUID, статус, WMI‑фильтр, дата изменения). Создание нового GPO, редактирование, удаление. Двойной клик по строке выделяет её (удобно для массовых операций).
• Связи (Links) — привязки GPO к домену или OU (атрибут gPLink). Кнопка «Привязать GPO к OU» открывает мультивыбор: несколько GPO × несколько целей (корень домена и настоящие OU), флаг «Принудительно (Enforced)». Вложенные OU отображаются путём вида «Linux / Ubuntu».
• Редактор настроек (GPME) — редактор параметров конкретного GPO по словарю ADMX (Machine/User). Вкладка появляется только при редактировании выбранного GPO.

4.3. Политики Linux

Пошаговые инструкции: ввод Linux‑машин в домен — Документ 10, настройка и доставка политик — Документ 11.

Каталог шаблонов политик Linux доступен и из главного меню — пункт «Каталог шаблонов» под «Домены» (с выбором домена), см. Документ 11.

Гибридное управление политиками для Linux‑клиентов. Часть читает штатный SSSD, часть применяет агент hopedc-agent. Вкладки:

• Sudo‑правила — объекты sudoRole, которые читает SSSD (sudo_provider=ad). Поля sudoUser, sudoCommand, sudoOption. Имя правила = имя объекта в каталоге; допускается только латиница/цифры/. _ - (без кириллицы).
• Политики машин — объекты hopeLinuxPolicy (тип file/package/cron/sysctl/smb), применяются агентом к машинам — членам целевой группы. Есть встроенные и пользовательские шаблоны.
• Политики пользователей — файлы окружения/лимитов, применяются к пользователям — членам выбранной группы (подстановка %USERGROUP%).
• Связи (OU) — привязка политик к OU (аналог связей GPO). Мультивыбор политик и OU; агент применяет политику, если объект компьютера лежит внутри выбранного OU (включая вложенные) или хост входит в целевую группу.
• Агент — генерация конфигурации/скрипта ввода и скачивание агента; выбор способа аутентификации агента (пароль сервисной учётки или клиентский сертификат mTLS / SASL EXTERNAL).

Поля выбора групп/машин/OU реализованы как поиск с фильтрацией — корректно работают даже при тысячах групп и хостов. Списки разделяют группы машин (содержат компьютеры) и группы пользователей; для машинных групп показывается состав по ОС (Linux/Windows).

4.4. Сайты и службы (Sites and Services)

Аналог консоли «Active Directory Sites and Services». Слева — дерево: Sites (сайты и их серверы), Subnets (подсети), Inter‑Site Transports → IP / SMTP (связи сайтов). Справа — обзор топологии и управление выбранным узлом.

Возможности

• Сайты — создание/удаление сайтов; для каждого — список серверов и привязанных подсетей.
• Подсети — CIDR‑подсети с привязкой к сайту.
• Серверы сайта — объекты серверов (с dNSHostName).
• Связи сайтов (site‑to‑site) — в транспортах IP/SMTP: имя, состав сайтов (≥2), стоимость (cost) и интервал репликации. Это конфигурация репликации между сайтами.
• Обзор топологии — счётчики и таблица связей site‑to‑site.

Локальный домен и интегрированный домен

Для локального домена HopeDC раздел ведёт собственную структуру сайтов (кнопка «Создать структуру сайтов» заводит контейнеры и Default‑First‑Site‑Name).

Для интегрированного домена (заданы параметры синхронизации с MS AD) раздел работает с Configuration NC реального AD: при синхронизации топология сайтов импортируется из `CN=Sites,CN=Configuration,…`, а изменения (создание/изменение/удаление сайтов, подсетей, связей) записываются обратно в AD — двусторонняя синхронизация. Об этом сообщает зелёный баннер в разделе.

4.5. DNS‑сервер зоны

Управление записями DNS домена: дерево зон (как в консоли MS DNS) или плоская таблица; создание/редактирование записей A/AAAA/CNAME/MX/TXT/SRV/NS/PTR/SOA; форвардеры; TSIG‑ключ и политика динамических обновлений своего домена (см. ниже); кнопка «Структура AD» (засев служебных SRV/A/CNAME записей DC‑locator: _ldap._tcp, _kerberos, _gc, pdc, _msdcs, DomainDnsZones/ForestDnsZones); импорт зон из AD. Системные записи (SOA/NS/_*) защищены от удаления.

Динамические обновления (RFC 2136). TSIG‑ключ и политика задаются отдельно для каждого домена (атрибуты корня домена hopeTsigKeyName/hopeTsigAlgo/hopeTsigSecret, hopeDnsSecureUpdates); ключ одного домена не принимается для зон другого домена (ответ NOTAUTH). Подпись проверяется вместе со свежестью (окно fudge, не более 15 минут), ответ подписывается тем же ключом.

• «Только безопасные» — неподписанные обновления отклоняются (REFUSED); подписанные ключом домена принимаются для любых типов записей.
• «Безопасные и небезопасные» (по умолчанию) — без подписи клиент может только регистрировать A/AAAA/PTR (как это делают Windows/SSSD), удалять лишь записи, созданные динамически, и не может занять имя, на котором уже есть статическая запись (например, hopedc, pdc, записи DC‑locator). SRV/NS/SOA/CNAME/TXT без подписи пропускаются.
• В зонах обратного просмотра принимаются только PTR; подписанная PTR должна указывать на имя в домене подписавшего ключа.

Псевдонимы CNAME (v130). Если у имени есть только CNAME, а спрашивают другой тип (A, AAAA, MX, SRV…), сервер отдаёт всю цепочку сразу — CNAME и конечные записи цели, как MS DNS и BIND (RFC 1034 §4.3.2): www.hope.local → web.hope.local → dc01.hope.local A 10.77.3.218. Цепочка разворачивается по всем зонам контроллера, не длиннее 8 звеньев; петли (a → b → a) обрываются с предупреждением в журнале. Если цель вне наших зон и клиент просил рекурсию, ответ на неё запрашивается у форвардера и добавляется к CNAME. Цель, которой нет в зоне, даёт NXDOMAIN вместе с CNAME (RFC 6604) — так видно, на каком звене обрыв. Запросы типа CNAME и ANY отдают сам CNAME без разворачивания.

4.6. DHCP‑сервер зоны

Управление пулами адресов (scope), диапазонами, шлюзом, DNS‑серверами, сроком аренды в контексте домена.

4.7. Центр сертификации

Внутренний удостоверяющий центр домена: выпуск и отзыв сертификатов, шаблоны, корневой сертификат и список отзыва (CRL). Используется, в частности, для выпуска клиентских сертификатов агента Linux (mTLS/SASL EXTERNAL). У каждого домена свой ЦС; домены разных лесов друг друга не видят.

• Шаблоны по доменам. Стандартные шаблоны (Web Server, Domain Controller, Code Signing, User) общие, но включаются и выключаются отдельно в каждом домене — отключение в одном домене не влияет на другие. Шаблон, созданный в домене, виден и применим только в нём; удалить можно только собственный шаблон домена (общие помечены «общий»).
• Вкладка «Корневой ЦС». Субъект, отпечаток, срок действия корневого сертификата, номер и дата следующего выпуска CRL, число отозванных; кнопки скачивания .crt и .crl; списки точек CDP и AIA.
• CRL, CDP и AIA. Каждый выданный сертификат содержит случайный 128‑битный серийный номер, расширение CRL Distribution Points и Authority Information Access. CRL подписан ключом ЦС, действует 8 дней и перевыпускается ежедневно, а также сразу после выпуска или отзыва сертификата. Публикация:
  • по HTTP: http://hopedc.<домен>/pki/<домен>.crl и .crt (порт 80, меняется переменной DC_PKI_HTTP_PORT; доступ ограничен тем же списком сетей, что и LDAP);
  • в каталоге (только для собственных доменов HopeDC): CN=Public Key Services,CN=Services,CN=Configuration,… — контейнеры CDP, AIA и Certification Authorities, как у MS Enterprise CA. Члены домена Windows автоматически получают корневой сертификат в доверенные.
  Для интегрированных доменов (MS AD) публикуется только HTTP — Configuration NC реального AD не изменяется.
• Сертификаты узлов кластера. Сертификаты HTTPS/LDAPS узла выпускаются с особой служебной отметкой; при связи между узлами кластера сертификат по цепочке ЦС принимается только с этой отметкой. Сертификат, выпущенный в панели (даже по шаблону Domain Controller и с именем узла), выдать себя за узел кластера не может.

4.8. Доверие (Trusts)

Управление доверительными отношениями домена с другими доменами/лесами: создание доверия (внешнее по паролю или внутрилесное), направление, SID filtering (карантин), выборочная аутентификация и суффиксы имён (TLN) для forest‑доверия. Пользователи доверенного домена проверяются по Kerberos‑PAC (подпись ключом доверия), а не биндом к чужому контроллеру.

• Проверки при создании. Домен‑партнёр должен быть корректным DNS‑именем и отличаться от локального; локальный домен должен существовать на этом сервере; SID партнёра (если указан) — в формате S-1-5-21-…. Второе доверие для той же пары доменов не создаётся — измените или удалите существующее.
• Изменение доверия (v187). У внешних и лесных доверий кнопка с карандашом («Изменить») задаёт адрес DC партнёра и пароль доверия; направление, тип и транзитивность задаются при создании — чтобы их поменять, удалите доверие и создайте заново (как в AD). Доверие внутри леса HopeDC (родитель ↔ поддомен, корень ↔ дерево, метка «ВНУТРИ ЛЕСА») создаётся вместе с доменом и удаляется только вместе с ним: вместо кнопок изменения и удаления у него замок и кнопка «Сменить ключ доверия» — новый случайный ключ записывается сразу в оба домена, выданные билеты продолжают действовать. Изменить или удалить такое доверие через API тоже нельзя: удаление или смена пароля с одной стороны разорвали бы вход между доменами леса.
• «Проверить связь». Убеждается, что DC партнёра доступен и обслуживает именно указанный домен; если DC отвечает за другой домен, проверка завершается ошибкой. Администратор, ограниченный своими доменами, может проверять только DC партнёров доверий своих доменов.
• Доверия из MS AD. Для домена, интегрированного с Microsoft AD (или Samba), доверительные отношения этого AD (объекты trustedDomain, в т.ч. с другими доменами и лесами) импортируются автоматически: сразу при интеграции и затем каждые 10 минут. Новые доверия добавляются, изменённые в AD (направление, тип, атрибуты, SID) — обновляются, удалённые в AD — удаляются. Адрес DC партнёра и пароль доверия, заданные в HopeDC вручную, при обновлении сохраняются; созданные вручную доверия не затрагиваются. Кнопка «Импорт из AD» запускает то же самое немедленно. Переносятся: партнёр, NetBIOS-имя, направление, тип, атрибуты (лесное, карантин/SID-фильтрация, выборочная аутентификация), SID партнёра; транзитивность определяется как в AD (лесное и внутрилесное — транзитивные, внешнее — нетранзитивное). Записи помечены значком AD.
• Лимит лицензии. Импорт учитывает лимит доверий тарифа: на Free доверия не добавляются (лимит 0). С v154 об этом сообщают мастер подключения (на экране «Готово») и кнопка «Импорт из AD»: сколько доверий не добавлено и по какому тарифу. После установки подходящей лицензии нажмите «Импорт из AD».
• Изоляция лесов. Если на одном сервере HopeDC размещено несколько лесов, пользователь одного леса получает билет к службе другого только через доверие (реферальный билет), с выборочной аутентификацией и фильтрацией SID. Без доверия запрос отклоняется. Домен, выдавший реферальный билет, не может выдать себя за пользователя чужого домена.
• Вход в панель через доверие. Пароль пользователя партнёра проверяется на DC партнёра по LDAPS (636); если LDAPS у партнёра нет — по LDAP 389 с предупреждением в журнале. Пустой пароль не принимается ни при каком способе входа.

• Видимость для Windows. Каждое доверие публикуется как объект trustedDomain в CN=System домена (LDAP) и отдаётся по RPC: NETLOGON DsrEnumerateDomainTrusts / NetrEnumerateTrustedDomains[Ex] (их используют nltest /domain_trusts и выбор объектов) и LSA LsarEnumerateTrustedDomains[Ex] (перечисление доверий через политику LSA, его используют средства администрирования доверий). Флаги домена в ответе соответствуют направлению доверия (исходящее/входящее) и принадлежности лесу.
• Кластер. Пароль доверия, суффиксы леса (TLN) и время смены пароля хранятся в реплицируемом объекте доверия и доступны на любом узле: любой узел может восстановить ключи Kerberos доверия и сменить пароль. Пароль по LDAP не отдаётся, на диске зашифрован мастер‑ключом узла. Доверия из старых версий переносятся в этот формат автоматически при запуске узла, где они создавались.

Права в лесу: Enterprise Admins и Domain Admins

Модель прав повторяет Windows:

• Enterprise Admins (группа корня леса) управляют всеми доменами леса, включая поддомены и деревья — панель, LDAP и SMB/SYSVOL.
• Domain Admins управляют только своим доменом: администратор родителя не управляет поддоменом, администратор поддомена — родителем.
• Enterprise Admins определяются строго как <SID корня леса>-519, а не по имени группы или любому SID с окончанием -519 — одноимённую группу в поддомене подделать нельзя.

4.9. Интеграция (AD/LDAP)

Вкладка зависит от состояния домена. Если домен ещё не интегрирован, на ней открывается мастер интеграции (источник каталога, адрес DC, LDAPS, необязательный отпечаток сертификата, учётные данные). Если интегрирован — панель интеграции:

• сводка: контроллер и протокол, состояние сертификата LDAPS, время последней синхронизации;
• кнопки «Синхронизировать сейчас» и «Мастер интеграции» (повторная интеграция);
• параметры подключения: адрес PDC, учётная запись и пароль, интервал, LDAPS;
• блок «Сертификат LDAPS контроллера».

Параметры синхронизации данного домена с внешним контроллером домена:

• IP контроллера‑источника (PDC), hopePdcIp;
• учётная запись синхронизации hopeSyncUser и пароль hopeSyncPass (хранится в зашифрованном виде);
• флаг LDAPS (hopeUseLdaps) — синхронизация по 636 с TLS.

Проверка подлинности контроллера AD (сертификат LDAPS)

HopeDC не просто шифрует канал к DC, а проверяет, что на другом конце — именно ваш контроллер. Иначе злоумышленник в сети мог бы подставить свой сертификат и получить пароль учётной записи синхронизации. Порядок проверки:

1. ЦС AD. Цепочка сертификата DC строится до центра сертификации AD, при этом проверяются имя DC (dnsHostName контроллера или адрес подключения) и назначение «Проверка подлинности сервера». Сертификат другого компьютера домена, выпущенный тем же ЦС, не подходит. Сертификаты ЦС HopeDC сам берёт из конфигурации леса (CN=Public Key Services,CN=Services,CN=Configuration) после первого подтверждённого входа. Поэтому ежегодный перевыпуск сертификата DC проходит без действий администратора: новый отпечаток запоминается автоматически, в журнале — «сертификат DC перевыпущен (подтверждён ЦС AD)».
2. Закреплённый отпечаток. Если ЦС AD не сохранён или сертификат DC выпущен не им (самоподписанный, сторонний ЦС), сравнивается SHA‑256 сертификата с закреплённым.
3. Первое подключение. Если ничего не сохранено, сертификат принимается и закрепляется. В мастере интеграции показываются субъект, издатель, срок действия и SHA‑256. Сверьте отпечаток на самом DC, например в PowerShell:
   Get-ChildItem Cert:\LocalMachine\My | % { $_.Subject; [BitConverter]::ToString([Security.Cryptography.SHA256]::Create().ComputeHash($_.RawData)) }

Чтобы исключить даже первое непроверенное подключение, введите ожидаемый отпечаток в поле «Отпечаток сертификата LDAPS (необязательно)» мастера интеграции. Тогда HopeDC подключится только к DC с этим сертификатом.

Если сертификат не прошёл проверку, подключение отклоняется без перехода на LDAP 389 (иначе злоумышленнику было бы достаточно «сломать» порт 636). Синхронизация останавливается с ошибкой «сертификат DC не подтверждён», в журнале — оба отпечатка.

Где смотреть и управлять: «Домены» → домен → вкладка «Интеграция (AD/LDAP)» → блок «Сертификат LDAPS контроллера» (в сводке вверху вкладки — краткое состояние). Там видно:

• способ проверки (ЦС AD / закреплённый отпечаток / первое подключение);
• субъект, издатель и срок действия сертификата;
• SHA‑256 и имя DC;
• число сохранённых ЦС AD.

Если DC предъявил другой сертификат, ниже появляется красный блок с его данными и кнопкой «Доверять этому сертификату». Нажимайте её только после сверки отпечатка на самом DC. В том же блоке можно задать отпечаток вручную или сбросить проверку: тогда следующее подключение закрепит сертификат заново. При смене адреса PDC в настройках проверка сбрасывается автоматически.

Подключение FreeIPA (v198)

HopeDC переносит из FreeIPA пользователей, группы и хосты и дальше синхронизирует их по интервалу домена и кнопке «Синхронизировать сейчас». Схема FreeIPA (389‑DS + MIT Kerberos) отличается от AD, поэтому объекты приводятся к модели AD при импорте.

Подключение. Только LDAPS (636) с проверкой сертификата: при первом подключении отпечаток SHA‑256 закрепляется (сверьте его на сервере FreeIPA: openssl s_client -connect <ip>:636 </dev/null | openssl x509 -noout -fingerprint -sha256) или задаётся заранее. Учётная запись — например admin: короткое имя превращается в uid=admin,cn=users,cn=accounts,<база>. Выгрузка постраничная, поэтому ограничение 389‑DS на число записей в ответе (по умолчанию 2000) не мешает.

Пароли. Если учётка синхронизации может читать ipaNTHash (в FreeIPA его по умолчанию читают только служебные учётки доверия ipa‑adtrust — выдайте право на чтение, если нужно), NT‑хэш переносится сразу: работают NTLM и Kerberos RC4. Ключи krbPrincipalKey (формат MIT) не переносятся. Иначе пароль проверяется в FreeIPA при первом входе по LDAP или в панель (bind uid=…,cn=users,cn=accounts,… или имя@REALM) и сохраняется в HopeDC вместе с ключами AES.

Kerberos. Пока роль KDC не принята, билеты для реалма FreeIPA выдаёт сам FreeIPA. После «Принять роль KDC» билеты выдаёт HopeDC: пользователи с перенесённым NT‑хэшем входят по RC4 (ключи AES появятся после первого входа по LDAP или смены пароля), пользователи, проверенные при входе, — по AES.

Не переносятся: правила HBAC и sudo FreeIPA, группы хостов и netgroups, DNS‑зоны, сертификаты (Dogtag), OTP‑токены, ID views и политики паролей FreeIPA. Групповые политики Windows и SYSVOL к FreeIPA неприменимы.

Если домен ещё не подключён, открывается Мастер подключения к домену (целевой сервер → учётные данные → репликация → готово). Когда домен подключён, показывается статус «Подключено (Online)» и кнопка «Синхронизировать сейчас». Блоки «Параметры соединения», «Интервал синхронизации» и «Подключение Linux хостов к домену» — сворачиваемые (по умолчанию свёрнуты).

Вывод Windows‑DC из эксплуатации

Чтобы домен, интегрированный с MS AD, продолжил работать без контроллеров Windows, на панели интеграции есть карточка «Вывод Windows‑DC из эксплуатации» из трёх шагов.

1. Роль KDC. Кнопка «Принять роль KDC» создаёт собственный ключ krbtgt HopeDC (RC4 и AES) и ключ службы LDAP ldap/hopedc.<домен>. Учётная запись krbtgt, пришедшая синхронизацией из AD, ключа не имеет (AD не отдаёт пароли по LDAP), поэтому ключ создаётся прямо в ней, без дублей. Синхронизация с AD продолжается и ключи HopeDC не затирает. С этого момента домен в переходном периоде: на вкладке «Ключи Kerberos» можно менять ключ krbtgt HopeDC; ключ krbtgt в AD независим и меняется в самой AD.
2. Проверка готовности показывает, что помешает работе без Windows‑DC:
   • есть ли ключ krbtgt HopeDC;
   • сколько активных пользователей имеют пароль в HopeDC (и список тех, у кого его нет). Пароль попадает в HopeDC, когда пользователь хотя бы раз вошёл через HopeDC (сквозная проверка через AD, пока Windows‑DC работает) или когда пароль сброшен в HopeDC. Остальные после вывода Windows‑DC не войдут до сброса пароля;
   • сколько компьютеров имеют пароль учётной записи в HopeDC. Остальные компьютеры нужно заново ввести в домен (или сбросить их учётную запись);
   • DNS‑записи домена, указывающие на адрес Windows‑DC: после его вывода замените адрес на адрес HopeDC;
   • доверия без пароля в HopeDC: задайте пароль доверия, иначе доверие перестанет работать вместе с Windows‑DC;
   • (v181) файлы групповых политик в HopeDC: у скольких политик они есть, конфликты и расхождения версии GPT.INI. Файлы переносит синхронизация SYSVOL с контроллером AD по SMB (Документ 3, без агента); если она не включалась — вручную (Документ 12, раздел 5). При отключении HopeDC выполняет последнюю синхронизацию SYSVOL и выравнивает версии.
3. Отключение от AD. Кнопка «Отключить от AD» (для подтверждения нужно ввести имя домена): если роль KDC ещё не принята, она принимается; синхронизация с AD останавливается, адрес PDC, учётные данные AD и данные проверки сертификата LDAPS удаляются; DNS‑записи, импортированные из AD, становятся собственными записями HopeDC. Домен становится собственным доменом HopeDC с отметкой «Мигрирован из AD» и датой. Отменить отключение нельзя: вернуть домен в AD можно только новой интеграцией (мастер интеграции).

Перенос паролей из AD при миграции (v166)

Чтобы пользователям не пришлось менять пароли при переходе на HopeDC, парольный материал учёток можно перенести заранее. По умолчанию пароль попадает в HopeDC только когда пользователь впервые входит через него (сквозная проверка через AD) или когда администратор сбрасывает пароль; перенос заполняет готовность сразу для всех. HopeDC по сети у контроллера AD ничего не считывает — он принимает файл, который администратор выгрузил на своём контроллере AD штатными средствами (у него есть на это права), и раскладывает значения по атрибутам тех же учёток, как он и так хранит их для собственных учётных записей.

Кнопка «Перенести пароли из AD» (значок ключа) у интегрированного домена открывает окно: вставьте выгрузку или загрузите файл, при необходимости включите «Заменять пароль и у учёток, у которых он уже есть». Кнопка «Проверить» показывает, что будет сделано, ничего не записывая; «Перенести» применяет. Файл нигде не сохраняется.

Имя — sAMAccountName (с префиксом ДОМЕН\ или суффиксом @домен или без них). Пустые строки и строки с # пропускаются. Сопоставление (v170): сначала по имени, затем по RID/SID из выгрузки — так находятся переименованные учётки. Соль Kerberos (v170): для машинных учёток ($) используется host-based соль AD, а не REALM+имя, — вход машин по AES работает без отката на RC4.

Отчёт (v170). Кроме счётчиков (разобрано / совпало / обновлено польз. и комп. / с ключами AES / только RC4 без AES / перенесена история / сопоставлено по SID / пропущено / без пароля / не нашлось / ошибки) показывается таблица пофамильно (учётка — статус — какие ключи) с выгрузкой CSV-отчёта для аудита. Строки «только RC4» подсвечиваются — это подсказка донести ключи AES. Перенос доступен с правом integration.edit и пишется в журнал безопасности (событие 4724).

Как выгрузить парольный материал на контроллере AD

Выгрузку делает администратор своего домена своими правами на своём контроллере — HopeDC в этом не участвует. Формат строк, которые понимает окно переноса, совпадает с форматом выгрузки распространённых средств администрирования AD. Ниже — типовые способы; выберите один.

Права: шаги 1 и 3 выполняет полный администратор или роль с правом integration.edit; делегированным администраторам домена они недоступны.

Вход по смарт-картам и сертификатам (PKINIT) (v167)

PKINIT (RFC 4556) — предварительная проверка открытым ключом: пользователь входит по сертификату со смарт-карты или токена (Рутокен, JaCarta) либо из файла, без пароля. KDC проверяет подпись запроса и цепочку сертификата до доверенного ЦС, сопоставляет сертификат с учётной записью и выдаёт TGT. Так работают вход по смарт-карте в Windows, kinit (MIT), SSSD и Astra. Реализован режим обмена ключами Диффи — Хеллмана (DH), который эти клиенты используют по умолчанию; передача ключа шифрованием RSA не поддерживается (на неё KDC отвечает ошибкой, и клиент переходит на DH).

Кнопка «Вход по смарт-картам (PKINIT)» (значок карты) у домена открывает окно управления:

• Включить / отключить. При включении HopeDC выпускает сертификат KDC, подписанный корневым ЦС домена (если ЦС ещё нет — создаёт его). Сертификат KDC несёт назначение id-pkinit-KPKdc и SAN krbtgt/REALM@REALM — по нему клиент доверяет подписи ответа. Отключение сохраняет сертификат KDC и список ЦС.
• Перевыпустить сертификат KDC — например, по истечении срока (по умолчанию 5 лет) или при смене ЦС домена.
• Доверенные ЦС. По умолчанию доверяется корневой ЦС домена HopeDC. Если сертификаты пользователей выданы внешним центром (ведомственный УЦ, Microsoft CA, КриптоПро УЦ), добавьте его корневой сертификат (PEM) — тогда KDC будет принимать и такие карты. Удаление ЦС отзывает доверие немедленно.

Чтобы карта подошла, сертификат пользователя должен: (1) проверяться до одного из доверенных ЦС; (2) иметь назначение «Проверка подлинности клиента» (clientAuth) или «Вход по смарт-карте» (1.3.6.1.4.1.311.20.2.2); (3) содержать имя учётки — UPN в SAN (otherName 1.3.6.1.4.1.311.20.2.3, как в Windows) или принципал Kerberos в SAN (1.3.6.1.5.2.2). HopeDC сопоставляет сертификат с учёткой по UPN (userPrincipalName или локальная часть = sAMAccountName).

Вход только по смарт-карте (passwordless) (v168)

В карточке учётной записи флажок «Вход только по смарт-карте (PKINIT) — пароль не действует» (атрибут userAccountControl, бит UF_SMARTCARD_REQUIRED, как в AD) делает учётку беспарольной: вход только по сертификату/смарт-карте.

• Kerberos: KDC отказывает в парольной предпроверке (PA-ENC-TIMESTAMP) и в ответе KDC_ERR_PREAUTH_REQUIRED предлагает клиенту только PKINIT — клиент сразу просит смарт-карту, пароль не запрашивается.
• NTLM (SMB): вход паролем запрещён — STATUS_SMARTCARD_LOGON_REQUIRED.
• LDAP simple bind: вход паролем отклоняется (как у отключённой учётки).
• Админка HopeDC (v169): такая учётка в панель паролем не входит (панель отдаёт понятный отказ; входа в панель по смарт-карте нет). Встроенный администратор панели — отдельная учётка и этим флагом не затрагивается, заблокировать себе доступ нельзя.

То есть флаг защищает вход в ОС (интерактивный вход на рабочую станцию Windows/Linux идёт по Kerberos → только PKINIT) и сетевую аутентификацию; парольный вход закрыт на всех путях.

Групповые управляемые учётные записи служб (gMSA) (v168)

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

Создание: раздел Структура домена → «Создать» → тип «Управляемая учётка службы (gMSA)». Задаются:

• Имя учётки (к нему добавляется $, как у машинных учёток).
• Интервал смены пароля, дней (по умолчанию 30, минимум 1).
• Кому можно получать пароль — DN или SID серверов (или их группы), на которых работает служба. Только они смогут прочитать пароль.

Учётка создаётся в контейнере CN=Managed Service Accounts домена (создаётся автоматически), получает SID, SPN HOST/имя.домен и первый управляемый пароль (256-байтный, как в AD). HopeDC держит ключи Kerberos и NT-хэш учётки синхронными с текущим паролем, поэтому служба проходит проверку подлинности обычным образом.

Корзина объектов (v173, по доменам — v194)

Аналог «Корзины Active Directory». Удаление пользователя, группы, подразделения (OU) или компьютера не стирает объект сразу, а помещает его в корзину: объект пропадает из каталога (его не видят LDAP, вход по Kerberos, панель), но хранится со всеми атрибутами и может быть восстановлен целиком. Это защищает от случайного удаления — типовой причины аварий в домене.

v194: корзина — у каждого домена своя. Раздел — вкладка «Корзина» в рабочей области домена («Домены» → домен → группа «Система» → «Корзина», над «Свойствами домена»; право recyclebin.view, действия — recyclebin.edit); в главном меню его больше нет. Вкладка показывает только объекты, удалённые из этого домена (без поддоменов и других доменов): администраторы и делегаты одного домена не видят удалённые объекты другого — и не могут их восстановить или удалить, даже зная идентификатор. Для доменов, интегрированных с MS AD, вкладка скрыта (корзину ведёт AD). Колонки: имя, тип, когда удалён и сколько осталось до очистки, исходное место (путь вида домен / подразделение). Действия:

• Восстановить — открывается окно выбора места: «В исходное место» (подразделение, откуда объект удалён; v195 — показано явно: имя подразделения, его вид — OU, контейнер или корень домена, путь и DN) или «Выбрать подразделение» — дерево подразделений этого домена (служебные контейнеры скрыты). Если исходного подразделения больше нет, сразу предлагается выбор из дерева. Объект возвращается со своими атрибутами и членством в группах; имя в выбранном месте должно быть свободно. Восстановить можно только в исходный домен — учётные данные и SID объекта принадлежат ему.
• Срок хранения и включение — кнопка «Настройки» на вкладке: свои у каждого домена (хранятся на объекте домена и реплицируются вместе с ним), по умолчанию корзина включена, срок хранения — 180 дней (от 1 до 3650). Фоновая очистка удаляет объекты по сроку их домена. Домены без своих настроек берут прежние общие настройки сервера.
• Удалить навсегда — окончательное удаление из корзины (необратимо).

В настройках раздела задаётся срок хранения (по умолчанию 180 дней, как в AD) и признак «корзина включена». По истечении срока объект удаляется окончательно автоматически. Если корзину выключить, удаление снова стирает объект сразу и безвозвратно.

Инвентаризация компьютеров (v179)

v184: инвентаризация — вкладка рабочей области домена: «Домены» → домен → «Инвентаризация» (право inventory.view — «Инвентаризация компьютеров» в матрице ролей; делегат видит только свои домены). На вкладке — компьютеры только этого домена, поиск ПО — тоже по домену. Прежний пункт меню убран, ссылка /inventory ведёт в «Домены».

Вкладка показывает по каждому компьютеру: ОС и сборку, производителя, модель и серийный номер, процессор, память, диски со свободным местом, сетевые адаптеры (IP, MAC), вошедших пользователей, установленные программы и обновления Windows (KB). Компьютеры без сведений агента показаны с данными каталога (ОС из объекта компьютера).

• Компьютеры — таблица с поиском (имя, IP, MAC, модель, серийный номер, пользователь) и фильтрами «без данных», «устарели (>7 дней)», «мало места (<10% на любом диске)»; выгрузка в CSV (открывается в Excel). Щелчок по строке — карточка: обзор, программы с фильтром, обновления.
• Поиск ПО — где установлена программа и какие версии: например, найти все машины со старой версией браузера.
• Подключение — инструкции и скрипт для Windows.

4.10. Свойства домена

Сведения о домене (право domains.view):

• Общие сведения: DNS‑ и NetBIOS‑имя, DN, SID и GUID домена, тип (собственный домен HopeDC, дочерний домен леса, дерево в лесу HopeDC, интегрированный с MS AD/LDAP, отключённый от MS AD после принятия роли KDC), функциональный уровень, имя и адрес контроллера, дата создания.
• Лес: корень леса, родительский (для дерева — родитель по доверию) и дочерние домены, деревья леса, домены леса на этом сервере.
• Состав каталога: число пользователей (и отключённых), групп, компьютеров, OU, групповых политик, доверий и делегатов — только объекты самого домена, без поддоменов.
• Параметры: описание домена и защита от случайного удаления. Пока защита включена, домен нельзя удалить из списка доменов. Менять параметры может администратор домена (Domain Admins) или роль с правом domains.edit; делегат видит вкладку только для чтения.

Вкладка «Загрузка данных» задаёт, как панель работает с большими списками домена (право на изменение — как у параметров):

• Умный режим (по умолчанию) — до 5000 объектов в домене действует локальный кэш, больше — серверная пагинация. На вкладке видно число объектов и какой режим действует сейчас.
• Локальный кэш — весь каталог домена загружается в браузер: поиск и переходы мгновенные. Для небольших доменов. Если в домене больше 5000 объектов, панель предупреждает, сколько данных браузер будет загружать при каждом открытии домена (≈ 0,5 КБ на объект, 200 тыс. объектов — около 100 МБ). Больше 20 000 объектов локальный кэш недоступен (v127): вариант заблокирован в панели, сервер отклоняет его сохранение, а ранее выбранный локальный кэш в таком домене действует как серверная пагинация.
• Серверная пагинация — пользователи и компьютеры домена в браузер целиком не загружаются. Список «Структуры домена» листается страницами по 100 (OU сверху, затем по имени в естественном порядке), поиск, фильтр типа и скрытие служебных записей выполняет сервер. В карточках объектов выбор участников групп, менеджера и субъектов безопасности ищет по серверу, имена по ссылкам подгружаются; UID/GID для UNIX‑атрибутов назначает сервер. Группы, OU, политики и сайты загружаются как прежде; для политик Linux сервер сообщает состав групп (Linux/Windows‑машины).

4.11. Делегирование

Назначение пользователей и групп пользователей, которым разрешено входить в панель и управлять только этим доменом. Делегат получает доступ к разделу «Домены» только для своего домена; разделы Лицензия, Учётные записи, Роли, глобальный DHCP остаются недоступны.

• Кандидаты — только пользователи и группы этого домена (без поддоменов и других лесов); привилегированные, машинные, служебные и системные объекты в список не попадают.
• Сопоставление по объекту. Запись делегата хранит DN и SID; при входе пользователь проверяется по самому объекту и по членству в группах, включая вложенные. Одноимённые учётки и группы других доменов и лесов прав не получают. Записи, сделанные до v124 (только имя), ищутся строго внутри домена; если объект удалён, запись помечается «не найден» и удаляется при сохранении.
• Делегат — не администратор домена. Как в AD (AdminSDHolder), делегату недоступны привилегированные группы и учётки — Domain/Enterprise/Schema Admins, Administrators, Account/Server/Print/Backup Operators, Administrator, krbtgt, служебные учётки HopeDC — и все их члены (с учётом вложенности). Делегат также не может: менять делегирование, удалять домен, назначать основную группу, кроме Domain Users/Guests/Computers, ставить флаги делегирования Kerberos и учётки контроллера домена, менять служебные атрибуты корня домена.
• Кто меняет делегирование: член Domain Admins этого домена (Enterprise Admins — для всех доменов леса) или учётка панели с правом delegation.edit. Остальные видят список только для чтения.
• Отзыв доступа. Права входа через каталог пересчитываются по текущему каталогу (кэш 20 секунд): снятый делегат или исключённый из Domain Admins теряет доступ сразу, без ожидания окончания сессии.

4.12. Поддомены, деревья и лес

HopeDC поддерживает лес доменов, как Active Directory. Новый домен можно создать тремя способами (раздел Домены → «Добавить домен» → «Создать локальный домен», переключатель «Где создать домен»):

Как создать домен в существующем лесу

1. Раздел Домены → «Добавить домен» → «Создать локальный домен».
2. Выберите «Дочерний домен в существующем лесу» или «Новое дерево в существующем лесу».
3. Для поддомена выберите родительский домен и введите одну метку (например msk); для дерева выберите лес и введите полное имя (например corp.ru). Итоговое имя, DN и NetBIOS‑имя показываются под полем.
4. Задайте администратора и пароль, язык журналов, нажмите «Создать».

Через API: POST /api/directory/create-child-domain (parent_fqdn, label) и POST /api/directory/create-tree-domain (forest_fqdn — любой домен леса, fqdn); оба — с admin_username, admin_password, log_lang, право domains.edit.

Что настраивается автоматически

• Свой домен: SID, контейнеры, собственные krbtgt и administrator, группы Domain Admins/Users/Computers/Guests, SPN — домен работает как отдельный реалм (мультиреалм‑KDC).
• Групповые политики: SYSVOL домена и стандартные GPO (Default Domain Policy со ссылкой на домене, Default Domain Controllers Policy) создаются сразу вместе с доменом (с v187; раньше — фоновой задачей в течение 2 минут, и раздел «Групповые политики» нового домена сначала был пуст).
• DNS: зона нового домена (SOA/NS/A) и записи DC‑locator (_ldap, _kerberos, _msdcs). У поддомена дополнительно NS‑делегирование + glue‑A в зоне родителя; у дерева делегирование не нужно. С v186 записи DC‑locator и crossRef (NetBIOS‑имя) появляются сразу, без перезапуска службы, — для всех способов создания домена.
• Двустороннее транзитивное доверие внутри леса: поддомен — с родителем, дерево — с корнем леса; меж‑реалмовые ключи Kerberos.
• Кросс‑реалм Kerberos: при запросе службы из другого домена леса KDC выдаёт реферальный TGT, и билет выдаёт целевой реалм. Путь между деревьями идёт через корень леса (например, corp.ru → corp.local → msk.corp.local).
• Общий Configuration/Schema NC: RootDSE домена отдаёт rootDomainNamingContext, конфигурацию и схему корня леса; раздел «Сайты» показывает общие сайты корня.

Особенности

• В списке доменов у поддомена бейдж «↳ поддомен · родитель: …», у дерева — «🌲 отдельное дерево леса» (с v196 лес виден по заголовку группы). В «Свойствах домена» тип — «Дерево в лесу HopeDC», родитель — «Родитель по доверию (корень леса)», у корня отдельно перечислены деревья леса.
• Администрирование: Enterprise Admins корня леса управляют всеми доменами леса, включая деревья; администратор дерева или поддомена — только своим доменом (см. п.4.8, «Права в лесу»).
• NetBIOS‑имя домена — первая метка имени (corp.ru → CORP). С v186 нельзя создать домен, чьё NetBIOS‑имя уже занято другим доменом сервера (corp.ru рядом с corp.local): вход CORP\user стал бы неоднозначным.
• Зеркало MS AD. В лес домена, интегрированного с внешним MS AD (без принятой роли KDC), HopeDC домены не добавляет: такой лес принадлежит MS AD, и его контроллеры о новом домене не узнают. Онлайн‑присоединение к лесу MS AD (репликация DRSUAPI) HopeDC не выполняет.
• Удаление: поддомены удаляются вместе с родителем. Деревья в DN корня не вложены, а схема и конфигурация леса хранятся у корня, поэтому корень леса нельзя удалить, пока в лесу есть деревья, — сначала удалите их (сообщение перечисляет такие домены).
• Вкладка «Интеграция (AD/LDAP)» для доменов леса скрыта — они часть локального леса HopeDC.
• Глобальный каталог леса доступен на портах 3268 (LDAP) и 3269 (LDAPS) — поиск по всем доменам леса, включая деревья; домены других лесов сервера в нём не видны.
• Региональный сервер дерева (п.4.13) держит только своё дерево. Если клиент запрашивает службу домена, неизвестного региональному серверу (например, другого дерева), KDC отправляет его к родителю по доверию — корню леса, который знает все свои домены.

4.13. Региональные серверы дочерних доменов

HopeDC ставится не только в корневом домене, но и в регионах с дочерними доменами. Региональный сервер держит только свой домен: учётные записи и ключи Kerberos родительского домена к нему не реплицируются, не принимаются и не хранятся. Общими остаются только конфигурация и схема леса. Настройка — в Кластер (HA) → «Разделы (домены) этого сервера» (или переменной DC_HOSTED_DOMAINS); пошаговый порядок пары «центр ↔ регион» и токены сопряжения описаны в Документе 7 «Кластер HA», раздел 10.

• Enterprise Admins работают и здесь: пользователь родителя администрирует поддомен на региональном сервере через проверенный PAC по доверию.
• Изоляция в обе стороны: центр не отдаёт региону чужие домены и не принимает от региона изменений родительского домена; из реплики узла с ограниченным разделом отклоняются объекты с чужим SID, группы Enterprise/Schema Admins, sIDHistory, материал krbtgt и правки корня домена.
• Защита от эскалации «снизу вверх» (строже Windows): скомпрометированный контроллер поддомена не может пронести привилегированный SID вверх (golden ticket / SID‑history). В классическом AD граница безопасности — весь лес, здесь она жёстче.

4.14. Ключи Kerberos домена (смена krbtgt)

Вкладка Домены → домен → «Ключи Kerberos» управляет ключом krbtgt этого домена — им подписываются все билеты Kerberos домена — и ключом служебной учётной записи hopedc-ldap-svc.

У каждого домена свои ключи. При создании домена HopeDC заводит в нём собственную учётную запись krbtgt со случайным ключом. KDC подписывает билеты домена ключом krbtgt именно этого домена, поэтому ключи разных доменов на одном сервере независимы: смена ключа на вкладке одного домена не затрагивает остальные, а утечка ключа одного домена не позволяет подделать билеты другого. У дочернего домена тоже свой krbtgt; для доверия «родитель — потомок» дополнительно заводятся межреалмовые учётные записи krbtgt-<домен>. Для доменов, интегрированных с MS AD, вкладка не показывается: их krbtgt хранится и меняется в самой AD. Исключение — домен, для которого HopeDC принял роль KDC (вывод Windows‑DC, п.4.9): вкладка показывается с пометкой о переходном периоде, а после отключения от AD домен управляется как собственный.

Для каждой учётной записи видны версия ключа (kvno), дата последней смены, возраст ключа в днях и статус:

• В порядке;
• Старый ключ ещё принимается — ключ сменён меньше 10 часов назад (срок жизни билета), билеты на прежнем ключе ещё действуют;
• Давно не менялся — возраст ключа krbtgt больше порога напоминания.

Как работает смена

Кнопка «Сменить ключ» создаёт новый случайный ключ. Текущий ключ становится «предыдущим» и принимается до следующей смены, поэтому уже выданные билеты продолжают работать, а пользователи ничего не замечают. Новые билеты выдаются на новом ключе.

Повторная смена в течение 10 часов заблокирована: она отозвала бы ключ, которым ещё зашифрованы действующие билеты. Под кнопкой показывается, через сколько повторная смена станет доступна. Ссылка «Принудительно…» выполняет смену сразу — только при подтверждённой компрометации: пользователям и службам придётся заново получить билеты (выход/вход, klist purge), часть служб может временно не пускать пользователей.

Регулярная смена и напоминания

Microsoft рекомендует менять krbtgt регулярно, например раз в полгода. Карточка «Регулярная смена krbtgt» задаётся для каждого домена отдельно: у разных доменов могут быть разные пороги напоминания и периоды плановой смены.

• Напоминать, если ключ не меняли дольше N дней (по умолчанию 180; 0 — не напоминать). Напоминание показывается в Обзоре DC (жёлтая плашка: по щелчку на имени домена открывается его вкладка «Ключи Kerberos»), на вкладке домена и раз в сутки по каждому домену пишется в журнал: ⏰ Ключ krbtgt домена … не меняли … дн. (порог … дн.).
• Менять krbtgt автоматически каждые N дней (от 30 до 3650) — плановая смена. Выполняется одна смена за раз (это безопасно: старый ключ ещё принимается). Проверка — раз в час, результат пишется в журнал: 🔐 Плановая смена ключа krbtgt … выполнена.

Каждая смена ключа и изменение настроек записываются в журнал с именем пользователя и доменом. Через API ключ меняется только в указанном домене (domain в запросе); если собственных доменов несколько, а домен не указан, смена отклоняется.

4.15. Политика паролей, PSO и вход по компьютерам (v159)

Раздел домена «Политика паролей» (право gpo.view — просмотр, gpo.edit — изменение) задаёт требования к паролям пользователей домена, срок их действия и блокировку после неверных попыток. Параметры, общие с AD (длина, сложность, история, минимальный и максимальный срок, блокировка), сохраняются в Default Domain Policy (GptTmpl.inf, раздел [System Access]) и зеркально — в атрибуты корня домена (minPwdLength, pwdProperties, pwdHistoryLength, minPwdAge, maxPwdAge, lockoutThreshold…), поэтому их видят и Windows‑клиенты.

• Проверять пароли по политике домена — главный переключатель. В доменах, созданных до v159, он выключен (пароли не проверяются, поведение прежнее); в новых доменах включён.
• Минимальная длина, сложность — как в AD: три категории символов из четырёх (прописные, строчные, цифры, спецсимволы), без имени учётной записи и частей полного имени.
• Размер алфавита (ФСТЭК) — сумма мощностей классов символов, использованных в пароле: латиница строчная и прописная — по 26, цифры — 10, спецсимволы — 33, кириллица строчная и прописная — по 33. Например, «Gorizont2026» — 62, «Gorizont#2026» — 95.
• Словарь запрещённых паролей — встроенный (частые пароли, раскладка «gfhjkm», месяцы и сезоны) и свой словарь домена (до 100 000 слов, загрузка из файла). Сравнение без учёта регистра, с заменой «l33t»‑символов (@→a, 0→o, 1→i, $→s) и без цифр и символов по краям: «Qwerty2026!» отклоняется как «qwerty». Также запрещены имя домена и учётки.
• История (до 24) и минимальный срок проверяются при смене пароля самим пользователем; сброс администратором их не проверяет (как в AD).
• Ограничить срок действия паролей — отдельный переключатель. Включённый: пароль старше максимального срока и флажок «Сменить пароль при следующем входе» (pwdLastSet=0) не дают войти, пока пароль не сменят: Windows и kinit получают KDC_ERR_KEY_EXPIRED и сами предлагают смену (через kpasswd), LDAP‑вход отклоняется с кодом AD data 532/773, NTLM — STATUS_PASSWORD_EXPIRED, панель показывает форму смены пароля. Не истекают: встроенный Administrator, учётки с флагом «Срок действия пароля не ограничен», учётки компьютеров и служб, а также учётки без даты смены пароля (до первой смены). Перед включением раздел показывает, у скольких пользователей пароль уже истёк.
• Заготовки: «Как в AD по умолчанию» и «ФСТЭК, класс 3/2/1» (мера ИАФ.4: длина ≥6/6/8, алфавит ≥60/70/70, 3–10/3–8/3–4 попытки, блокировка 5–30/10–30/15–60 мин, смена не реже 120/90/60 дней). Значок у заголовка показывает, каким классам соответствуют текущие параметры.

Где проверяется новый пароль: сброс в панели, «Локальный пароль», страница смены пароля, kpasswd (смена и установка; причина отказа для Linux — по‑английски), LDAP (unicodePwd/userPassword: удаление старого + добавление нового — смена, замена — сброс; отказ — constraintViolation с текстом причины), SAMR (STATUS_PASSWORD_RESTRICTION). В интегрированном и не захваченном домене паролями ведает AD — HopeDC его политику не дублирует.

Политики паролей для групп и пользователей (PSO). Как Fine‑Grained Password Policy в AD: объект msDS-PasswordSettings в CN=Password Settings Container,CN=System домена со своими требованиями и блокировкой, назначенный пользователям и группам (с вложенными). Действует вместо политики домена (и при выключенном главном переключателе). Назначенная напрямую главнее назначенной через группу; среди групповых — с меньшим значением «Приоритет». PSO, созданные по LDAP средствами AD (ADAC, New-ADFineGrainedPasswordPolicy), тоже учитываются. В таблице видно, на скольких пользователей действует каждая политика; в карточке пользователя (вкладка «Учётная запись») — какая политика действует, когда пароль менялся и когда истекает.

Смена пароля пользователем. На странице входа — ссылка «Сменить пароль пользователя домена» (имя, текущий и новый пароль); она же открывается сама, если пароль истёк или его требуется сменить. Неверный текущий пароль учитывается счётчиком блокировки.

Вход на компьютеры (атрибут userWorkstations, кнопка «Log On To…» в ADUC). В карточке пользователя — список NetBIOS‑имён компьютеров; пусто — вход с любого. Проверяется при первичном входе: Kerberos (имя из запроса Windows или, для Linux, по IP‑адресу клиента через DNS‑записи A/AAAA/PTR зон HopeDC) — отказ KDC_ERR_POLICY; NTLM — поле Workstation, отказ STATUS_INVALID_WORKSTATION. Если имя компьютера определить нельзя (нет DNS‑записи для адреса), вход отклоняется — заведите A‑записи для Linux‑машин.

5. Службы: DNS, DHCP и NTP (глобально)

DNS Сервер

Глобальный раздел управления встроенной службой DNS (порт 53): запуск/остановка службы, просмотр всех зон (прямого и обратного просмотра) с числом записей и пометкой «AD» (импортированные). Управление конкретными записями выполняется в разделе домена. У каждой зоны есть кнопка «Перейти» — открывает вкладку DNS соответствующего домена (доступна, если зона относится к управляемому домену и у роли есть право domains.view; иначе кнопка заблокирована).

Условная пересылка (v165). Карточка «Условная пересылка»: зона (суффикс, например partner.local) и её серверы (IP или IP:порт через запятую, до 8). Запросы к именам в этой зоне и её поддоменах, не относящиеся к своим зонам HopeDC, уходят на эти серверы по очереди (2 с на сервер), остальные внешние имена — на общий форвардер; при нескольких подходящих зонах побеждает самая длинная. Цели CNAME вне своих зон дорезолвливаются так же. Настройка общая для сервера (реплицируется на все узлы), API — GET/PUT /api/dns/conditional.

Старение и очистка записей (v165). Карточка «Старение и очистка записей» — как в Windows DNS: интервал без обновления и интервал обновления (по умолчанию 168 ч = 7 суток), зоны (пусто — все). Касается только записей, которые клиенты регистрируют сами (DNS UPDATE: Windows, SSSD, NetworkManager); ручные, служебные (DC‑locator), импортированные из AD и созданные DHCP записи не стареют. В течение интервала без обновления повторная регистрация ничего не пишет (нет лишней репликации), после — запись продлевается; запись, не обновлявшаяся дольше обоих интервалов, удаляется очисткой (раз в час на каждом узле, событие 5141 в журнале безопасности). При включении записям, созданным до v165, ставится текущее время — отсчёт начинается с момента включения. «Что будет удалено» — пробный прогон, «Очистить сейчас» — немедленная очистка. Время обновления хранится в идентификаторе записи (UUID v7), формат базы и репликации не меняется — узлы прежних версий в кластере работают с такими записями как обычно.

DHCP Сервер

Глобальное управление службой DHCP и пулами по всем сетям.

Доменные пространства имён DFS (v131)

Контроллер обслуживает доменные пространства DFS (режим Windows Server 2008, [MS-DFSNM]): пользователь открывает \\hope.local\Files\Docs, а контроллер направляет его к серверам пространства. Пространства создаются файловым сервером (HopeDFS «Пространства DFS» → «Доменное», или консолью DFS Management) как объекты каталога CN=<имя>,CN=<имя>,CN=Dfs-Configuration,CN=System,<домен> (класс msDFS-Namespacev2).

• На запрос корня пространства (\\домен\имя, в DNS- или NetBIOS-форме) контроллер отвечает списком серверов пространства из msDFS-TargetListv2 с TTL из msDFS-Ttlv2 (по умолчанию 300 с). Цели в состоянии «offline» не выдаются.
• Ссылки на папки (\\домен\имя\Папка) выдаёт уже сервер пространства — контроллер в это не вмешивается.
• SYSVOL и NETLOGON обслуживаются, как прежде; имена пространств с ними не пересекаются.

Проверка на клиенте Windows: dir \\hope.local\Files, затем dfsutil /pktinfo — в кэше видны корень пространства и сервер, на который он указывает.

NTP Сервер (точное время)

Встроенный сервер времени домена (v128). Решает две задачи: держит часы самого контроллера точными по внешним источникам и раздаёт время членам домена на UDP 123. Качество реализации — на уровне chrony/ntpd, а не простого SNTP-ответчика: по каждому источнику копится фильтр из 8 последних измерений (берётся замер с наименьшей задержкой), достоверные источники выбираются пересечением интервалов (алгоритм Марзулло, «вруны» отсекаются), а системные часы подстраиваются ядерным контуром (плавный увод частоты; ступенька только при большом сдвиге). По умолчанию служба выключена; включается в этом разделе (право ntp.edit). Точное время критично: Kerberos отклоняет билеты при расхождении более 5 минут.

• Статус. Синхронизированы ли мы, страт, смещение и джиттер часов, выбранный источник, дрейф частоты. Отдельно — таблица источников с их смещением, задержкой и регистром достижимости (как chronyc sources), и статистика раздачи (обслужено, подписано MS-SNTP, защищено NTS, отклонено).
• Подстройка часов. Переключатель «Подстраивать системные часы сервера». Выключено — режим наблюдения: служба раздаёт время и показывает смещение, но часы не трогает. Для подстройки юниту нужна возможность CAP_SYS_TIME (её выдаёт скрипт развёртывания); без неё панель показывает предупреждение, а служба продолжает раздавать время.
• MS-SNTP (Windows). Подпись ответов ключом учётной записи компьютера — член домена Windows проверяет, что время пришло от доверенного контроллера. Поддержаны классическая форма и расширенная (Windows Server 2012+; SP800-108/HMAC-SHA512). Отдельной настройки на клиентах Windows не нужно: вступив в домен, они синхронизируются с контроллером автоматически.
• NTS (RFC 8915). Защищённое время для Linux-клиентов chrony 4+: ключи выдаются по TLS (порт 4460, сертификат из ЦС домена), пакеты аутентифицируются (AES-SIV-CMAC-256). «Печенья» не хранят состояние на сервере и работают на любом узле кластера.
• Симметричные ключи. Ключи NTP (SHA-256 / SHA-1 / AES-CMAC, RFC 5905/8573) для сетевого оборудования и внешних источников. Секреты не отображаются после сохранения и не отдаются через API/LDAP.
• Источники. Внешние серверы времени (хост/IP, iburst, предпочтение, ключ). «Минимум согласующихся источников» задаёт, сколько источников должны сойтись, чтобы время считалось достоверным.
• Доступ и защита. Ограничение раздачи по подсетям (как у LDAP; loopback всегда). Защита от усиления: лимит запросов с одного адреса — при превышении отправляется Kiss-o’-Death (RATE), запросы управления (mode 6/7) не обслуживаются.
• Свободный ход (v130). Если у мастера времени нет доступных внешних источников (изолированная сеть, нет выхода в Интернет), примерно через минуту он начинает раздавать собственные часы на страте из поля «Страт свободного хода» (по умолчанию 10, идентификатор LOCL) — как «Local CMOS Clock» у PDC-эмулятора AD или local stratum 10 у chrony. Так все члены домена остаются согласованными между собой и Kerberos работает. Часы самого контроллера в этом режиме не правятся. Как только источник станет доступен, сервер вернётся к нему. 0 в поле — режим выключен: без источников клиенты получат «не синхронизировано» (страт 16). Остальные узлы кластера в свободный ход не переходят — они берут время у мастера.
• Иерархия в кластере. Как у PDC-эмулятора AD: один узел (с наименьшим идентификатором среди доступных) — мастер времени, берёт внешние источники; остальные синхронизируются с ним, а при его отказе переходят на внешние. Все настройки NTP реплицируются по кластеру.

6. Безопасность

Учётные записи

Доступ к админ‑панели HopeDC. Через «Создать пользователя» доступны три типа записей:

• Локальный — учётка панели с собственным именем, e‑mail и паролем.
• Доменный пользователь — конкретный пользователь из выбранного домена, сопоставленный с локальной ролью. Входит своим доменным паролем (сквозная проверка PTA/LDAP), отдельный пароль не заводится.
• Доменная группа — при входе роль получает любой член группы. Членство определяется по memberOf, а также по первичной группе (primaryGroupID + objectSid), поэтому работает и «Domain Users», которой в memberOf нет.

В форме сперва выбирается домен, затем принципал (поиск с фильтрацией; технические учётки, компьютеры, системные почтовые ящики и объекты Exchange из списка исключены). В таблице у каждой записи виден тип (Локальный / Домен · пользователь / Домен · группа), статус и роль. Сопоставления доменных принципалов хранятся отдельно (не в bincode‑учётках) и не мешают локальным. Встроенная учётка admin всегда поддерживается активной (защита от потери доступа).

Роли и права (RBAC)

Роли определяют набор прав (например domains.view, gpo.view, dns.view, roles.edit и т.д.). Встроенные роли: Администратор (право * — полный доступ) и Только чтение. Системные роли изменять нельзя — создавайте кастомные. Права вида domain:<fqdn> ограничивают делегата конкретными доменами.

Раздел матрицы «Контроллеры» (v188): controllers.view — список контроллеров и журналы задач, controllers.edit — добавление, изменение и удаление записей, проверка, установка и обновление по SSH. Роли с правами «Кластер (HA)» получили их автоматически при обновлении; администраторы домена (Domain Admins) получают оба права для контроллеров своего домена, делегаты — только просмотр (v195; см. «Контроллеры» в разделе 7).

Новые разделы матрицы (v184): «Корзина» (recyclebin.view — просмотр, recyclebin.edit — восстановление, очистка, срок хранения), «Инвентаризация компьютеров» во вкладках домена (inventory.view), «Журнал безопасности» (seclog.view/seclog.edit) и «Двухфакторная (MFA): политика и назначение» (mfa.view/mfa.edit). Раньше корзину и инвентаризацию открывало любое право на каталог, журнал безопасности — права «Логирование», политику MFA — только полный доступ. При обновлении роли получают новые права по прежним (домены → корзина и инвентаризация на чтение; изменение каталога → корзина на изменение; «Логирование» → журнал безопасности), делегаты доменов — корзину и инвентаризацию своих доменов. Без отдельного права: «Каталог шаблонов» — по праву «Групповые политики», MFA своей учётки и «Описание API» — любому вошедшему, «Обновления» — только полный доступ.

Для вкладки домена «Ключи Kerberos» предусмотрены права kerberos.view (просмотр, входит в роль «Только чтение») и kerberos.edit (смена ключей и настройка регулярной смены).

Матрица прав повторяет меню панели. В разделе «Домены» отдельно настраиваются вкладки домена: структура, группы, групповые политики (Windows и Linux), сайты и службы (sites.view/sites.edit), центр сертификации, доверия, ключи Kerberos и делегирование (delegation.view/delegation.edit). В разделе «Настройки» добавлен пункт «Связи» (topology.view, только просмотр). При обновлении до v120 существующие роли получили эти права автоматически по прежним: «Сайты и службы» — у ролей с просмотром или изменением доменов, «Делегирование» — у ролей с изменением доменов, «Связи» — у ролей с доступом к кластеру. Доступ пользователей при обновлении не меняется.

Проверка прав на сервере (v125). Права ролей проверяются ядром для каждого запроса, а не только интерфейсом: чтение раздела требует права <раздел>.view, изменение — <раздел>.edit. Запись объектов каталога проверяется по самому объекту: группы — «Управление группами», GPO, связи GPO (gPLink) и политики Linux — «Групповые политики», объекты сайтов — «Сайты и службы», корень домена — «Домены», остальное — «Структура домена». Скачивание бэкапа требует права «Резервное копирование: изменение» (в бэкапе хэши паролей и ключи). Неизвестные пути API доступны только полному администратору. При отказе сервер отвечает 403 с названием нужного права, панель показывает его сообщением вверху экрана.

Права сессии пересчитываются по текущим ролям и каталогу (кэш до 20 секунд, сбрасывается при изменении ролей, учёток и каталога): урезанная роль, отключённая учётка, снятый делегат или исключённый из Domain Admins теряют доступ сразу, а не через сутки после входа. Доменная группа, назначенная роли в «Учётных записях», учитывается с вложенностью и строго в своём домене.

Защита от повышения привилегий (v126). Создавать и менять роли и учётные записи можно только в пределах своих прав: роль не может получить право, которого нет у того, кто её редактирует, а учётке нельзя назначить роль шире собственной. Служебные права вида admin:… вручную не назначаются. Нельзя удалить, отключить или понизить последнюю учётку с полным доступом, а роль, назначенную учёткам, нельзя удалить, пока её не сняли с них. Вход в панель доменной учёткой больше не даёт права на центр сертификации по умолчанию — их нужно выдать ролью явно.

Секреты не покидают сервер. API каталога и панель не отдают хэши паролей и ключи Kerberos (unicodePwd, userPassword, ключи AES и т.п.) — даже полному администратору. В карточке объекта виден только признак «пароль задан / ключи Kerberos есть». Секрет кластера в настройках тоже не показывается (см. раздел «Кластер»).

Делегированному администратору домена (роль с ограничением domain:<fqdn>) для работы своих вкладок доступны на чтение статус кластера, лицензия, состояние DNS‑сервера и его пересылка; при отказе в доступе сервер отвечает понятным сообщением (JSON), а не пустой страницей.

Сетевой доступ

Белый список IP‑адресов клиентов домена (файл net_ldap.json). Применяется к подключениям LDAP (389), LDAPS (636) и Kerberos (88): подключения не из списка отклоняются. Используйте для ограничения круга машин, которым разрешено обращаться к контроллеру.

7. Настройки

Лицензия и версии

Загрузка лицензионного ключа и просмотр текущего использования (домены, объекты, доверия). Для получения ключа скопируйте запрос из раздела и передайте на сервер лицензирования. Ключ проверяется вшитым ключом вендора и привязан к оборудованию сервера.

v197: ключ проверки лицензий нельзя заменить. Подпись лицензии проверяется только открытым ключом сервера лицензий, вшитым в сборку (его отпечаток показан в карточке «Ключ лицензии»). Прежняя возможность задать свой ключ проверки (POST /api/license/pubkey, поле «Доверенный ключ сервера лицензий») удалена: при сборке без вшитого ключа ею можно было бы подписать лицензию самостоятельно. Оставшийся от прежних версий файл license.pub удаляется при запуске. Сборка без настоящего вшитого ключа не компилируется. Установленные лицензии продолжают действовать.

Кнопка «Сравнить версии» открывает таблицу сравнения версий Free / Standard / Enterprise:

Лимиты Standard/Enterprise — типовые; фактические значения задаёт выданный ключ.

Разделы, требующие более старшей версии. Если текущей лицензии недостаточно, раздел открывается только для просмотра, с плашкой о нужной версии: Кластер (HA) требует Enterprise; Доверие (Trusts) и Связи — Standard или выше. На странице кластера при этом недоступны любые изменения: настройки узла, пиры, вкладки, включение/выключение. Уже настроенный функционал продолжает работать — например, если лицензия истекла, кластер продолжает реплицировать, просто его нельзя изменить. Ограничение проверяется и на сервере, а не только в интерфейсе.

Лицензионное соглашение (v148). Условия использования HopeDC — Документ 8. При первом входе после установки (и после выхода новой редакции соглашения) панель вместо разделов показывает текст соглашения: полный администратор панели отмечает согласие и нажимает «Принимаю»; «Не принимаю» — выход. Пока соглашение не принято, остальные пользователи панели видят сообщение «Соглашение должен принять полный администратор панели», а API панели отвечает 428 eula_required. Службы контроллера домена (вход в домен, LDAP, Kerberos, DNS, DHCP, NTP, SMB, репликация) от принятия не зависят и работают всегда. Факт принятия (учётная запись, адрес, время, редакция и SHA‑256 текста) хранится зашифрованным на каждом сервере (eula_acceptance.json в каталоге данных); в кластере соглашение принимается на каждом узле. В разделе «Лицензия» — карточка «Лицензионное соглашение»: кто и когда принял, просмотр текста. Текст доступен и без входа: ссылка на странице входа и hopedc-core --eula. Перечень компонентов третьих лиц (Документ 9) в продукт не входит и предоставляется по запросу.

Резервное копирование

Настройка и запуск резервных копий каталога. Автобэкапы выполняет фоновый воркер ядра. Рекомендуется хранить копии вне сервера DC. Права: backup.view / backup.edit.

• Создание копии — ZIP‑архив выбранных компонентов (база, настройки, журналы) скачивается в браузер.
• Восстановление данных — загрузка ранее скачанного архива. Восстановление выполняется по принципу «всё или ничего»: архив сначала целиком проверяется и только потом записывается. После восстановления перезапустите службу HopeDC.
• Автоматизация — расписание (дни недели, время), каталог для копий, сколько копий хранить, состав; список готовых копий со скачиванием и удалением.

Шифрование данных на диске и мастер‑ключ

Начиная с версии v106 база HopeDC хранится на диске в зашифрованном виде (AES‑256‑GCM). Кража каталога данных или архива бэкапа без мастер‑ключа не даёт ни хэшей паролей, ни ключей Kerberos (в т.ч. krbtgt), ни ключа центра сертификации.

Старые открытые файлы (active.wal, audit.wal, sysvol.wal) и старые архивы бэкапов шифруются автоматически при первом запуске новой версии.

Где лежит мастер‑ключ

Ключ — 32 случайных байта (64 hex‑символа) в отдельном файле вне каталога данных. Ядро ищет его в таком порядке:

1. переменная окружения DC_MASTER_KEY (сам ключ, hex);
2. файл из переменной DC_MASTER_KEY_FILE (если задана — используется только он);
3. /etc/hopedc/master.key — расположение по умолчанию (каталог 0700, файл 0600, владелец — пользователь службы);
4. <каталог данных>.keys/master.key — запасной вариант, если в /etc/hopedc нет прав на запись;
5. <каталог данных>/.master-key/master.key — аварийный вариант.

Если ключа нет нигде, он создаётся при первом запуске. Путь и отпечаток ключа (16 hex‑символов; сам ключ по отпечатку восстановить нельзя) показываются в зелёной плашке раздела Резервное копирование и пишутся в журнал при старте. Если ключ оказался внутри каталога данных, в плашке появляется жёлтое предупреждение: копия каталога в этом случае содержит и ключ — перенесите его в /etc/hopedc/master.key.

Экспорт мастер‑ключа под паролем

Копия ключа сохраняется в файл .hdckey, зашифрованный паролем: ключ шифрования выводится из пароля через Argon2id (64 МиБ, 3 прохода — подбор пароля дорог даже на видеокартах), сам мастер‑ключ шифруется AES‑256‑GCM. Без пароля файл бесполезен.

1. Откройте Настройки → Резервное копирование и нажмите в зелёной плашке «Скачать мастер‑ключ (под паролем)». Кнопка видна только полному администратору панели (право *).
2. Введите пароль своей учётной записи (повторная проверка) и пароль для файла ключа — не короче 12 символов и не совпадающий с паролем учётной записи. При желании добавьте заметку (например, где будет храниться копия).
3. Нажмите «Скачать файл ключа». Скачается файл hopedc-master-<сервер>-<отпечаток>-<дата>.hdckey.

Каждый экспорт и каждая неудачная попытка (неверный пароль, нет прав) записываются в журнал с именем пользователя: 🔑 Мастер‑ключ экспортирован (под паролем) пользователем «…».

Восстановление бэкапа другого сервера

Архив, сделанный на другом сервере, зашифрован его мастер‑ключом. Чтобы восстановить его (например, на новом сервере взамен вышедшего из строя):

1. Резервное копирование → Восстановление данных → «Выбрать ZIP‑архив».
2. Панель сообщит, что архив зашифрован ключом другого сервера, и покажет отпечаток нужного ключа.
3. Выберите файл .hdckey исходного сервера — под кнопкой отобразится его отпечаток, сервер и дата создания. Если отпечаток не совпадает с нужным, панель сразу предупредит «Этот ключ не подходит к архиву».
4. Введите пароль файла ключа и нажмите «Восстановить с этим ключом».
5. Данные перешифровываются на ключ текущего сервера и записываются. Если хоть одна запись не расшифровалась, ничего не записывается. Перезапустите службу.

Ключ исходного сервера при этом на текущий сервер не устанавливается — он нужен только на время восстановления.

Командная строка на сервере

Для случаев, когда панель недоступна (новый сервер, восстановление после сбоя). Запускать от root; путь к бинарнику — как в вашей установке (например /opt/hopedc/hopedc-core). Если каталог данных отличается от /var/lib/hopedc и переменная DC_DATA_DIR не задана, укажите --data-dir.

Защита от ошибок при импорте:

• если база в каталоге данных зашифрована другим ключом, импорт отказывается (с этим ключом база не откроется);
• если на месте уже лежит другой ключ, импорт отказывается; с --force старый файл сохраняется рядом как master.key.bak-<дата>;
• если такой же ключ уже установлен — сообщает об этом и ничего не меняет.

Для сценариев автоматизации пароль можно передать переменной HOPEDC_KEY_PASSWORD (учитывайте, что переменные окружения процесса видны root).

От чего шифрование не защищает

• Образ всего диска сервера. Если ключ лежит в /etc/hopedc на том же диске, что и база, копия всего диска (или всей ВМ) содержит и то, и другое. Для защиты от этого сценария используйте шифрование диска (LUKS) или привязку ключа к TPM.
• Злоумышленник с правами root на работающем сервере — ключ доступен процессу службы.
• Утечка копии ключа вместе с копией базы или бэкапом. В этом случае действуйте как при компрометации AD: дважды смените пароль krbtgt, смените пароли администраторов и служебных учёток, перевыпустите сертификаты ЦС; старые бэкапы считайте скомпрометированными.

Связи

Граф контроллеров, доменов и лесов: подчинённость доменов, доверия, какие домены обслуживает каждый контроллер и реплики между контроллерами. Раздел доступен на контроллере корневого домена (редакция Standard и выше, право topology.view).

• Слои — кнопки «Подчинённость», «Доверия», «Обслуживание», «Реплики» включают и выключают соответствующие связи.
• Фильтр «Домены» — список доменов, сгруппированный по лесам: можно скрыть отдельные домены, весь лес или оставить «только этот» лес. Выбор запоминается в браузере. Контроллер показывается, если обслуживает хотя бы один видимый домен.
• Во весь экран — граф занимает всё окно браузера; выход — кнопкой «Свернуть» или клавишей Esc.
• Разные леса раскладываются отдельно вокруг обслуживающего их контроллера. Клик по узлу приближает к нему, кнопка с перекрестием вписывает граф целиком. Мышь: левая кнопка — вращение, колесо — масштаб, правая — сдвиг.

Связи конкретного домена. В рабочей области домена есть вкладка «Связи» (группа «Сеть и безопасность»). Она показывает только данные этого домена: сам домен и его поддомены, его доверия (партнёр — серым узлом), контроллеры, которые его обслуживают, и реплики с ним. Другие домены, которые обслуживают те же контроллеры, не показываются: сервер отфильтровывает их сам. Вкладка работает на любом контроллере этого домена (не только на корневом) и доступна делегированным администраторам домена с правом «Связи».

Логирование

Просмотр и скачивание файловых журналов сервера (hopedc.log.*): выбор файла (или «новейший»), фильтр по уровню (ERROR/WARN/INFO/DEBUG/TRACE), серверный фильтр по подстроке и быстрый поиск по экрану, автообновление, подсветка строк по уровню. Внизу — список файлов со скачиванием каждого. Кнопка «Настроить» задаёт политику хранения журналов (пресеты «Неделя / Месяц / 3 месяца / Год», а также ограничение по возрасту и по количеству файлов); очистка применяется автоматически и по кнопке «Очистить сейчас» (с предупреждением о том, какие файлы удалятся). Новейший активный журнал всегда сохраняется. В рабочей области конкретного домена есть такой же раздел, но с фильтрацией строк по FQDN этого домена. Право доступа: logs.view.

Журнал безопасности (v164)

Раздел «Безопасность → Журнал безопасности» (право «Журнал безопасности: просмотр», изменение настроек, SIEM и мониторинга — «Журнал безопасности: изменение»; v184 — своё право, раньше — права раздела «Логирование»; роли с правами «Логирование» получили его автоматически). События: входы по Kerberos, LDAP, NTLM и в панель (успешные и неудачные, с причиной), блокировки и разблокировки, смена и сброс паролей, изменения каталога и групп по LDAP, изменения и отказы в панели, изменения настроек аудита — с кодами как в журнале безопасности Windows (4624, 4625, 4740, 4768, 4771, 4776, 5136 …); фильтры, поиск, выгрузка CSV и JSON. Настройки и SIEM: состав событий, срок хранения, отправка в SIEM по syslog (UDP, TCP или TLS; CEF или JSON) с проверкой связи. Мониторинг: метрики Prometheus (/metrics с токеном) и шаблон Zabbix.

Кластер (HA)

Раздел настраивает высокую доступность: мульти‑мастер репликацию каталога, DNS, доверительных отношений, доменной политики безопасности и конфигурации DHCP‑пулов между контроллерами домена. Узлы обмениваются изменениями методом «pull» через API (порт 9444, HTTPS) с проверкой общего секрета; новый узел выполняет первичный бутстрап снимком (snapshot). Конфликты (правка одного объекта на разных узлах) разрешаются по правилу «последняя запись побеждает». Права: cluster.view / cluster.edit.

Раздел разбит на четыре вкладки:

• Узлы и репликация — статус этого узла (node_id, локальный USN), настройка узла (имя, общий секрет), список пиров (базовые URL API узлов, порт 9444) с индикацией онлайн/офлайн и счётчиком применённых изменений; кнопка «Реплицировать сейчас». Здесь же — переключатели «Что реплицировать» (каталог, DNS, доверия, политика, DHCP‑пулы; выключенные остаются локальными) и тумблер DHCP‑failover (split‑scope), при котором узлы делят диапазон пула, чтобы не выдать один IP дважды.
• Журнал конфликтов — случаи, когда правка с этого узла столкнулась с правкой того же объекта на другом. По каждой записи видно, что сохранилось и что затёрлось (какая версия, с какого узла, когда), и было ли входящее изменение принято или отклонено.
• Возвраты узлов — отчёты о догоне после того, как пир вернулся в кластер: простой, сколько изменений догнано, сколько было конфликтов (в т.ч. затёртых локальных).
• Согласованность — сверка отпечатков (дайджестов) состояния каталога, DNS, доверий, политики безопасности и DHCP‑пулов с каждым узлом: Сошлись / Расхождение / «Нет связи», с разбивкой по каждой части. Кнопка «Проверить сейчас».

Общий секрет (v126). Секрет кластера в форме не показывается (поле пароля с подсказкой «задан»). Чтобы оставить прежний, оставьте поле пустым и сохраните; новый вводится только при смене.

Пересинхронизация (v126). Кнопка «Пересинхронизировать» запрашивает у пиров полный снимок и сводит его с локальными данными по правилу «последняя запись побеждает»: недостающее добавляется, устаревшее обновляется, удалённое на пирах — удаляется, более новые локальные правки сохраняются. Узел делает это и сам, если обнаружил разрыв в журнале пира (был недоступен дольше, чем журнал хранит события — 8000 изменений) — после возврата узла раньше требовалась пересборка с нуля. Пересинхронизация 200 тыс. объектов занимает 5–10 секунд и не порождает ответных событий репликации.

Контроллеры: установка и обновление по SSH (v188)

Раздел «Контроллеры» главного меню (сразу под «Доменами», v195) и вкладка «Контроллеры» в рабочей области домена (группа «Система», над «Свойствами домена», v195) хранит доступ по SSH к серверам, на которые ставится HopeDC, и выполняет с ними установку и обновление прямо из панели.

• Запись контроллера: имя, адрес (IP или DNS‑имя) и порт SSH, пользователь, вход по паролю или закрытому ключу (OpenSSH или PuTTY, с паролем ключа), пароль sudo (если пользователь не root; по умолчанию — пароль SSH), роль и домены (в главном разделе — выбор из списка доменов сервера флажками, с поиском; во вкладке домена — этот домен). Доступ хранится в каталоге (реплицируется вместе с доменом, на диске зашифрован мастер‑ключом узла), по LDAP и API не отдаётся и в панели не показывается; на RODC не попадает. Пустые поля пароля и ключа при изменении — «не менять».
• Роли. Региональный контроллер держит только указанные домены: сопрягается с этим узлом личным токеном пары, данных и ключей других доменов на нём нет (как региональный сервер, п.4.13). Полная реплика всех доменов — узел полного доверия по общему секрету кластера; её добавляет и устанавливает только полный администратор панели.
• «Проверить подключение» — вход по SSH, ОС, архитектура, работает ли sudo, установлен ли HopeDC и какой версии. Ключ сервера (отпечаток SHA256) запоминается при первом входе и дальше сверяется: если сервер подменён или переустановлен, вход отклоняется с указанием обоих отпечатков (сбросить ключ — флажок в карточке контроллера).
• «Установить» — передаёт пакет (версия этого узла) и install_hopedc.sh во временный каталог сервера, сверяет SHA‑256, запускает установщик с параметрами присоединения (JOIN_CLUSTER=1, домены, токен пары или общий секрет), затем добавляет пир в «Кластер (HA)» этого узла. Новый контроллер получает данные домена со следующей репликацией. Временный каталог удаляется, параметры присоединения служба шифрует и сразу стирает с диска. Ход установки — в журнале задачи (кнопка с журналом у контроллера).
• «Обновить» — до версии пакета, подготовленного полным администратором в «Обновлениях» (если он новее), иначе до версии этого узла. Делегат свою сборку загрузить не может. Установщик сохраняет прежний бинарник и возвращает его, если новая версия не запустилась. Кнопка «Обновить контроллеры домена» (в главном разделе — «Обновить все») обновляет контроллеры по одному; первая ошибка останавливает обновление, остальные контроллеры не трогаются.
• Корневой сервер (v189) — узел, на котором открыта панель, — показан в списке первой строкой (метка «Корневой сервер», версия, ОС, домены). Он только для просмотра: удалить, изменить или обновить его из «Контроллеров» нельзя. Обновляет его только полный администратор панели (или роль с полными правами) в разделе «Обновления» — кнопка «Обновления» в его строке видна только им. «Обновить все» и «Обновить контроллеры домена» корневой сервер не затрагивают. Записи, адрес которых указывает на сам этот сервер (его IP, имя или localhost), не принимаются — иначе делегат мог бы переустановить корневой сервер по SSH.
• Удаление записи удаляет только запись и сохранённый доступ: HopeDC на сервере и его сопряжение остаются (вывести узел из кластера — в «Кластер (HA)»).

Как добавить контроллер

1. Подготовьте сервер: Linux x86_64 с systemd, доступ по SSH (root или пользователь с sudo), сетевой доступ от этого сервера к нему по SSH (22) и от него к этому серверу по порту API (9444), открытые порты домена (Документ 1, п.9). Время — синхронизировано.
2. Контроллеры → «Добавить контроллер» (или «Домены» → домен → «Контроллеры»). Укажите имя, адрес и порт SSH, роль и домены (в главном разделе — флажками из списка доменов сервера), пользователя и способ входа: пароль или закрытый ключ; для пользователя не root — пароль sudo, если он отличается от пароля SSH. Сохраните.
3. Нажмите «Проверить подключение» (значок вилки). В колонке «Состояние» появятся ОС, архитектура, работает ли sudo и установлен ли HopeDC; ключ сервера запоминается.
4. Нажмите «Установить» и подтвердите. Откроется журнал задачи с выводом установщика; по завершении контроллер показывает версию и состояние службы «active», а в «Кластер (HA)» этого узла появляется его пир. Данные домена приходят со следующей репликацией (обычно до минуты).
5. Сохраните пароль панели нового контроллера (v195). Вместо заводского Admin123! установка задаёт учётке панели admin нового сервера случайный пароль (16 символов). По окончании установки он показывается один раз внизу журнала задачи — только тому, кто запустил установку (кнопки «Показать» и «Копировать»). На сервер передаётся только его bcrypt‑хэш; в открытом виде пароль нигде не хранится, и после закрытия окна журнала увидеть его снова нельзя. Если пароль утерян — сбросьте его на сервере консольной командой восстановления доступа (Документ 1).
6. Войдите в панель нового контроллера (https://<адрес>:9443) с этим паролем, смените его (требуется при первом входе) и примите Лицензионное соглашение.

Колонки списка

• Контроллер — имя, адрес, описание. Роль — «Региональный» с доменами или «Полная реплика». Доступ SSH — пользователь, способ входа и отпечаток ключа сервера (сами пароли и ключи не показываются).
• Состояние — версия HopeDC и состояние службы по последней проверке, ОС и время проверки; при ошибке — её текст (например, изменился ключ сервера или не работает sudo).
• Действия — проверить, установить (если HopeDC не установлен) или обновить (если версия ниже доступной), журнал последней задачи, изменить, удалить запись.
• Над списком — версия этого узла и версия, до которой ставятся и обновляются контроллеры (пакет из «Обновлений», если он новее, иначе версия этого узла).

Кто может. Права «Контроллеры» в матрице ролей (просмотр / изменение; роли с правами «Кластер (HA)» получают их автоматически). Администраторы домена (группа Domain Admins, а также Enterprise Admins леса) видят в рабочей области домена контроллеры своего домена и могут добавлять, проверять, устанавливать и обновлять региональные контроллеры этого домена. Делегатам домена (v195) раздел доступен только для просмотра — без кнопок изменения; сервер также отклоняет такие запросы от делегата. Требования к серверу: Linux x86_64 с systemd (Ubuntu/Debian, RHEL‑совместимые, Astra Linux SE), вход по SSH с правами root или sudo; установку выполняет узел, который держит домен (центральный сервер).

Описание API (v165)

Пункт меню «Описание API» (любой вошедший): все методы API панели — раздел, метод, путь, назначение и права, которые проверяет сервер (достаточно любого из перечисленных; «*» — полный администратор), пометка «админ домена» — метод доступен доменно‑ограниченному администратору. Поиск, фильтр по разделу, пример входа через curl. Кнопка «openapi.json» — файл OpenAPI 3.0 для Postman, Swagger UI и генераторов клиентов (он же — GET /api/openapi.json). Вход: POST /api/auth/login → токен → заголовок Authorization: Bearer; ошибки бизнес‑логики приходят с HTTP 200 и {"status":"error","message":…}.

Обновления (v147)

Раздел Настройки → Обновления проверяет и устанавливает новые версии HopeDC прямо из панели — как в Hope Mail Server и Hope MSG Gateway. Доступен только полному администратору панели (роль с полным доступом); делегированные и доменные администраторы его не видят, API отвечает 403.

Версии. Вверху — текущая версия (номер выпуска, например v147; подробности сборки — во всплывающей подсказке), доступная версия из онлайн‑источника и статус. Версию бинарника на сервере показывает hopedc-core --version.

Источник пакета.

• Из архива (закрытый контур). Загрузите hopedc-core_vNNN.gz (или распакованный hopedc-core). Пакет распаковывается и проверяется: исполняемый файл Linux нужной архитектуры, сборка HopeDC v147 или новее, пробный запуск --version с чистым окружением. Показываются версия, размер и SHA‑256 исходного файла — сверьте её с контрольной суммой поставщика. Поле «Версия» необязательно; если указать, она должна совпасть с версией пакета.
• Онлайн‑источник. Адрес манифеста (подойдёт внутренний веб‑сервер), канал stable / beta и автопроверка раз в сутки (о найденной версии пишется в журнал). Манифест — JSON {"version","url","sha256","notes"}, по каналам — {"stable":{…},"beta":{…}}; относительная ссылка считается от адреса манифеста. Пакет без sha256 не ставится, при несовпадении суммы или версии — отклоняется. Используйте HTTPS: по http пакет можно подменить в пути.

Установка. Кнопка «Установить vNNN» (с подтверждением) передаёт пакет системной службе hopedc-update, которая работает от root отдельно от HopeDC: сверяет SHA‑256, ещё раз пробно запускает новую сборку от имени пользователя службы, сохраняет текущий бинарник (/opt/hopedc/hopedc-core.prev и три последних .bak.*), ставит новый, перезапускает HopeDC и ждёт, пока ответит API и служба 10 секунд проработает без перезапусков. Если новая версия не поднялась — автоматический откат на прежнюю. Ход установки (проверка → замена бинарника → перезапуск → готово / откат) виден в разделе; во время перезапуска панель несколько секунд недоступна и затем сама показывает итог. Каталог, ключи и настройки не затрагиваются, но новая версия может обновить формат данных — перед установкой сделайте резервную копию (ссылка есть в окне подтверждения). Можно поставить и более старую версию (v147+) — раздел предупредит об откате.

Кластер. В списке узлов видны версии всех контроллеров кластера (запрос по токену пары / секрету кластера). Обновляйте узлы по очереди из панели каждого: пока один перезапускается, клиентов обслуживают остальные, изменения догоняются репликацией. Разные версии на узлах подсвечиваются — это допустимо на время поэтапного обновления.

Контроллеры (v188). Пакет, подготовленный здесь, используется и разделом «Контроллеры»: оттуда по SSH обновляются серверы, добавленные в него, в том числе региональные и RODC, которые кнопка «Обновить весь кластер» пропускает. Сам этот (корневой) сервер обновляется только здесь и только полным администратором.

Astra Linux. Новый бинарник получает метку МКЦ прежнего (высокая целостность 63), каталоги пакетов — высокую метку. В строгом режиме ЗПС пакет должен быть подписан ключом, заверенным ГК «Астра», иначе пробный запуск не пройдёт и установка будет отклонена без замены бинарника.

8. Ключевые особенности продукта

9. Astra Linux SE: МКЦ, МРД, ЗПС

Проверено на Astra Linux SE 1.8.1 в режиме «Смоленск» (максимальная защищённость) при включённых мандатном контроле целостности (МКЦ), мандатном разграничении доступа (МРД) и замкнутой программной среде (ЗПС). Требуемая glibc — 2.31 и новее (в Astra 1.8 — 2.36), отдельная сборка не нужна.

Установка

Скрипт deploy_astra140.ps1 (из Windows, по SSH) или те же шаги вручную под учёткой администратора в сессии с высоким уровнем целостности (63):

Метки задаются командой pdpl-file 0:63:0:0 <файл> (для каталогов — 0:63:0:iinh), а каталоги HopeDC прописываются в /etc/parsec/fs-ilev.conf строками max /var/lib/hopedc, max /etc/hopedc, max /opt/hopedc — тогда set-fs-ilev сохраняет им высокую метку. Журналы не размещаются в /var/log: в Astra этот каталог имеет низкую целостность, а файл не может быть выше своего каталога. Служба systemd запускается от root и получает высокий уровень целостности (метка процесса 0:63).

МКЦ (v140)

В Astra 1.8 новый файл получает низкую метку целостности независимо от уровня процесса и каталога, а HopeDC переписывает базу и настройки через временный файл и переименование. Поэтому начиная с v140 служба при запуске и сразу при появлении любого нового файла в каталогах базы, журналов и ключа копирует на него метку целостности своего исполняемого файла (атрибут security.PDPL), новым подкаталогам — метку корневого каталога. Уже помеченные файлы не меняются, метки не понижаются. В журнале службы: «МКЦ: каталог … — файлам HopeDC задаётся метка целостности исполняемого файла». Каталоги без метки (низкой целостности) служба не трогает и пишет об этом предупреждение. На других Linux атрибута нет, и механизм не действует.

Проверка защиты: процесс с целостностью 0 (служба systemd с PDPLabel=0:0:0:0) не может изменить файлы базы и журналов, создать файл в каталогах HopeDC, изменить master.key или подложить файл к бинарнику — «Отказано в доступе». Чтение МКЦ не ограничивает: от посторонних данные закрыты правами доступа (0600/0700, владелец root) и шифрованием на диске.

МРД

При включённом МРД служба работает на уровне конфиденциальности 0 и обслуживает обычных (немаркированных) сетевых клиентов: Windows, Linux и Astra на уровне 0. Пока не поддерживаются: подключения клиентов с ненулевым мандатным уровнем (потребуются права службы CapabilitiesParsec=PARSEC_CAP_MAC_SOCK …, как у штатных служб Astra) и выдача мандатных атрибутов доменных пользователей клиентам Astra (аналог ALD Pro). Это в плане развития.

ЗПС

До этого используйте мягкий режим: DIGSIG_ELF_MODE=2 в /etc/digsig/digsig_initramfs.conf, затем sudo update-initramfs -u -k all и перезагрузка. Запуск разрешён, нарушение пишется в журнал ядра (NOT ELF SIGNED: path=/opt/hopedc/hopedc-core). Возврат в строгий режим — то же с DIGSIG_ELF_MODE=1. При строгом режиме проверка подписи 40‑мегабайтного бинарника занимает несколько секунд при каждом запуске — учтено в TimeoutStartSec=180.