JumpServer RDP через Kerberos-аутентификацию
Применимая версия: JumpServer v4.10.x-ee (для других версий принцип
аналогичен, версии образов компонентов могут отличаться).
По состоянию на v4.10.16-lts только Razor (клиентский способ
подключения) может использовать Kerberos; lion (Web GUI) из-за
встроенного FreeRDP 2.x поддерживает только NTLM.
1. Область применения и цели
| Требования безопасности/соответствия |
Необходимо отказаться от NTLM/NTLMv1; RDP должен использовать
строгую Kerberos-аутентификацию |
| Среда AD-домена |
Управляемые Windows-серверы уже (или могут быть) включены в
домен Active Directory |
| Требования аудита |
Требуется доказуемая цепочка Kerberos-аутентификации (билеты
KDC) |
Сценарии, где Kerberos не применим/невозможен: целевой узел
находится в рабочей группе (нет домена/KDC), подключение
выполняется по IP, используется локальная учётная запись, либо
подключение идёт через lion (Web-терминал). В этих случаях возможен
только NTLM.
2. Принцип: как в RDP определяется Kerberos или
NTLM
NLA (Network Level
Authentication) в RDP работает через CredSSP, который внутри
использует SPNEGO для согласования Kerberos или NTLM.
Чтобы клиент мог использовать Kerberos, он должен суметь получить у
KDC сервисный билет TERMSRV/<FQDN> для целевого
узла; если получить билет не удаётся — происходит откат на
NTLM.
Критерий определения: в журнале безопасности целевого
Windows-сервера ищите событие 4624 / LogonType 3, поле
AuthenticationPackageName:
- Kerberos = аутентификация Kerberos прошла успешно
- NTLM = использован NTLM (поле
LmPackageName
дополнительно показывает NTLM V1/V2)
Примечание: значение Negotiate в записи с LogonType 10 — это лишь
метка «оболочки» сессии и не является достоверным показателем.
3. Предварительные условия (отсутствие любого из них
приводит к откату на NTLM или к сбою)
- Целевой Windows-сервер уже включён в домен AD (домен
предоставляет KDC и автоматически регистрирует для компьютера SPN
HOST/TERMSRV).
- Адрес актива в JumpServer указан как FQDN (например,
host.example.com), нельзя использовать IP (у IP нет
SPN → обязательно NTLM).
- Учётная запись подключения содержит домен/realm:
user@example.com (UPN, рекомендуется) или
DOMAIN\user. Одно лишь имя пользователя не позволяет
определить realm → NTLM.
- Подключение выполняется через Razor (клиент), а не через Lion
(Web GUI).
- Razor способен обнаружить KDC и подключиться к нему (см. раздел
5), порт KDC 88 (TCP+UDP) должен быть доступен.
- Расхождение часов между клиентом, KDC и целевым узлом < 5
минут.
4. Почему Lion не поддерживает Kerberos
Поддержка Kerberos зависит главным образом от встроенной версии
FreeRDP: FreeRDP 2.x поддерживает только NTLM, FreeRDP 3.x
поддерживает Kerberos.
В настоящее время Lion всё ещё использует FreeRDP 2.x, поэтому
Kerberos не поддерживается.
5. Реализация настройки Razor
Пусть домен — EXAMPLE.COM, DC/KDC — <KDC_IP>,
цель — host.example.com.
Пример значений: realm LAB.LOCAL, KDC 10.1.14.240, цель
win2019.lab.local.
5.1 Консоль JumpServer: создание актива и учётной записи
домена
Управление активами → Активы → Создать (Windows): в адресе указать
FQDN (host.example.com), протокол RDP/3389.
Учётная запись: имя пользователя user@example.com (или
EXAMPLE\user).
5.2 Как заставить Razor обнаружить KDC (один из двух
способов)
По умолчанию внутри контейнера Razor отсутствует файл krb5.conf, а
его DNS-запросы перенаправляются через встроенный DNS-резолвер
Docker на хост, из-за чего SRV-запись _kerberos AD не
разрешается. Поэтому по умолчанию KDC не обнаруживается, и
происходит тихий откат на NTLM. Необходимо восполнить это одним из
следующих способов.
Способ A (рекомендуется, ближе всего к реальному AD):
направить DNS Razor на DNS AD
Отредактируйте <каталог
установки>/compose/razor.yml, добавьте сервису razor
секцию dns::
services:
razor:
container_name: jms_razor
hostname: jms_razor
dns: # ← добавлено
- <KDC_IP> # DNS AD (обычно совпадает с DC), пример 10.1.14.240
...
Принцип: встроенный резолвер Docker (127.0.0.11) по-прежнему
разрешает имена контейнеров (razor как обычно находит core и другие
внутренние сервисы), но пересылает «не-контейнерные» запросы на DNS
AD; таким образом SRV-записи
_kerberos._udp/._tcp.EXAMPLE.COM успешно разрешаются →
FreeRDP3 автоматически обнаруживает KDC. Этот способ не требует
krb5.conf.
Условие: DNS AD содержит SRV-запись _kerberos и
настроен внешний форвардер (иначе razor не сможет разрешать имена
вне домена).
Способ B (локально управляемый): внедрение
krb5.conf
Поместите krb5.conf в постоянный путь на хосте (шаблон см. в
Приложении, ключевые параметры: dns_lookup_kdc=false +
kdc=<KDC_IP>):
cp krb5.conf /opt/jumpserver/krb5.conf
Отредактируйте <каталог
установки>/compose/razor.yml, добавьте в
volumes: сервиса razor:
volumes:
- ${VOLUME_DIR}/razor/data:/opt/razor/data
- ${CONFIG_DIR}/nginx/cert:/opt/razor/cert
- /opt/jumpserver/krb5.conf:/etc/krb5.conf:ro # ← добавлено
5.3 Требования к сети
Между хостом, на котором работает razor, и (DC/KDC) должны быть
разрешены TCP и UDP порт 88 (Kerberos обычно сначала использует
UDP, затем TCP).
Проверка (внутри контейнера razor):
docker exec jms_razor bash -c 'timeout 3 bash -c ">/dev/tcp/<KDC_IP>/88" && echo TCP88-OPEN'
6. Проверка
Подключитесь к активу по FQDN клиентским способом (используя
учётную запись домена).
На целевом Windows-сервере проверьте событие 4624:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddMinutes(-15)} |
ForEach-Object {
$x=[xml]$_.ToXml(); $d=@{}; $x.Event.EventData.Data | %{ $d[$_.Name]=$_.'#text' }
if ($d['LogonType'] -eq '3') {
[pscustomobject]@{Время=$_.TimeCreated; ПакетАутентификации=$d['AuthenticationPackageName']; Учётная_запись=$d['TargetUserName']; IP_источника=$d['IpAddress']}
}
} | Sort-Object Время -Descending | Format-Table -AutoSize
Если поле «Пакет аутентификации» = Kerberos, значит Kerberos
использован успешно.
7. Быстрый поиск и устранение неисправностей
| 4624 по-прежнему показывает NTLM |
Подключение выполнено через lion (Web); либо использован IP;
либо учётная запись без домена |
Использовать Razor + FQDN + user@realm |
| 4624 по-прежнему NTLM (Razor, FQDN и учётная запись домена —
всё верно) |
Razor не может найти KDC, происходит тихий откат |
Настроить способ A или B; убедиться, что порт 88 доступен |
В логах Razor: Cannot find KDC for realm |
Нет krb5.conf, и в DNS нет SRV-записи
_kerberos |
См. решение выше |
| KRB_AP_ERR_SKEW |
Расхождение часов > 5 минут |
Синхронизировать все узлы по NTP |
| Не удаётся разрешить цель/внешние адреса |
DNS Razor указывает на DNS AD, но у того нет внешнего
форвардера |
Настроить форвардер на DNS AD |
| Машины в рабочей группе всегда используют NTLM |
Нет домена/нет KDC |
Сначала необходимо включить машину в домен |
8. Важные замечания
«Подключение установлено» не равно «использован Kerberos»: при сбое
Kerberos razor тихо переключается на NTLM, и подключение всё равно
устанавливается. Единственный надёжный критерий — событие 4624 на
целевой машине.
Команда jmsctl upgrade перезаписывает файлы compose:
после обновления изменения в razor.yml (dns/volume) могут быть
утеряны, их нужно будет внести заново.
lion пока не поддерживает Kerberos: нужно дождаться будущих версий,
где guacd в lion, возможно, будет обновлён до FreeRDP 3.x
(Guacamole 1.6.0+).
Если требуется принудительно проверить использование Kerberos:
можно временно отключить NTLM в локальной политике целевой машины
(Сетевая безопасность: ограничить NTLM: входящий NTLM-трафик =
запретить всё); если подключение всё равно проходит успешно — это
доказывает, что использовался Kerberos. Обязательно сохраните
доступ через консоль/внеполосный канал, чтобы не заблокировать себе
доступ.
9. Настройка при использовании Windows Active Directory в
качестве контроллера домена (KDC)
Поскольку под рукой не оказалось подходящей машины с Windows
Server, здесь в качестве примера используется Samba AD DC,
работающий на Linux; если вы используете настоящий Windows Server
AD, принцип полностью аналогичен и даже проще — Windows AD уже
включает в себя KDC и интегрированный с AD DNS с SRV-записями,
поэтому Razor через способ A (DNS указывает на DNS AD), как
правило, сразу работает с Kerberos «из коробки», без необходимости
в krb5.conf. Ниже приведены основные моменты для стороны
Windows.
9.1 Сторона контроллера домена (KDC) — практически без
дополнительной настройки
Установите роль AD DS и повысьте сервер до контроллера домена
(через мастер, либо командой Install-ADDSForest -DomainName
example.com ...).
После повышения автоматически появляются: служба KDC (работает на
каждом DC), интегрированный с AD DNS с соответствующими
SRV-записями (_kerberos._tcp/._udp.example.com,
_ldap._tcp.dc._msdcs.example.com и т. д.).
В Windows нет понятия krb5.conf — клиент через SSPI и DNS AD
автоматически обнаруживает KDC.
В диспетчере DNS настройте на DC форвардеры (Forwarders), чтобы
члены домена/шлюзы могли разрешать имена вне домена.
9.2 Включение целевого Windows-сервера в домен (аналогично
сценарию с Samba)
# 1) Указать DNS-сервер AD для сетевого адаптера (контроллер домена)
Set-DnsClientServerAddress -InterfaceIndex <idx> -ServerAddresses <AD_DNS_IP>
# 2) Включить в домен и перезагрузить
Add-Computer -DomainName example.com -Credential (Get-Credential EXAMPLE\Administrator) -Restart
# 3) После перезагрузки: включить RDP + принудительный NLA, разрешить учётную запись
Set-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0
Set-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1
Enable-NetFirewallRule -DisplayGroup 'Remote Desktop'
Add-LocalGroupMember -Group 'Remote Desktop Users' -Member 'EXAMPLE\rdpuser'
Члены домена автоматически синхронизируют время с DC через службу
времени Windows, вручную обычно ничего делать не нужно (достаточно
обеспечить расхождение < 5 минут).
9.3 Создание учётной записи домена для
JumpServer
New-ADUser -Name rdpuser -UserPrincipalName rdpuser@example.com `
-AccountPassword (Read-Host -AsSecureString) -Enabled $true
В учётной записи актива JumpServer укажите
rdpuser@example.com (или
EXAMPLE\rdpuser).
9.4 SPN (обычно регистрировать вручную не
требуется)
Члены домена автоматически регистрируют
HOST/<host>,
HOST/<host>.example.com; KDC Windows по
умолчанию сопоставляет TERMSRV с HOST, поэтому билет
TERMSRV/<fqdn> можно получить без ручной
регистрации.
Проверка/подтверждение (на DC или любой машине в домене):
setspn -L <COMPUTERNAME>
setspn -Q TERMSRV/host.example.com
9.5 Подключение Razor к Windows AD
Способ A (настоятельно рекомендуется): в razor.yml параметр
dns: указывает на IP DNS-сервера Windows AD. DNS AD
уже содержит SRV-запись _kerberos → FreeRDP3
автоматически обнаруживает KDC → Kerberos, без необходимости в
krb5.conf.
Способ B: если изменить DNS Razor неудобно, внедрите krb5.conf, где
kdc = <FQDN или IP DC Windows>, realm
указывается заглавными буквами (EXAMPLE.COM).
Порт KDC
88 (TCP+UDP) — см. раздел 5.3.
9.6 (Опционально) Принудительное включение Kerberos / отказ
от NTLM на стороне Windows
GPO: Конфигурация компьютера → Политики → Конфигурация Windows →
Параметры безопасности → Локальные политики → Параметры
безопасности, раздел политик «Сетевая безопасность: ограничить
NTLM».
Либо добавьте учётную запись в группу Protected Users
(принудительно использует Kerberos, отключает NTLM и другие слабые
методы аутентификации; поддерживается FreeRDP3).
Внимание! У группы Protected Users есть побочные эффекты
(невозможность делегирования, невозможность использовать
NTLM/кэшированный вход и т. д.) — это нужно обсудить с заказчиком
или предоставить решение на его усмотрение!
Приложение
Шаблон krb5.conf (для способа B)
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
forwardable = true
[realms]
EXAMPLE.COM = {
kdc = <KDC_IP>
admin_server = <KDC_IP>
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
