15023 Windows Server, AD и Роли

Event ID 15023 HTTP.sys: Ошибка безопасности создания конечной точки

Обновлено: 15.08.2026 · Официальная документация ↗

Архитектура ядра HTTP.sys и модель прав URLACL

Событие 15023 логируется в системном журнале System источником HttpEvent. Сообщение: "Создание конечной точки безопасности завершилось с ошибкой. Группа безопасности или учетная запись не имеет прав на регистрацию префикса URL (The security group or account does not have permission for the endpoint)". Драйвер режима ядра HTTP.sys отвечает за диспетчеризацию веб-запросов. Чтобы сервис (например, служба WCF, ADFS, WinRM или кастомное приложение) мог слушать определенный URL и порт, учетная запись этого сервиса должна быть явно зарегистрирована в списке управления доступом URL (URL Reservations / URLACL).

Симптомы сбоя:

Службы на базе .NET / WCF или микросервисы не запускаются, выдавая исключение AddressAccessDeniedException.
Веб-сайты IIS или виртуальные каталоги возвращают ошибку 500.19 или 503 Service Unavailable.
Служба удаленного управления Windows (WinRM / PowerShell Remoting) отказывается принимать подключения по HTTPS (порт 5986).

Пошаговое делегирование прав на URL в HTTP.sys

Сценарий 1: Просмотр текущих регистраций URLACL

Проверьте, какая учетная запись зарегистрирована для конфликтующего префикса URL.

# Просмотр всех зарегистрированных URL-префиксов в HTTP.sys
netsh http show urlacl

# Фильтрация по конкретному порту (например, 8080 или 443)
netsh http show urlacl | findstr :8080

Сценарий 2: Выдача прав учетной записи сервиса на URL-префикс

Если сервису, работающему от непривилегированной учетной записи (или Service Account), требуется занять порт:

Откройте командную строку от имени Администратора.

Выполните резервирование URL-пространства:

# Резервирование URL для доменной сервисной учетной записи
netsh http add urlacl url=http://+:8080/MyCustomService/ user="CORP\svc_app"

Перезапустите целевую службу приложения.

Сценарий 3: Удаление некорректных или устаревших резерваций

Если старая программа оставила за собой заблокированный URL-префикс:

# Удаление блокирующей резервации из ядра HTTP.sys
netsh http delete urlacl url=http://+:8080/MyCustomService/

Типовые ошибки администраторов

Попытка запустить службу от LocalSystem ради обхода ошибки: Повышение прав службы до SYSTEM скрывает ошибку прав URLACL, но создает критическую брешь в безопасности сервера. Всегда делегируйте конкретные URL-пространства через netsh http add urlacl.

Веб-сервисы и API падают с ошибками доступа к сетевым портам?
Конфликты HTTP.sys и привязок SSL-сертификатов приводят к простоям корпоративных порталов. Передайте сопровождение веб-инфраструктуры в ITSTM: настроим правильную маршрутизацию, сертификаты и права доступа.

💡 Практика специалистов: При развертывании приложений .NET Core / Kestrel за пределами IIS на Windows Server рекомендуется запускать их за обратным прокси-сервером (Reverse Proxy) или регистрировать точные URLACL префиксы, избегая использования широких масок (+:80/), конфликтующих с системными сервисами.

Частые вопросы (FAQ)

В чем разница между символами '+' и '*' в URL-префиксах HTTP.sys?

Символ '+' (Strong Wildcard) заставляет HTTP.sys перехватывать запросы на всех IP-адресах хоста для данного порта, имея наивысший приоритет. Символ '*' (Weak Wildcard) перехватывает трафик только в том случае, если нет более точного совпадения по IP или хосту.

Требуется ли перезагрузка сервера после изменения netsh http add urlacl?

Нет. Изменения в списках управления доступом URLACL применяются драйвером HTTP.sys мгновенно на лету.

Какая учетная запись по умолчанию имеет право регистрировать любые URL?

Учетная запись NT AUTHORITY\SYSTEM и члены локальной группы 'Администраторы' (Builtin\Administrators) имеют безусловное право на привязку к любым свободным URL без предварительной настройки urlacl.

Связана ли эта ошибка с привязкой SSL-сертификатов?

Косвенно — да. Для HTTPS-трафика помимо прав на URL (urlacl) требуется привязка SSL-сертификата к порту через команду netsh http add sslcert.