Последние несколько лет Microsoft постепенно отказывается от NTLM в пользу решений на базе Kerberos. В следующих основных версиях клиентской и серверной Windows сетевая аутентификация NTLM будет отключена по умолчанию, а в пакете базовых параметров безопасности (security baseline) для Windows Server 2025 уже доступен аудит входящих подключений с использованием NTLM. Теперь компания представила набор изменений, которые ещё сильнее снижают зависимость от этого протокола.
В одной из ближайших сборок канала Experimental программы Windows Insider для клиентской и серверной Windows ряд сценариев, ранее требовавших NTLM, сможет использовать Kerberos через две новые возможности – IAKerb (Initial and Pass Through Authentication Using Kerberos) и LocalKDC (Local Key Distribution Center, локальный центр распределения ключей).
IAKerb: Kerberos без прямого доступа к контроллеру домена
IAKerb позволяет применять Kerberos в случаях, когда у клиента нет прямого доступа к контроллеру домена. Классическая аутентификация Kerberos требует прямой связи с контроллером домена, тогда как при использовании IAKerb роль посредника в обмене берёт на себя целевая служба.
Возможность полезна в корпоративных средах, где видимость контроллеров домена ограничена, либо где клиентские службы могут обращаться к целевым службам, но не к нужным контроллерам домена.
LocalKDC: Kerberos для локальных учётных записей
LocalKDC обеспечивает аутентификацию через Kerberos для сценариев с локальными учётными записями – вместо обращения к NTLM. Это особенно полезно на автономных устройствах, в средах рабочих групп и в других подобных конфигурациях, где раньше локальная аутентификация вынужденно откатывалась к NTLM.
Новые функции помогут отказаться от NTLM
Вместе IAKerb и LocalKDC сокращают зависимость от NTLM как в удалённых корпоративных сценариях, так и в локальных средах. Разработчики получают возможность опираться на современные механизмы аутентификации с предсказуемым и безопасным поведением, не прибегая к обходным решениям на уровне приложений.
Microsoft отмечает, что большинство организаций отказываются от NTLM из соображений безопасности, однако часть пользователей продолжает применять протокол для узких задач. IAKerb и LocalKDC призваны закрыть часть таких пробелов и помочь полностью отказаться от NTLM. При этом новые функции не устраняют все оставшиеся зависимости: отдельные сценарии по-прежнему могут требовать NTLM из-за поведения приложений, особенностей инфраструктуры или устаревших зависимостей.
Когда появятся новые функции и как их включить
Предварительная версия IAKerb и LocalKDC станет доступна в июне 2026 года в клиентских и серверных сборках канала Experimental программы Windows Insider. По умолчанию IAKerb включён, а LocalKDC отключён. В предварительной версии обе функции настраиваются только через реестр; управление через групповые политики и средства MDM Microsoft добавит позднее, по мере доработки функций.
Обе функции настраиваются параметрами реестра в ветке:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
За работу функций отвечают два параметра:
- DisableIAKerb – для IAKerb;
- DisableLocalKDC – для LocalKDC.
Значение 0 включает функцию, 1 – отключает. Если параметр в реестре отсутствует, применяется поведение по умолчанию для конкретной сборки: IAKerb включён (значение 0), LocalKDC отключён (значение 1). Подробности – в блоге Microsoft.
Что проверить во время тестирования
Microsoft рекомендует организациям, которые всё ещё используют NTLM, заранее проверить новые механизмы в контролируемой среде. Возможности закрывают значительную часть сценариев с откатом к NTLM, но не все: отдельные случаи по-прежнему могут требовать NTLM из-за поведения приложений, особенностей инфраструктуры или устаревших зависимостей.
Во время тестирования имеет смысл:
- определить сценарии, которые уже покрываются IAKerb или LocalKDC, и проверить их в контролируемой среде, управляя включением функций через параметры реестра;
- с помощью расширенного аудита NTLM понять, где зависимость от NTLM ещё сохраняется;
- проверить сопутствующие зависимости – разрешение имён, настройку SPN (Service Principal Name), устаревшие допущения в конфигурации.
Отдельно стоит проверить следующие сценарии:
- доступ к общим папкам SMB;
- удалённое администрирование;
- среды с ограниченным прямым доступом к контроллеру домена или без него;
- аутентификацию в рабочих группах и на автономных устройствах;
- доступ с использованием локальных учётных записей;
- конфигурации, которые готовятся к сокращению или блокировке NTLM.
Диагностика и обратная связь
Поскольку это предварительная версия, в части сценариев аутентификация всё ещё может откатываться к NTLM – например, из-за зависимостей конкретных приложений, ошибок в разрешении имён или настройке SPN, а также из-за взаимодействия доменных и локальных учётных записей на одном устройстве.
Отследить поведение помогают встроенные журналы. Журналы Kerberos позволяют убедиться, что используется именно Kerberos, увидеть участие IAKerb или LocalKDC и зафиксировать сбои и откаты. Операционные журналы NTLM показывают, когда и почему происходит обращение к NTLM, и помогают расставить приоритеты для дальнейшего разбора.
О нестандартном поведении или особых сценариях аутентификации Microsoft предлагает сообщать на ntlm@microsoft.com, указывая тестируемый сценарий, ожидаемый и фактический результат и, при наличии, записи из журналов событий.