⚡ Битрикс24 встаёт по утрам? Виноват модуль «Почта»

Симптом коварен: процессор холодный, MySQL без длинных запросов, swap пуст — а портал отдаёт 502 каждое утро в часы синхронизации IMAP. Мониторинг показывает «всё ок», админ добавляет память — без эффекта. Узкое место сидит в архитектуре PHP-FPM.

Чтение из IMAP-сокета — блокирующая операция: fgets() ждёт ответа Яндекса или Exchange десятки секунд. В стандартном bitrix-env все скрипты крутятся в одном пуле www с pm.max_children порядка 50. Запустились синхронизации десятка ящиков — и воркеры намертво заняты ожиданием почты, живым пользователям обслуживать запросы физически нечем. Перезапуск php-fpm по крону каждые 15 минут (встречали и такое) только убивает сессии и причину не лечит.

🔧 Лечение — изолировать check_mail.php в отдельный пул [mail] с жёсткими лимитами:

Ключевые параметры:
• pm.max_children = 3–12 — по объёму почты, больше бессмысленно (внешний IMAP быстрее не ответит)
• request_terminate_timeout = 40–70s — убивает зависший на сокете воркер
• request_slowlog_timeout на 10 секунд ниже terminate — успеть записать трейс до kill
• pm.max_requests = 100 — страховка от утечек памяти при парсинге писем
• memory_limit = 512M на Debian — вложения с base64-картинками раздувают воркер до сотен МБ
• отдельный mail-slow.log — основной www-slow.log остаётся чистым для диагностики реальных тормозов CRM

Маршрутизация — ровно один URL /bitrix/tools/check_mail.php. На bitrix-env (nginx + Apache) правило кладём в /etc/httpd/bx/custom/check_mail.conf через SetHandler. На nginx-only — точный location = /bitrix/tools/check_mail.php обязательно выше общего location ~ \.php$, иначе общий перехватит запрос раньше. Расширять правило на /bitrix/tools/ целиком запрещено: там лежат скрипты других модулей, webhook-и CRM попадут в маленький почтовый пул и получат 503.

📊 На CentOS-портале с парой ящиков хватает 3 воркеров под пользователем bitrix и сокетом /run/php-fpm/mail.sock. На нагруженном Debian с десятками активных ящиков — 12 воркеров под www-data и /run/php/mail.sock. Принцип универсальный: любой блокирующий внешний интегратор (выгрузка в маркетплейс, опросы API, экспорт в 1С) выносится в свой пул по той же схеме.

Готовые конфиги pool [mail] для CentOS и Debian, правила Apache и nginx, разбор каждого параметра — в полном разборе от IT For Prof

⚡ iVentoy: 34 рабочих места с миграцией на Windows 11 за 7 часов одним инженером

В одном из проектов IT For Prof мы заменили парк из 34 ноутбуков с переходом на Windows 11 и включением в домен. Раньше такое делали два инженера за два дня. С iVentoy уложились в один рабочий день силами одного человека.

iVentoy — PXE-сервер «всё-в-одном»: один бинарник поднимает DHCP, TFTP и HTTP без отдельной настройки сервисов. ISO кладётся в каталог и сразу появляется в загрузочном меню — без распаковки install.wim, правки BCD и SMB-шары. В одном меню держим Windows 10 22H2, Windows 11 24H2, Server 2022, Astra Linux, РЕД ОС, WinPE, Clonezilla и ESXi — поддержка 110+ типов ОС.

🔧 Что важно знать инженеру:
• Установка машины ~20 минут до экрана логина, параллельно ставятся 8–10 штук
• Версия 1.0.35 от 9 июня 2026, один бинарник под Windows и Linux на x86_64 и arm64 — поднимается даже на Raspberry Pi
• Режим «без DHCP»: боевой DHCP контроллера домена не трогаем, отдаём только TFTP+HTTP через option 66/67. В 80% корпоративных внедрений используем именно этот сценарий
• Legacy BIOS, IA32 UEFI, x86_64 UEFI и ARM64 UEFI обслуживаются одним сервером — без отдельных конфигов под pxelinux.0 и bootx64.efi
• Фильтр по MAC отсекает гостевые ноуты от unattend-сценария, который затрёт диск
• Для Linux iVentoy сам решает проблему отсутствующих драйверов NIC и RAID-контроллеров — пересобирать initramfs не приходится

Один инженер запускает 10 машин одновременно — и пока они ставятся, занимается следующей партией.

📊 Подводный камень из практики: запуск iVentoy со встроенным DHCP в общем VLAN с боевым контроллером домена — часть рабочих станций получит IP с «левого» сервера и потеряет шлюз. Правило: либо изолированный сегмент со своим DHCP, либо режим без DHCP через option 66/67 на основном.

Команды запуска, шаблоны unattend.xml и kickstart для Astra Linux/РЕД ОС, разбор Secure Boot и переключения UEFI/Legacy PXE — в полном разборе с кейсом на 34 машины

🔧 GLPI: Service Desk и CMDB в одной open-source системе на своём сервере

GLPI закрывает заявки с SLA и инвентаризацию ИТ-активов в одном веб-интерфейсе, без лицензионных платежей Teclib' — но в реестре Минцифры его нет, поэтому для госзаказчиков и субъектов КИИ путь закрыт.

Для коммерческого сектора это рабочая замена Naumen Service Desk, ManageEngine ServiceDesk Plus, JIRA Service Management и BMC Helix. Данные остаются в контуре заказчика — закрывается 152-ФЗ без облачной обработки третьей стороной. Финансовый блок (бюджеты, поставщики, лицензии) встроен в ядро, а не продаётся отдельным модулем.

Стек минимальный: Linux + PHP с расширениями mysql, xml, gd, intl, mbstring, curl, ldap, zip + MariaDB или MySQL + Apache либо Nginx с PHP-FPM. Для парка до нескольких сотен активов и десятков техников хватает виртуалки на 2–4 vCPU и 4–8 ГБ памяти. Узкое место — не CPU, а скорость диска под MariaDB и настройки PHP-OPcache.

📊 GLPI Agent ставится через GPO или пакетный менеджер на Windows, Linux и macOS — собирает серийники, модели дисков, установленное ПО и патчи. Для коммутаторов, принтеров и точек доступа работает agentless-режим по SNMP: один агент-сборщик закрывает сегмент сети филиала. Без правил дедупликации (Rules → Inventory) по серийнику, UUID и MAC парк за полгода вырастает в полтора раза — один ноутбук после переустановки ОС превращается в новый актив.

Каталог форм самообслуживания снимает 60–70% «свободных» обращений: вместо абстрактной очереди — кнопки «Заявка на доступ», «Новый сотрудник», «Заявка на технику» с маршрутом согласования.

Типовые грабли при установке от инженеров IT For Prof: забытое расширение PHP роняет проверку окружения; дефолтные memory_limit, upload_max_filesize и post_max_size режут импорт инвентаря и вложения в заявках; SELinux в enforcing не даёт веб-серверу писать в каталоги GLPI.

✅ Пошаговая установка на Debian, подключение LDAP/AD, рабочий набор плагинов (Formcreator, Fields, Behaviours, DataInjection) и сценарии интеграции с Zabbix для автосоздания тикетов из алертов — в полном разборе

🔧 Zammad: open-source тикет-система на своём сервере за час в Docker

Официальные пакеты Zammad доступны только для CentOS, Debian и Ubuntu — Windows и macOS остаются вне поддержки вендора. На Linux-хосте docker-compose стек поднимается примерно за 60 минут: четверть времени уходит на подготовку ВМ, четверть на образы, остальное — TLS и первичная настройка.

Под капотом Ruby on Rails, PostgreSQL для базы, Elasticsearch для полнотекстового поиска и Memcached для кэша. Минимум для пилота: 4 vCPU, 8 GB RAM, 80 GB SSD, Ubuntu 22.04 LTS или Debian 12. Узким местом чаще становится Elasticsearch — индекс перерастает JVM heap и вычитывается с диска, поиск тормозит. Лечится расширением heap и выносом ES на отдельный SSD.

Сравнение стеков с близкими альтернативами:
• osTicket — PHP+MySQL, акцент на email, разворачивается быстрее всех
• GLPI — PHP+MySQL, сильный CMDB и учёт техники
• OTOBO — Perl+PostgreSQL, классический ITIL-движок
• Zammad — Rails+Elasticsearch+PostgreSQL, омниканальность из коробки

Каналы заводим по очереди: email через IMAP/SMTP на отдельный ящик support@, Telegram-бот (первое сообщение клиента должно начинаться с /start, иначе тикет приходит без контекста), веб-форма с reCAPTCHA, LDAP/AD с узким фильтром по OU. Один клиент пустил всю AD без фильтра — после первой синхронизации в helpdesk легли тысячи лишних учёток, интерфейс зависал от автодополнений.

Типовая засада docker-инсталляции: переменная TZ не проброшена в docker-compose.yml. Хост в UTC, Zammad настроен на Europe/Moscow — SLA-таймеры считают со сдвигом в час. Проверяйте часовой пояс до того, как заведёте живые тикеты.

Архитектура отказоустойчивого развёртывания, импорт из osTicket через встроенный мастер и миграция с GLPI через REST API — в полном разборе от IT For Prof

🔧 Rocket.Chat на своём сервере: MongoDB в replica set обязательна даже для одного узла

В продакшене Rocket.Chat откажется стартовать без MongoDB в режиме replica set — платформа использует change streams для распространения событий между подами. Это правило срабатывает даже при одном узле БД.

Развёртывание на своём сервере оставляет переписку, файлы и учётные записи внутри периметра компании. На проектах в банке и производстве платформа закрывает сразу два сценария: внутренний корпоративный чат и обращения клиентов через виджет на сайте.

📊 Расчёт ресурсов по нашему опыту:

• 50 сотрудников — один узел, MongoDB на той же машине, SSD под полугодовую переписку, резервные копии на отдельное хранилище
• 200 сотрудников — MongoDB выносим на отдельный сервер, replica set из 3 узлов, 2 контейнера приложения за Nginx, общий S3-бакет для uploads
• 500+ сотрудников — кластер: 3 узла MongoDB, минимум 3 экземпляра приложения, выделенный TURN-сервер для голоса и видео, Prometheus с node-exporter и mongodb-exporter, алерты на репликацию

Грабли из практики: Rocket.Chat на виртуалке с thin provisioning и снапшотами гипервизора без согласования с MongoDB. За 3 месяца база раздулась, снапшот не удалялся, ВМ остановилась по нехватке места на датасторе. С тех пор для MongoDB — только eager-zeroed диск и отдельный том под журнал.

⚡ Первый запуск выполняем поэтапно: сначала поднимаем MongoDB → инициализируем replica set → проверяем rs.status() (PRIMARY, health: 1) → только потом запускаем приложение. docker compose up -d всем стеком сразу в 3 случаях из 10 приводит к тому, что Rocket.Chat успевает записать первые документы до инициализации replica set — после этого базу приходится чистить.

✅ Docker Compose оправдан для 1–2 узлов приложения. От 500 пользователей переходим на Kubernetes с Helm-чартом вендора. SSO через Active Directory, интеграции с Jira, GitLab, Zabbix через webhooks и Apps-Engine — закрывают типовые требования ИБ и DevOps без обучения админов.

Команды инициализации replica set, требования к серверу под 50/200/500 пользователей и docker-compose.yml от команды IT For Prof — в полном разборе

⚡ Open-source тикет-системы: GLPI vs Zammad vs OTOBO vs Chatwoot vs osTicket

GLPI — единственная из пяти систем, которая закрывает связку «тикеты + активы + финансы» в одной установке: Helpdesk, CMDB, бюджеты поставщиков, лицензии и agentless-инвентаризация работают из одного интерфейса.

Облачные SaaS-хелпдески тарифицируются за каждого агента в месяц. При росте команды поддержки с 5 до 50 инженеров счёт растёт линейно, тогда как self-hosted решения по основной лицензии бесплатны: платите только за сервер и администрирование. На горизонте 3–4 лет разница в стоимости владения расходится тем сильнее, чем больше агентов в поддержке.

🔧 Разбор по стеку и зоне применения:

• GLPI — PHP+MySQL, GPLv3. Внутренний ИТ-отдел 200–2000 рабочих мест: связка хелпдеска с CMDB ощутимо экономит время первой линии на заявках по железу
• Zammad — Ruby on Rails+PostgreSQL+Elasticsearch+Redis, AGPLv3. Смешанная поддержка с почтой, Telegram, чатом и Twitter из коробки
• Chatwoot — Ruby on Rails+PostgreSQL+Redis, MIT. Контакт-центр на WhatsApp, Telegram, Facebook, Instagram для розницы и e-commerce
• OTOBO — Perl+PostgreSQL/MySQL, GPLv3. Миграция с OTRS с сохранением процессной модели
• osTicket — PHP+MySQL, GPLv2. Простой почтовый хелпдеск, разворачивается за полдня

📊 Главная ошибка при оценке — считать только лицензию. Реальные статьи расходов: инфраструктура (Rails+Elasticsearch требуют в разы больше RAM, чем PHP), администрирование (Ruby-стеку нужен отдельный DevOps на четверть ставки), коммерческая поддержка, обучение операторов и кастомизация. У GLPI есть 45-дневный пробный период для первой инсталляции — хватает на оценку под реальной нагрузкой.

Небольшая компания внедряла GLPI ради CMDB «на будущее», а позже активы всё равно велись в Excel — некому было заполнять карточки. Система «на вырост» оправдана, только когда рост реальный, а не гипотетический.

Пять типовых сценариев выбора, расчёт стоимости владения за 3 года и схемы интеграции с Active Directory, Zabbix и мессенджерами — в полном разборе от IT For Prof

⚡ Битрикс24: −9 ГБ памяти и TTFB 5,2 → 0,8 с за один день без апгрейда сервера

Клиент: оптовая торговая компания, 120 сотрудников, коробочный портал. Проблема: по утрам карточки сделок открывались 5–15 секунд, в пиковые часы портал отдавал 502 Bad Gateway, отдел продаж терял по 10–20 минут. Внутренний админ добавил серверу RAM — через две недели всё вернулось.

📊 Экспресс-аудит за 60–90 минут по логам nginx, PHP-FPM и медленному логу MariaDB показал четыре независимые причины, и ни одна не про мощность железа:

• Пул PHP-FPM в динамике держал десятки простаивающих воркеров, которые впустую занимали гигабайты
• Модуль «Почта» синхронизировался по блокирующему IMAP прямо в общем www-пуле — в часы синхронизации воркеров не оставалось живым пользователям
• Файлы из S3 Reg.ru шли через PHP, на каждое вложение — отдельный воркер и TLS-рукопожатие
• MariaDB работала на дефолтных значениях, буферный пул InnoDB не вмещал рабочие данные

🔧 Что сделали: перевели www-пул на статический режим с расчётом воркеров под реальную память, вынесли IMAP-синхронизацию в отдельный пул с жёстким таймаутом, добавили в nginx прямое проксирование S3 и Brotli, затюнили InnoDB buffer pool и таймауты в отдельном конфиге, который переживает обновления окружения.

Потребление RAM веб-стеком: 9,3 ГБ → 1 ГБ. TTFB на тяжёлых страницах CRM: 5,2 → 0,8 с. Утренние 502 прекратились. Медленный лог PHP-FPM: ~21 МБ мусора в неделю → десятки килобайт.

✅ Освободившиеся 8 ГБ ушли под буферный пул базы, апгрейд сервера не понадобился. Все работы — один рабочий день.

Формулы расчёта воркеров PHP-FPM, параметры изолированного пула для IMAP и регламент еженедельной профилактики от IT For Prof — в полном разборе кейса.

🔧 Chatwoot: омниканальная поддержка на своём сервере вместо Intercom и Zendesk

Открытая платформа поддержки клиентов с 25 000+ звёзд на GitHub. Объединяет WhatsApp, Telegram, Instagram, email и веб-виджет в одну ленту разговоров — без передачи переписки в чужое облако.

Ключевое отличие от классических тикет-систем: базовая единица здесь — разговор с контактом. Каналы склеиваются по email, телефону или внешнему ID. Для веб-виджета это закрывает identity validation: залогиненный пользователь приходит в Chatwoot с HMAC-подписью, и его чат, почта и WhatsApp с тем же номером автоматически попадают в одну карточку. Где общего ключа нет (Instagram отдаёт только внутренний ID профиля), карточки объединяются вручную через merge.

📊 Архитектура и железо для команды 5–10 операторов:
• Rails-приложение + Sidekiq-воркеры + PostgreSQL + Redis + reverse-proxy (Caddy или Nginx)
• минимум 2 vCPU и 4 ГБ RAM на проде
• SSD под PostgreSQL — поиск по разговорам упирается в IOPS
• от 20 операторов и активного WhatsApp/Telegram-трафика PostgreSQL выносится на отдельный сервер с репликой и регулярным pg_dump

Развёртывание из официального docker-compose занимает около получаса, если DNS и TLS-сертификат готовы заранее. В .env правятся FRONTEND_URL (полный HTTPS-адрес, иначе в письмах битые ссылки), параметры PostgreSQL и Redis, SMTP и S3-совместимое хранилище для вложений. Reverse-proxy должен отдельно проксировать websocket ActionCable, иначе интерфейс грузится, но новые сообщения появляются только после F5.

⚡ Встроенный AI-агент Captain работает в двух режимах: автономно отвечает на типовые вопросы из help center и FAQ или подсказывает оператору варианты ответа и переводит реплики на язык клиента. Для контура без выхода данных наружу подключается локальная модель по OpenAI-совместимому API. Контрольный тест перед продом — 30–50 реальных вопросов с известными ответами; запуск на клиентов оправдан, когда «не знаю» уверенно преобладает над «уверенно ошибся».

Chatwoot не подходит для внутренней ITSM-поддержки, контрактов с SLA уровня «P1 — реакция 15 минут» и contact-центра с предиктивным набором. Это платформа живых разговоров, а не учёта инцидентов.

Подключение WhatsApp Business API через 360dialog и Cloud API, связка с Bitrix24 через вебхуки, мониторинг очередей Sidekiq в Zabbix и чек-лист от инженеров IT For Prof — в полном разборе

Frisbee: российский мессенджер держит 300 000 пользователей на одну инсталляцию и обрабатывает 100 000 сообщений в секунду

Компании, которые до 2022 года вели переписку в Telegram и Slack, всё чаще получают запрос от юридического отдела: нужен мессенджер из реестра российского ПО — этого требует 152-ФЗ и приказ по импортозамещению. Frisbee — собственная платформа разработчика KLAUD ATLAS с записью в реестре под номером 7378, публичным сайтом frisbee.chat и клиентами в RuStore и App Store.

По данным Frisbee, продукт получил TAdviser IT Prize 2026 и обслуживает около 1 млн корпоративных пользователей. Одна инсталляция рассчитана более чем на 300 000 пользователей, серверная часть держит 100 000 сообщений в секунду, а видеоконференции — более 1000 участников одновременно, с гостевым доступом по ссылке без регистрации.

✅ Что входит в платформу помимо чата:
• AI-ассистент ведёт протоколы видеовстреч и присылает отчёты прямо в общий чат
• FrisbeeTube — собственный видеохостинг для записей обучений и регламентов
• FrisbeeFlow — таск-менеджер без выгрузки задач в стороннюю систему
• SIP-телефония — звонок сотруднику или добавление в конференцию по номеру телефона

Поставка — по двум моделям: облачный SaaS или on-premise на сервере заказчика. On-premise закрывает требование «данные внутри периметра»: шифрование при хранении и передаче, удалённый выход из аккаунта и очистка данных с устройства при потере или увольнении. Публичного прайс-листа у Frisbee нет — и SaaS-пакеты, и on-premise считают индивидуально, под число пользователей, набор модулей и SIP.

🔧 В IT For Prof мы разбираем такие внедрения на практике: когда Frisbee выгоднее собственного сервера на Matrix, какие три вопроса задать вендору на пресейле и по какому критерию оценивать переход с Telegram, Slack или Teams без потери истории переписки.

Критерии выбора между Frisbee и open-source, чек-лист миграции с Telegram без потери истории переписки и три вопроса вендору на пресейле — как выбрать и внедрить без ошибок

🔒 WireGuard на уровне протокола не знает ни логинов, ни паролей — только пары публичных ключей. При штате 80+ человек это превращает увольнение в квест «найти, какой ключ чей», а туннель уволенного отвечает ещё долго после того, как ему закрыли почту.

Разрыв закрывает wg-portal с LDAP-провайдером: доменная учётка становится единственным источником истины, а VPN синхронизируется следом по расписанию. Заводить и блокировать людей вы продолжаете в оснастке AD, портал перечитывает конфиг WireGuard сам.

Механика отзыва спрятана в LDAP-фильтре (!userAccountControl:1.2.840.113556.1.4.803:=2) — это битовая проверка флага ADS_UF_ACCOUNTDISABLE. Отключили учётку в AD → пользователь перестаёт проходить фильтр → на следующем цикле sync_interval (по умолчанию 15 минут, на чувствительных контурах снижаем до 5) пир уходит в disabled. Для мгновенного отзыва — ручная деактивация в интерфейсе портала, разрывает активные сессии сразу.

Сегментация сети — через interface_filter: группа VPNUsers пускается в wg0 (офисная подсеть), Contractors — в изолированный wg1 (только таск-трекер и один RDP). Пользователь в обеих группах получает два пира, портал их не «схлопывает».

Windows Server 2025 включает LDAP signing по умолчанию — простой bind на 389 без шифрования контроллер отклонит. Нужен STARTTLS на 389 или LDAPS на 636, сертификат CA должен лежать в доверенном store сервера с wg-portal.

⚡ Второй фактор на LDAP не навешивается — только через OIDC-прокладку (Keycloak или Authentik), которая федерирует ту же AD и требует TOTP/WebAuthn поверх пароля. В IT For Prof включаем 2FA точечно на группе wg-critical для доступа к финансовым системам, обычные сотрудники ходят в офисный сегмент по доменному паролю.

Разбор field_map, типовые ошибки bind и чтение логов при no entries returned — в полном разборе

🔧 Cisco приостановила бизнес в РФ ещё в 2022 году: продлить лицензии AnyConnect легально нельзя, обновлений безопасности для ASA/FTD нет, замены железа по гарантии тоже. AnyConnect работает по инерции — пока не кончилась лицензия и не сломался шлюз.

WireGuard закрывает разрыв как открытый протокол без лицензий на пользователя: число пиров ограничено только ресурсами сервера. Для СМБ без ГОСТ-обязательств это прямая замена — доступ к 1С, RDP и файловым по привычному сценарию «запустил клиент — попал в корпоративную сеть».

Ключевой принцип миграции — параллельная работа двух VPN, а не «выключили в пятницу, включили в понедельник». WireGuard поднимается на отдельном сервере, слушает свой UDP (обычно 51820) и не мешает ASA. Пилот — ИТ-отдел на неделю, потом волны по группам доступа: сначала простые политики (одна подсеть), в конце — финансы и дежурная смена. ASA держат ещё две недели в горячем резерве после последнего подключения — за это время всплывают подрядчики раз в квартал и скрипты, ходящие через VPN как транспорт.

Политики переносятся не буквально. Split-tunnel ACL из group-policy превращается в AllowedIPs на пирах, а L4-фильтрация — в nftables на сервере. Десятки индивидуальных политик ASA сводятся к 3–5 интерфейсам wg-portal с маппингом на группы Active Directory: wg-office, wg-finance, wg-devops, wg-contractors.

Постуре-контроль (проверка антивируса, домена, версии ОС) чистый WireGuard не воспроизводит — это архитектурное отличие, а не пробел настройки. Компенсация: OIDC перед wg-portal или MDM.

📊 Честная граница: банкам, госорганам, операторам КИИ и медицине с ЕГИСЗ WireGuard юридически не подходит — там нужен сертифицированный ГОСТ-шлюз (С-Терра, ViPNet, «Континент»). Никакой аудит открытого кода сертификат ФСБ/ФСТЭК не заменит.

Порядок волн, шаблоны peer-конфигов и разбор трёх граблей маршрутизации DNS/split-tunnel — в полном разборе от IT For Prof.

🔒 Отзыв VPN у уволенного: одна блокировка в AD вместо отдельного пункта в чек-листе

WireGuard проверяет только пару ключей — слова «пользователь» и «уволен» для протокола ничего не значат. Пока публичный ключ бывшего сотрудника лежит в конфиге сервера, туннель поднимается, а файловый сервер и 1С отвечают ему так же, как вчера.

Ручная модель — гонка со временем. Аккаунт в AD закрыли за минуту, а VPN живёт своей жизнью: вспомнить, какой из десятков пиров чей, удалить строку, перезапустить сервис. На одном контуре пир уволенного разработчика висел в конфиге несколько дней — задачу поставили не тому админу, а VPN оставался вне общего чек-листа offboarding.

Связка wg-portal + LDAP-синхронизация убирает ручной шаг. В фильтрах login_filter и sync_filter прописано условие (!userAccountControl:1.2.840.113556.1.4.803:=2) — бит ADS_UF_ACCOUNTDISABLE атрибута userAccountControl. Кадровик жмёт Disable Account в оснастке домена, на следующем цикле портал переводит пир в disabled и снимает его с интерфейса. По умолчанию sync_interval = 15 минут, на контурах с чувствительными данными снижаем до 5.

✅ Ключевые детали механики:
• Флаг disable_missing: true закрывает сценарий с полным удалением учётки или переносом в архивный OU за пределы base_dn — пир снимается и без Disable Account
• Конфликтное увольнение — ручной kick через веб-интерфейс портала, активная сессия обрывается сразу, цикла ждать не нужно
• Ротация preshared key — только для админов инфраструктуры и доступа в PCI-сегмент: обесценивает старый клиентский конфиг целиком, даже если копия осела на личном ноутбуке
• Доказательство отзыва для проверки: поле latest handshake в выводе wg show wg0 dump + журнал портала с log_user_info: true

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

Так VPN, почта, RDP и корпоративный мессенджер отзываются каскадом за одну операцию в AD. В IT For Prof схема отработана на контурах от 80+ сотрудников: блокировка учётки → снятие пира в течение цикла → запись в журнале для аудита.

Конфиг LDAP-фильтров, схема разнесения групп AD по WireGuard-интерфейсам и разбор доказательной базы через latest handshake — в полном разборе

🔧 Self-hosted мессенджер в реестре отечественного ПО — только один из четырёх зрелых

Из рабочего шорт-листа для развёртывания на своём сервере — Rocket.Chat, Element/Matrix, Nextcloud Talk и Frisbee — в реестре Минцифры значится только Frisbee. Остальные три технически сильнее, но для госзаказчика и получателей бюджета мимо: обоснование отсутствия аналогов по мессенджерам не проходит.

Реестр — это не аудит безопасности, а юридический фильтр: льготы по НДС вендору и преимущество в закупках по 44-ФЗ и 223-ФЗ. У IT For Prof был кейс, где «шифрование переписки» в реестровом продукте на деле означало TLS до сервера и открытый текст в базе. Технический аудит проводим отдельно.

Выбор между остальными тремя сводится к архитектуре, а не к «удобству интерфейса»:

• Rocket.Chat — моно-сервер, один периметр, официальный Helm chart для Kubernetes и штатный air-gapped-режим. Ставим малым командам на Docker Compose и когда важен полный контроль данных внутри контура.
• Element на Synapse — федеративный протокол Matrix: домены обмениваются сообщениями как SMTP-серверы. E2EE в приватных комнатах по умолчанию, звонки через Element Call на LiveKit. Берём, когда переписка идёт с десятком внешних подрядчиков без заведения им учёток.
• Nextcloud Talk — модуль поверх Nextcloud. Оправдан только там, где файловое хранилище Nextcloud уже развёрнуто: одна база LDAP/AD, один бэкап. Для промышленных звонков обязателен High-Performance Backend.

Наличие в реестре и «безопасно» — не синонимы. Реестр не проверяет ни архитектуру, ни E2EE, ни устойчивость к утечкам.

Отдельно про MeetVap, о котором уже спрашивают: 28 звёзд, 16 коммитов, ни одного релиза, вендор — частный разработчик из Турции. Следить — да, внедрять — нет. И не повторяйте нашу ошибку: миграция Rocket.Chat с управляемого облака вендора в свой контур на другой версии ушла в неделю простоя с ручным восстановлением из бэкапа MongoDB. Либо сразу on-premise, либо сразу облако с SLA.

Матрица выбора под размер команды, требования к E2EE и федерации + разбор архитектурной разницы Matrix vs моно-сервер — в полном разборе