Перейти к основному контенту

JumpServer RDP через Kerberos-аутентификацию

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:

  1. Kerberos = аутентификация Kerberos прошла успешно
  2. NTLM = использован NTLM (поле LmPackageName дополнительно показывает NTLM V1/V2)

Примечание: значение Negotiate в записи с LogonType 10 — это лишь метка «оболочки» сессии и не является достоверным показателем.

3. Предварительные условия (отсутствие любого из них приводит к откату на NTLM или к сбою)

  1. Целевой Windows-сервер уже включён в домен AD (домен предоставляет KDC и автоматически регистрирует для компьютера SPN HOST/TERMSRV).
  2. Адрес актива в JumpServer указан как FQDN (например, host.example.com), нельзя использовать IP (у IP нет SPN → обязательно NTLM).
  3. Учётная запись подключения содержит домен/realm: user@example.com (UPN, рекомендуется) или DOMAIN\user. Одно лишь имя пользователя не позволяет определить realm → NTLM.
  4. Подключение выполняется через Razor (клиент), а не через Lion (Web GUI).
  5. Razor способен обнаружить KDC и подключиться к нему (см. раздел 5), порт KDC 88 (TCP+UDP) должен быть доступен.
  6. Расхождение часов между клиентом, 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
Наверх