Сертификат действителен, а домен не пускает: сильные привязки сертификатов после сентября 2025

Понедельник, половина ноутбуков не заходит в корпоративный Wi-Fi, у пользователей смарт-карт «неверное имя пользователя или пароль», а сертификаты — свежие, цепочка валидна, отзыв проверяется. В журнале System на контроллерах домена пачками сыпется событие 39 от Kdcsvc. Это не про срок действия и не про CRL: контроллер домена больше не принимает сертификат, который нельзя однозначно связать с учётной записью. Разбираю, что именно изменилось, как за час понять масштаб проблемы у себя, и как чинить — правильно (SID-расширение) и в обход (ручные привязки altSecurityIdentities), с командами и граблями.

Что именно перестало работать и когда

История тянется с мая 2022 года. Обновление KB5014754 закрыло дыру в том, как контроллер домена сопоставляет предъявленный сертификат с учётной записью: раньше хватало совпадения по имени субъекта, по UPN в SAN или по адресу электронной почты. Всё это подделывается тем, кто может влиять на выпуск сертификатов или на атрибуты объекта в каталоге. Microsoft ввела понятие сильной привязки: либо в самом сертификате лежит SID учётной записи (расширение с OID 1.3.6.1.4.1.311.25.2), либо администратор явно прописал сильную привязку в атрибуте altSecurityIdentities.

Переход шёл фазами. С мая 2022 — режим совместимости с аудитом, ключ реестра HKLM\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement со значениями 0 (проверка выключена), 1 (проверять, но пропускать при отсутствии сильной привязки) и 2 (запрещать). С 11 апреля 2023 значение 0 перестало действовать: режим Disabled KDC игнорирует. 11 февраля 2025 контроллеры домена по умолчанию переехали в полное принуждение — но откатиться значением 1 всё ещё было можно. А 9 сентября 2025 года ключ StrongCertificateBindingEnforcement перестал поддерживаться вовсе. Он остаётся в реестре, его можно менять, KDC его просто игнорирует.

Отсюда и вся путаница на местах. Админ помнит, что «мы это чинили реестром», лезет проверять — ключ на месте, значение 1, всё как оставили в 2024-м. А аутентификация не проходит. Никакой ошибки, никакого предупреждения о том, что параметр устарел, система не выдаёт. Ключ мёртв, и обратной дороги нет: единственный способ вернуть работоспособность — привести сертификаты и привязки в порядок. Удалять сентябрьские обновления с контроллеров ради этого — плохая идея, вы откатите заодно и патчи безопасности за год.

• 10 мая 2022 — KB5014754, режим совместимости, начало аудита, Enterprise CA начинает класть SID в сертификаты по онлайн-шаблонам
• 11 апреля 2023 — фаза включения, значение 0 (Disabled) игнорируется
• 13 февраля 2024 — оснастка ADUC в RSAT по умолчанию создаёт сильную привязку X509IssuerSerialNumber вместо слабой X509IssuerSubject
• 11 февраля 2025 — по умолчанию полное принуждение, откат ключом ещё возможен
• 9 сентября 2025 — ключ StrongCertificateBindingEnforcement больше не поддерживается, слабые сопоставления не работают

Читаем журнал: события 39, 40 и 41 — это три разные болезни

Все три события пишутся в журнал System контроллера домена источником Kdcsvc, и их постоянно путают, потому что текст похож. Событие 39 — «сертификат валиден, но не удалось сильно сопоставить его с пользователем». Это классика: нет ни SID-расширения, ни сильной ручной привязки. Событие 40 — то же самое плюс уточнение: сертификат выпущен раньше, чем создана учётная запись, поэтому даже слабое сопоставление отвергнуто. Событие 41 — самое коварное: SID в сертификате есть, но он не совпадает с SID учётной записи, к которой сертификат сопоставился.

Лечатся они по-разному. 39 — либо перевыпуск с SID, либо ручная привязка. 40 — обычно упирается в пересозданную учётку или в клонированную машину, и правильный ответ тоже перевыпуск; ключ CertificateBackdatingCompensation (тот же раздел реестра Kdc, значение в секундах: 0x1E13380 — год, 0x12CC0300 — десять лет) раньше сдвигал окно допустимого «опережения», но работал только для слабых сопоставлений, а их после сентябрьских обновлений 2025 года KDC не поддерживает. Рассчитывать на него как на костыль сейчас нельзя. 41 — почти всегда пересозданный объект в AD: учётку компьютера удалили и завели заново, или пользователя восстановили из корзины не тем способом, SID сменился, а сертификат остался старый.

Собирать эти события надо не с одного DC, а со всех и за длинный период — трафик аутентификации по сертификатам обычно неравномерный, редкие сценарии (подрядчик раз в квартал, VPN у директора) вылезут только на горизонте месяца. Я снимаю выгрузку так:

$dcs = (Get-ADDomainController -Filter *).HostName
Invoke-Command -ComputerName $dcs -ScriptBlock {
  Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 39,40,41
    StartTime = (Get-Date).AddDays(-30)
  } -ErrorAction SilentlyContinue |
  Where-Object { $_.ProviderName -match 'Kerberos-Key-Distribution-Center|Kdcsvc' } |
  Select-Object @{n='DC';e={$env:COMPUTERNAME}}, TimeCreated, Id, Message
} | Export-Csv C:\temp\kdc_weak_mapping.csv -NoTypeInformation -Encoding UTF8

Скрипт идёт по всем контроллерам через WinRM и складывает события в один CSV с именем DC. Если какой-то контроллер не ответил, Invoke-Command напишет ошибку, но выгрузку по остальным не прервёт — просто перезапустите для него отдельно. Дальше CSV открывается в Excel, и сводная таблица по полю Id и по имени субъекта из текста сообщения сразу показывает, кого затронуло.

• 39 — нет сильной привязки вообще: перевыпуск с SID или ручная привязка в altSecurityIdentities
• 40 — сертификат старше учётной записи: перевыпуск сертификата или разбор, почему учётка пересоздана
• 41 — SID в сертификате не тот: искать пересозданный объект AD или клон, перевыпускать обязательно
• Пусто в журналах — не повод расслабляться: проверьте, что аутентификация по сертификатам у вас вообще происходит и что аудит не отключён политикой

Разбор из практики: оптовый склад сантехники на 38 рабочих мест

Клиент — оптовый поставщик сантехники «Аквалайн-Опт», 38 рабочих мест: офис продаж, бухгалтерия и склад с отгрузкой. Два контроллера домена на Windows Server 2022, издающий Enterprise CA на отдельной виртуалке с Windows Server 2019, корневой CA выключен и хранится офлайн. Корпоративный Wi-Fi — 802.1X EAP-TLS через NPS, сертификаты компьютеров из собственного шаблона, всего 44 устройства: ноутбуки менеджеров, офисные ПК и шесть складских планшетов на Windows, через которые кладовщики собирают заказы. Плюс четыре пользователя со смарт-картами для доступа к серверу 1С и VPN на сертификатах у разъездных менеджеров.

Обновления на контроллеры приехали в пятницу вечером в плановое окно. В понедельник к десяти утра у меня было 14 обращений «не подключается Wi-Fi», к обеду — 21, то есть почти весь беспроводной парк. Смарт-карты не работали ни у кого. При этом проводные ПК, RDP, файловые шары — всё живо, потому что там обычный Kerberos с паролями. На обоих DC в System за утро накопилось около семисот событий 39. Ключ StrongCertificateBindingEnforcement на обоих стоял в 1 — его выставили в феврале 2025, когда «всё вдруг перестало пускать», и благополучно забыли.

Выгрузили сертификат компьютера с любого ноутбука и посмотрели, что внутри. SID-расширения нет. Полезли в шаблон — и там нашлось объяснение: в msPKI-Enrollment-Flag стоял бит 0x00080000, CT_FLAG_NO_SECURITY_EXTENSION. То есть галка «не включать ntdsCASecurityExt» в свойствах шаблона. Её кто-то поставил ещё в 2022 году, когда после майского обновления посыпались непонятные ошибки и на форуме посоветовали «выключить это новое расширение». Совет продержался три года и положил склад на четвёртый.

Дальше было просто. Сняли флаг с шаблона, подняли минорную версию, разослали gpupdate /force и certutil -pulse через удалённое выполнение. За три часа автоперевыпуск обновил 39 устройств из 44, пять ноутбуков менеджеров, которые были в разъездах, доехали в течение недели. Сертификаты для смарт-карт перевыпустили руками — их всего четыре. Отдельно остался внешний программист 1С, чей сертификат выпускает партнёрский CA, к которому у нас нет доступа: ему сделали ручную привязку X509IssuerSerialNumber. Итого около пяти часов работы на весь инцидент, из которых три — ожидание автоперевыпуска. Реальная стоимость проблемы — полдня остановленной отгрузки: складские планшеты сидят на том же Wi-Fi, и сборка заказов шла на бумаге.

• Проверить сертификат на наличие SID: `certutil -dump -v C:\temp\user.cer | findstr /i "1.3.6.1.4.1.311.25.2 NTDS"`
• Проверить флаг шаблона: `certutil -v -dstemplate ИмяШаблона | findstr /i "msPKI-Enrollment-Flag"`
• Снять флаг подавления SID: `certutil -dstemplate ИмяШаблона msPKI-Enrollment-Flag -0x00080000`
• Массово проверить машинные сертификаты скриптом по Cert:\LocalMachine\My
• После правки шаблона — `gpupdate /force` и `certutil -pulse` на клиенте, иначе автоперевыпуск ждёт своего цикла

Правильный путь: SID внутрь сертификата

Обновлённый Enterprise CA по умолчанию сам добавляет расширение с OID 1.3.6.1.4.1.311.25.2 в сертификаты, выпущенные по онлайн-шаблонам — то есть по тем, где субъект строится из Active Directory, а не задаётся в запросе. Это и есть штатный механизм. Никаких настроек на CA для этого не требуется, требуется лишь не мешать: не ставить в шаблоне флаг подавления расширения и не переводить шаблон в режим «subject supplied in request», где CA не знает, чей это будет сертификат.

Ключевой момент, который стоит проговорить руководству: ранее выданные сертификаты расширение не получат никогда. Оно кладётся в момент выпуска. Значит, любая миграция на сильные привязки — это волна перевыпуска всего парка. Для машинных и пользовательских сертификатов, раздаваемых автоенроллментом, это делается почти бесплатно: правите шаблон, поднимаете версию, ждёте цикл. Для сертификатов на токенах и смарт-картах — это личная встреча с каждым владельцем. Планируйте по календарю, а не «за вечер».

Отдельная история — устройства под управлением Intune и SCEP. Если сертификаты раздаются через Intune и NDES, SID сам собой не появится: его надо явно попросить, добавив в SCEP-профиле в Subject Alternative Name атрибут URI со значением {{OnPremisesSecurityIdentifier}}. Intune подставит строку вида tag:microsoft.com,2022-09-14:sid:<значение>. По документации Microsoft переменная работает только с атрибутом URI и для сертификатов устройств — только для гибридно присоединённых к Microsoft Entra машин; у чисто облачных устройств локального SID нет вовсе. Для PKCS-профилей нужен обновлённый Intune Certificate Connector. Центр сертификации должен принять такой URI в SAN — службы сертификации Windows с актуальными обновлениями это умеют, сторонние CA проверяйте до раскатки.

Мой приоритет такой: сначала машинные сертификаты (они держат Wi-Fi и NAC — это самый массовый простой), потом пользовательские для VPN, потом смарт-карты, потом всё остальное. И только после этого — разбор одиночных исключений вроде подрядчиков и сервисных учёток.

• Шаблон строит субъект из AD (не supplied in request) — обязательное условие для SID-расширения
• Снять CT_FLAG_NO_SECURITY_EXTENSION, поднять версию шаблона
• Убедиться, что CA обновлён — на неупакованном патчами CA расширения не будет
• SCEP/Intune: атрибут URI в SAN со значением {{OnPremisesSecurityIdentifier}}
• Перевыпуск: автоенроллмент для парка, ручной график для токенов

Ручные привязки altSecurityIdentities: три сильных типа и где режут пальцы

Когда SID в сертификат не вкрутить, остаётся многозначный атрибут altSecurityIdentities у объекта пользователя или компьютера. Из шести поддерживаемых форматов сильными считаются три: X509IssuerSerialNumber (издатель плюс серийный номер), X509SKI (идентификатор ключа субъекта) и X509SHA1PublicKey (хеш открытого ключа). Слабые — X509IssuerSubject, X509SubjectOnly и X509RFC822 (по адресу почты). После сентябрьских обновлений 2025 года слабые сопоставления не поддерживаются: KDC их не примет. Если у вас в каталоге лежат старые привязки вида X509:<I>...<S>... — они уже не работают, просто ещё не удалены.

Главная засада — формат X509IssuerSerialNumber. Серийный номер разворачивается по байтам: то, что certutil показывает как 2B0000000011AC0000000012, в атрибуте пишется как 1200000000AC11000000002B. Байты меняются местами целиком, полубайты внутри байта — нет. И второе, о чём забывают: имя издателя тоже пишется в обратном порядке RDN. В сертификате вы видите «CN=AQUALINE-Issuing-CA, DC=aqualine, DC=local», а в привязке должно быть DC=local,DC=aqualine,CN=AQUALINE-Issuing-CA — без пробелов после запятых. Одна лишняя пробельная позиция — и привязка молча не сработает, событие 39 продолжит идти.

Если у вас RSAT с февральскими обновлениями 2024 года и новее, проще не собирать строку руками, а открыть в ADUC свойства учётной записи, включить Advanced Features, зайти в Name Mappings и добавить сертификат файлом — оснастка сама создаст сильную привязку X509IssuerSerialNumber. Раньше она по умолчанию делала слабую X509IssuerSubject, поэтому все привязки, сделанные до 2024 года через эту же оснастку, надо перепроверить.

Ещё один практический совет: X509SKI обычно удобнее, чем серийный номер, если расширение Subject Key Identifier в сертификате есть — там нечего разворачивать, просто копируете шестнадцатеричное значение. А вот с X509SHA1PublicKey чаще всего ошибаются: туда идёт хеш открытого ключа, а не отпечаток сертификата. В выводе certutil -v -dump это строки Key Id Hash, а не Cert Hash; какой из вариантов хеша ждёт KDC, сверяйте с примером в KB5014754 на тестовой учётке. Взяли отпечаток — получили нерабочую привязку и полдня поисков.

Строку можно не собирать вручную, а получить из файла сертификата. Скрипт ниже разворачивает серийный номер по байтам, переворачивает порядок RDN издателя и дописывает значение в атрибут учётной записи. Перед записью выведите $alt на экран и сравните с сертификатом глазами — если в имени издателя есть запятые внутри значений (например, в O=), простое разбиение по запятой их сломает.

# сборка привязки X509IssuerSerialNumber из файла сертификата
$c  = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new('C:\temp\user.cer')
$sn = $c.SerialNumber -split '(..)' | Where-Object { $_ }
[array]::Reverse($sn)
$rdn = ($c.IssuerName.Name -split ',\s*'); [array]::Reverse($rdn)
$alt = 'X509:<I>' + ($rdn -join ',') + '<SR>' + ($sn -join '')
Set-ADUser -Identity a.petrov -Add @{ altSecurityIdentities = $alt }

После записи проверьте результат командой Get-ADUser a.petrov -Properties altSecurityIdentities и сразу прогоните реальный вход. Если событие 39 по этой учётке больше не появляется, привязка рабочая; если идёт дальше — почти всегда виноваты пробелы в имени издателя или неразвёрнутый серийный номер.

• Сильные: X509IssuerSerialNumber, X509SKI, X509SHA1PublicKey
• Слабые и с сентября 2025 нерабочие: X509IssuerSubject, X509SubjectOnly, X509RFC822
• Серийный номер — разворот по байтам; имя издателя — обратный порядок RDN, без пробелов
• X509SHA1PublicKey — хеш ключа (Key Id Hash), а не отпечаток сертификата (Cert Hash)
• Привязка по серийному номеру умирает при каждом перевыпуске сертификата — закладывайте регламент

Что делают не так из раза в раз

Первое и самое массовое — пытаются лечить симптом. Видят «сертификат отклонён», идут продлевать сертификат. Или заново публикуют CRL. Или чистят кэш Kerberos. Ни одно из этих действий не имеет отношения к причине. Второе по частоте — правят реестр по инструкции трёхлетней давности и удивляются, что не помогло. Это, к сожалению, ровно то, что выдают в первых строках поисковики: статей 2022–2024 годов в разы больше, чем актуальных.

Третье — массово прописывают привязки. Приходит идея: «раз перевыпуск долгий, давайте скриптом сделаем altSecurityIdentities для всех 44 машин». Технически сработает. Операционно — вы только что подписались обновлять привязки при каждом перевыпуске сертификата, то есть раз в год минимум, и любой ручной перевыпуск теперь ломает аутентификацию. Ручные привязки — это исключение на десяток объектов, а не режим эксплуатации парка.

Четвёртое, и это уже про безопасность: право на запись в altSecurityIdentities равносильно возможности войти в домен под чужой учётной записью — достаточно привязать к администратору домена сертификат, которым владеешь ты. Атака известна как ESC14. Не делегируйте этот атрибут хелпдеску «чтобы сами чинили», не включайте его в широкие делегирования на OU и заведите аудит изменений: одна строка в журнале, зато вы узнаете о попытке в тот же день.

И пятое — паника. Со стороны выглядит как обвал, но ломается только то, что аутентифицируется по сертификату: смарт-карты, 802.1X EAP-TLS, часть VPN, некоторые сценарии Windows Hello for Business. Обычный доменный вход по паролю, файловые шары, RDP, почта не затронуты вообще. Если у вас в организации сертификаты для входа нигде не используются — вас это изменение не касается, и тратить на него выходные не нужно. Проверить просто: если за месяц на контроллерах нет ни одного события 39/40/41, спите спокойно.

• Не продлевайте сертификат — это не про срок действия
• Не возвращайте StrongCertificateBindingEnforcement — ключ игнорируется
• Не откатывайте обновления контроллеров ради обхода
• Не делайте ручные привязки массово — только точечно
• Не делегируйте запись в altSecurityIdentities помимо администраторов домена

План работ: что делать в первую очередь

Порядок, который я использую у клиентов. День первый — разведка, без единого изменения. Собираете события 39, 40 и 41 со всех контроллеров за 30 дней, сводите в таблицу по типу события и по субъекту. Параллельно снимаете инвентаризацию: какие шаблоны сертификатов активны, у каких стоит бит 0x00080000, где субъект берётся из запроса, обновлён ли сам CA. Результат — список: сколько объектов затронуто, каких, и какой из трёх сценариев (39/40/41) у каждого.

День второй — правка шаблонов и пилот. Снимаете флаг подавления расширения, поднимаете версию шаблона, перевыпускаете сертификат на трёх-пяти тестовых машинах и одном пользователе, проверяете certutil -dump -v на наличие OID 1.3.6.1.4.1.311.25.2, прогоняете реальный сценарий — подключение к Wi-Fi, вход по смарт-карте, поднятие VPN. Только убедившись, что пилот зелёный, запускаете волну автоперевыпуска на весь парк. Держите под рукой список офлайн-устройств: ноутбуки в отпусках и склады с терминалами доедут не сразу.

День третий — хвосты и регламент. Ручные привязки для внешних сертификатов, разбор событий 41 (там почти всегда обнаруживается пересозданный объект AD, который заодно надо привести в порядок), удаление старых слабых привязок X509IssuerSubject из каталога — они больше не работают и только мешают разбираться. И финальный штрих, который экономит следующий инцидент: мониторинг. Один триггер на события 39/40/41 в системе мониторинга — и в следующий раз вы узнаете о проблеме за неделю до того, как она станет массовой, а не в понедельник от директора.

Отдельно про сроки. Если вы читаете это и у вас всё работает — не расслабляйтесь: работает, пока сертификаты выпущены после мая 2022 обновлённым CA и без флага подавления. Достаточно одного нового шаблона, скопированного со старого, или одного сертификата от стороннего CA — и вы получите ту же историю в миниатюре. Проверка шаблонов должна войти в регулярный аудит PKI наравне с проверкой сроков корневого сертификата.

• Разведка: события 39/40/41 за 30 дней со всех DC + инвентаризация шаблонов
• Правка шаблонов: снять 0x00080000, поднять версию, проверить, что субъект строится из AD
• Пилот на 3–5 объектах с реальным сценарием входа, потом волна автоперевыпуска
• Точечные ручные привязки для внешних CA, разбор событий 41
• Чистка старых слабых привязок и постановка мониторинга на события KDC

Частые вопросы