Подробный гайд по CredSSP: настройка, безопасность и проблема Double Hop в Windows

CredSSP — протокол безопасности Windows для решения проблемы двойного прыжка. Позволяет делегировать учетные данные, но требует осторожности из-за рисков компрометации.

2026.06.27 #Windows #PowerShell #Безопасность #администрирование #ActiveDirectory #сети #IT #sysadmin

Подробный гайд по CredSSP: настройка, безопасность и проблема Double Hop в Windows Подробный технический гайд по CredSSP (Credential Security Support Provider). Это мощный, но требующий осторожности инструмент в экосистеме Windows, который решает специфические проблемы аутентификации, но при неправильном использовании может стать серьезной уязвимостью.

1. Что такое CredSSP?

CredSSP (Credential Security Support Provider) — это провайдер поддержки безопасности в Windows, который позволяет приложению делегировать учетные данные пользователя (например, пароль или его хэш) от клиента к целевому серверу.

Изначально он разрабатывался для использования в RDP (Remote Desktop Protocol) и WinRM (PowerShell Remoting).

Главная цель CredSSP — решить проблему, известную в среде Windows-администраторов как "Double Hop" (Двойной прыжок).

2. Проблема "Двойного прыжка" (Double Hop)

Чтобы понять, зачем нужен CredSSP, нужно понять, как работает стандартная аутентификация Windows (NTLM и Kerberos).

Сценарий:

Вы (Клиент) подключаетесь по PowerShell Remoting (WinRM) к Серверу А, чтобы выполнить скрипт, который, в свою очередь, должен получить данные с Сервера Б (например, обратиться к файловому шару \\ServerB\Share или к SQL-базе).

Hop 1 (Клиент -> Сервер А):

Вы успешно аутентифицируетесь. Сервер А понимает, кто вы.

Hop 2 (Сервер А -> Сервер Б):

Скрипт на Сервере А пытается обратиться к Серверу Б от вашего имени. Здесь возникает проблема.

По соображениям безопасности Windows запрещает передавать ваши учетные данные дальше (с Сервера А на Сервер Б). Сервер Б видит анонимный токен или отклоняет запрос, потому что Сервер А не имеет права делегировать ваши права (если не настроено специальное делегирование Kerberos).

Решение через CredSSP:

CredSSP позволяет клиенту явно сказать: "Я доверяю Серверу А, вот мои учетные данные, используй их для подключения к Серверу Б".

3. Как работает CredSSP (Архитектура и поток)

Процесс аутентификации с использованием CredSSP выглядит следующим образом:

Инициация: Клиент инициирует подключение к Серверу А (например, через WinRM) и предлагает использовать CredSSP.
Создание защищенного канала: Сервер А и Клиент согласовывают использование TLS/SSL для шифрования канала связи.
Передача учетных данных: Клиент шифрует свои учетные данные (фактически, хэши паролей NTLM/Kerberos) с помощью публичного ключа Сервера А и отправляет их по защищенному TLS-каналу.
Расшифровка и использование: Сервер А расшифровывает учетные данные. Теперь у него есть ваши "чистые" учетные данные.
Двойной прыжок: Сервер А использует эти учетные данные для аутентификации на Сервере Б.

4. Пошаговая настройка CredSSP

Для работы CredSSP его необходимо включить и на клиенте, и на сервере.

Шаг 1: Настройка Клиента

Откройте PowerShell от имени администратора на клиентской машине:

# Включаем CredSSP для роли клиента. 
# Указываем FQDN сервера (или маску *.domain.com), которому мы доверяем делегирование.
Enable-WSManCredSSP -Role Client -DelegateComputer "ServerA.domain.com"

Примечание:

Если нужно разрешить делегирование на несколько серверов, их можно перечислить через запятую или использовать wildcard.

Шаг 2: Настройка Сервера (Сервер А)

Откройте PowerShell от имени администратора на Сервере А:

# Включаем CredSSP для роли сервера
Enable-WSManCredSSP -Role Server

Шаг 3: Настройка через Групповые политики (GPO)

Если вы не хотите настраивать каждый сервер вручную, используйте GPO.

Для Клиентов: `Computer Configuration -> Administrative Templates -> System -> Credentials Delegation`

Allow delegating fresh credentials (Разрешить делегирование новых учетных данных): Включено.
Добавьте серверы в список (например, wsman/ServerA.domain.com или wsman/*.domain.com).
Аналогично настройте "Allow delegating fresh credentials with NTLM-only server authentication", если используется NTLM.

Для Серверов: `Computer Configuration -> Administrative Templates -> System -> Credentials Delegation`

Allow delegating fresh credentials (или аналогичные политики для NTLM/Kerberos): Убедитесь, что сервер не заблокирован политиками.
Также убедитесь, что служба WinRM настроена на прослушивание и разрешены делегирования.

Шаг 4: Подключение с использованием CredSSP

Теперь вы можете подключиться к Серверу А, используя CredSSP:

# Явно указываем использование CredSSP
Enter-PSSession -ComputerName ServerA.domain.com -Authentication CredSSP -Credential domain\username

5. Безопасность и CVE-2018-0886 (Критически важно!)

Это самая важная часть гайда. CredSSP часто называют "необходимым злом", и вот почему:

Уязвимость архитектуры

Когда вы используете CredSSP, вы фактически передаете свой пароль (или его легко обратимый хэш) на Сервер А.

Если Сервер А скомпрометирован, злоумышленник может извлечь ваши учетные данные из памяти (LSASS) и использовать их для доступа ко всем ресурсам, к которым у вас есть доступ (включая Сервер Б и контроллеры домена, если вы администратор).
Вы должны доверять Серверу А так же, как вы доверяете своему локальному компьютеру.

CVE-2018-0886 (Remote Code Execution)

В 2018 году в CredSSP была найдена критическая уязвимость. Злоумышленник, находящийся в той же сети (Man-in-the-Middle), мог перехватить трафик и выполнить произвольный код на клиентской или серверной машине без какой-либо аутентификации.

Митигация (Защита от уязвимости шифрования):

Microsoft выпустила исправления (KB4088787 и др.) и внедрила настройку групповой политики Encryption Oracle Remediation (Защита от уязвимостей шифрования).

`Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation`

Protected (Защищено): Клиент будет отказываться подключаться к серверам, на которых не установлено обновление безопасности. (Рекомендуемое значение).
Force Updated Clients: Клиент будет подключаться только к полностью пропатченным серверам.
Vulnerable (Уязвимо): Отключает защиту (использовать только для совместимости со старыми системами).

Важно:

Если клиент пропатчен и настроен на "Protected", а сервер нет, вы получите ошибку подключения.

6. Альтернативы CredSSP (Best Practices)

Из-за рисков, связанных с передачей учетных данных, в корпоративных средах не рекомендуется использовать CredSSP, если есть альтернативы.

1. Kerberos Constrained Delegation (KCD) / Ограниченное делегирование Kerberos:

Позволяет настроить в Active Directory, что Сервер А может делегировать права пользователя только на конкретные службы Сервера Б. Учетные данные не передаются в открытом виде, используется безопасный механизм Kerberos S4U2Self.

2. Resource-Based Constrained Delegation (RBCD) / Делегирование на основе ресурсов:

Более современная и гибкая версия KCD. Настраивается не на объекте Сервера А, а на объекте Сервера Б (Сервер Б сам решает, кому разрешено делегировать к нему права). Это золотой стандарт для решения проблемы Double Hop.

3. Just Enough Administration (JEA):

Если вам нужен PowerShell Remoting, настройте JEA. Это позволит пользователям выполнять только строго определенные команды на Сервере А от имени виртуальной учетной записи, минуя необходимость делегирования их личных прав на Сервер Б.

4. Использование SSH / OpenSSH for Windows:

Если задача кроссплатформенная или не требует глубокой интеграции с AD, SSH использует свои механизмы передачи ключей и не страдает от проблемы Double Hop в том же виде.

7. Типичные ошибки и траблшутинг

Ошибка 1: "The WinRM client cannot process the request. CredSSP authentication is currently disabled..."

Причина: CredSSP не включен на клиенте или сервере, либо не настроены GPO.
Решение: Проверьте Enable-WSManCredSSP и настройки Allow delegating fresh credentials в GPO. Выполните gpupdate /force.

Ошибка 2: "An authentication error has occurred. The function requested is not supported. Remote Desktop could not connect to the remote computer..." (или аналогичная ошибка при использовании WinRM).

Причина: Рассинхронизация патчей безопасности (CVE-2018-0886). Клиент пропатчен и требует защищенного соединения, а сервер — нет (или наоборот).
Решение: Установите последние обновления Windows на обе машины. Если сервер нельзя обновить (Legacy), временно понизьте уровень защиты в GPO Encryption Oracle Remediation до Vulnerable (но осознавайте риски!).

Ошибка 3: "Access is denied" при попытке обратиться к ресурсу Сервера Б из сессии CredSSP.

Причина: Учетная запись не имеет прав на Сервере Б, либо в GPO на Сервере А запрещено делегирование для данной учетной записи.
Решение: Проверьте права на целевом ресурсе. Убедитесь, что в GPO DelegateComputer на клиенте указан правильный FQDN сервера А.

Важно

CredSSP — это отличный инструмент для быстрого решения проблемы "двойного прыжка" в сценариях PowerShell Remoting и RDP, особенно в небольших средах или при быстром прототипировании.

Однако в enterprise-средах его следует использовать только как крайнюю меру. Всегда отдавайте предпочтение Resource-Based Constrained Delegation (RBCD), так как оно решает ту же задачу, но делает это с использованием безопасного протокола Kerberos, не подвергая учетные данные пользователей риску компрометации на промежуточном сервере.

Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.

Статью подготовил: Денис Аверко @Nymexis г. Омск