Назад | Перейти на главную страницу

Аутентификация удаленного рабочего стола без NTLM - как настроить из клиентов, отличных от Windows?

Задний план

Это уже давно меня беспокоит (и никакие поиски в Интернете не дали достойного решения), поэтому я надеюсь, что кто-то может дать какой-нибудь мудрый совет. Когда я пытаюсь запустить сеанс удаленного рабочего стола с Mac на ПК, присоединенный к домену Windows, используя последний клиент удаленного рабочего стола Microsoft (в настоящее время v10.3.9), я часто получаю сообщение об ошибке на следующем снимке экрана.

Не удалось подключиться к удаленному ПК. Это может быть связано с истекшим сроком действия пароля. Если это продолжает происходить, обратитесь за помощью к сетевому администратору.

Код ошибки: 0x207

Если я попытаюсь удаленно подключиться к тому же компьютеру с ПК с Windows, используя собственный клиент удаленного рабочего стола Windows, я не получу эту ошибку и могу нормально подключиться. Это характерно для клиентов, отличных от Windows.

TL; DR

Есть ли способ разрешить клиентам, отличным от Windows, подключаться к подключенным к домену компьютерам с Windows через удаленный рабочий стол, не делая исключений проверки подлинности NTLM для каждого целевого компьютера? Kerberos, похоже, недоступен для клиента Mac RDP. Поддерживается ли другой механизм аутентификации?

Параметры GPO и журналы событий на сервере RDP

Целевой компьютер, присоединенный к домену (сервер RDP), имеет много примененных GPO. Я думаю, что все соответствующие настройки из gpresult следовать:

Пользователи, предназначенные для удаленного доступа, добавляются в группу пользователей соответствующего ПК удаленного рабочего стола «Пользователи удаленного рабочего стола» с помощью lusrmgr.msc Оснастка MMC.

Если я попытаюсь войти в систему с клиента, отличного от Windows, получив указанную выше ошибку, журнал безопасности на сервере RDP покажет неудачное событие входа в систему, ID 4625: -

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          <Date> <Time>
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      <RDP Host>
Description:
An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       <User Name>
    Account Domain:     <Domain Name>

Failure Information:
    Failure Reason:     An Error occured during Logon.
    Status:         0x80090302
    Sub Status:     0xC0000418

Process Information:
    Caller Process ID:  0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:   <RDP PC FQDN>
    Source Network Address: <RDP PC IP Address>
    Source Port:        0

Detailed Authentication Information:
    Logon Process:      NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

Параметры GPO и журналы событий на контроллере домена

Итак, похоже, что неудачный вход в сеть с использованием аутентификации NTLM. В соответствии с различными передовыми практиками и рекомендациями по безопасности я попытался отключить аутентификацию NTLM в домене, применив следующие групповые политики к контроллерам домена, используя Default Domain Controllers Policy: -

На контроллере домена у меня есть событие журнала, соответствующее неудачному запросу проверки подлинности NTLM, в разделе Журналы приложений и служб> Microsoft> Windows> NTLM> Рабочий: -

Log Name:      Microsoft-Windows-NTLM/Operational
Source:        Microsoft-Windows-Security-Netlogon
Date:          <Date> <Time>
Event ID:      4004
Task Category: Blocking NTLM
Level:         Warning
Keywords:      
User:          SYSTEM
Computer:      <DC FQDN>
Description:
Domain Controller Blocked: NTLM authentication to this domain controller is blocked.
Secure Channel name: <RDP PC FQDN>
User name: <User Name>
Domain name: <Domain>
Workstation name: <RDP PC FQDN>
Secure Channel type: 2

NTLM authentication within the domain <Domain> is blocked.

If you want to allow NTLM authentication requests in the domain <Domain>, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Disabled.

If you want to allow NTLM authentication requests only to specific servers in the domain ms-rtc, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Deny for domain servers or Deny domain accounts to domain servers, and then set the security policy Network Security: Restrict NTLM: Add server exceptions in this domain to define a list of servers in this domain as an exception to use NTLM authentication.

Обходной путь

Итак, единственный известный мне способ разрешить удаленному рабочему столу доступ к ПК с клиента, отличного от Windows, - это добавить полное доменное имя этого ПК в политику контроллеров домена по умолчанию в разделе: -

P.S. Подумал, сертификаты не упомянул. Я развернул внутреннюю PKI, и у меня также есть сертификаты RDP, автоматически развертываемые GPO. От клиента меня спрашивают, доверять ли сертификату, 0x207 появляется после того, как я выбираю Принять, чтобы доверять сертификату, а затем ввожу свой домен \ имя пользователя и пароль. Как и выше, я могу подключиться, если указано исключение NTLM, или войти в систему не удастся, если сервер не указан в качестве исключения.

ИЗМЕНИТЬ 1

В качестве альтернативы клиенту Microsoft RDP на Mac я попробовал другое приложение под названием freerdp, установлен с brew install freerdp. Это также не позволяет войти в систему на любом ПК, где NTLM не был явно включен, но дает гораздо более информативное сообщение об ошибке, чем клиент Microsoft, особенно с уровнем журнала, установленным на TRACE. Я не уверен, поддерживает ли он Kerberos, CredSSP или аналогичный, но, возможно, эта дополнительная информация может оказаться полезной: -

$ xfreerdp /log-level:TRACE /d:<DOMAIN> /u:<User Name> /v:<RDP Host FQDN> 
[17:24:38:242] [4547:0ff48000] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[17:24:38:243] [4547:0ff48000] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[17:24:38:261] [4547:0ff48000] [INFO][com.freerdp.client.x11] - Property 296 does not exist
[17:24:38:262] [4547:0ff48000] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[17:24:38:263] [4547:0ff48000] [DEBUG][com.freerdp.client.x11] - Pointer device: 6
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[17:24:38:272] [4547:0ff48000] [DEBUG][com.freerdp.core] - connecting to peer <RDP Host IP>
[17:24:38:277] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - RDP_NEG_RSP
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - selected_protocol: 2
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Negotiated NLA security
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_NLA
[17:24:38:622] [4547:0ff48000] [DEBUG][com.winpr.utils] - Could not open SAM file!
Password: ***
[17:24:42:365] [4547:0ff48000] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[17:24:42:365] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - nla_client_init 348 : packageName=Negotiate ; cbMaxToken=12256
[17:24:42:366] [4547:0ff48000] [TRACE][com.freerdp.core.nla] -  InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[17:24:42:366] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - Sending Authentication Token
[17:24:42:366] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - 0000 <some hex numbers> NTLMSSP.........
[17:24:42:366] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[17:24:42:366] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - 0020 06 01 b1 1d 00 00 00 0f                         ........
[17:24:42:371] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - CredSSP protocol support 6, peer supports 6
[17:24:42:371] [4547:0ff48000] [ERROR][com.freerdp.core.nla] - SPNEGO failed with NTSTATUS: 0x80090302
[17:24:42:371] [4547:0ff48000] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_AUTHENTICATION_FAILED [0x00020009]
[17:24:42:371] [4547:0ff48000] [ERROR][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_NLA - nla_recv_pdu() fail
[17:24:42:371] [4547:0ff48000] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
[17:24:42:371] [4547:0ff48000] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1

Здесь происходит пара вещей:

  • Чтобы использовать аутентификацию Kerberos на компьютере, отличном от Windows, вам необходимо настроить это специально. Здесь есть хорошее руководство (другая цель - vscode auth - но такое же решение): https://github.com/microsoft/vscode-mssql/wiki/How-to-enable-Integrated-Authentication-on-macOS-and-Linux-using-Kerberos
  • Используя CredSSP, это должно фактически позволить вам использовать Kerberos (или, лучше, делегировать билет ограничения от клиента к цели)
  • У меня нет Mac, чтобы проверить это, но этот метод работает с Linux.

Но даже если это сработает, это перенесет бремя с настройки объекта групповой политики, чтобы он содержал все имена клиентов, освобожденных от аутентификации Kerberos, на настройку всех клиентов.

Однако это делает его более безопасным, поскольку теперь вы разрешаете аутентификацию NTML для всего, что исходит от этих конкретных клиентов.

Отредактируйте файл подключения к удаленному рабочему столу (.rdp в Windows) с помощью текстового редактора и добавьте эту строку: enablecredsspsupport:i:0 Мне пришлось сделать это, чтобы войти в систему на ПК с Windows 10 из Linux Mint 17. На самом деле мне также пришлось сделать это для входа в систему. из Windows 10, которая была подключена к другому домену AD.