Вопросы Теги

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

Общие сведения

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

Error code: 0x207. We couldn't connect to the remote PC.

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

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

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

TL; DR

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

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

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

  • Настройки компьютера> Политики> Административные шаблоны
    • Сеть / Сетевые подключения / Брандмауэр Защитника Windows / Профиль домена:
      • Брандмауэр Защитника Windows: Разрешить исключения локального порта: Включено
      • Брандмауэр Защитника Windows: Определены исключения входящего порта: 3389: TCP: [IP-адреса]: включено: Подключения к удаленному рабочему столу
    • Делегирование системы / учетных данных
      • Удаленный хост Разрешает делегирование неэкспортируемых учетных данных: Включено
    • Компоненты Windows / Службы удаленного рабочего стола / Узел сеанса удаленного рабочего стола / Подключения
      • Разрешить пользователям подключаться удаленно с помощью служб удаленных рабочих столов: включено
    • Компоненты Windows / Службы удаленных рабочих столов / Узел сеансов удаленных рабочих столов / Безопасность
      • Всегда запрашивать пароль при подключении: Включено
      • Требовать безопасную связь RPC: Включено
      • Требовать аутентификации пользователя для удаленных подключений с использованием аутентификации на уровне сети: Включено
      • Установить уровень шифрования клиентского соединения: Включено. Уровень шифрования: высокий уровень

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

Если я попробуйте войти в систему с клиента, отличного от 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 в домене, применив следующие групповые политики к контроллерам домена, используя политику контроллеров домена по умолчанию : -

  • Конфигурация компьютера > Политики> Параметры Windows> Параметры безопасности> Локальные политики> Параметры безопасности
    • Сетевая безопасность: уровень проверки подлинности LAN Manager: отправлять только ответ NTLMv2. Отказать LM и NTLM
    • Сетевая безопасность: Ограничить NTLM: NTLM-аутентификация в этом домене: Запретить учетные записи домена для серверов домена.
    • Сетевая безопасность: Ограничить NTLM: Аудит входящего трафика NTLM: Включить аудит для всех учетных записей

Вкл. контроллер домена, у меня есть соответствующее событие журнала для неудавшегося запроса проверки подлинности 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, заключается в добавлении полного доменного имени этого ПК в политику контроллеров домена по умолчанию в разделе: -

  • Конфигурация компьютера> Политики> Параметры Windows> Параметры безопасности> Локальные политики> Параметры безопасности
    • Сетевая безопасность: Ограничить NTLM: Добавить исключения сервера в этом домене:

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
4
задан 5 May 2020 в 19:38
3 ответа

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

0
ответ дан 4 January 2021 в 07:37

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

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

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

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

0
ответ дан 4 January 2021 в 07:37

Политика «Безопасность сети: ограничить NTLM: проверка подлинности NTLM в этом домене: запретить учетным записям домена на серверах домена» ограничивает подключения NTLM к серверам домена. Если вы хотите подключиться к домену через клиент, который не поддерживает Kerberos, вы должны отключить эту политику или, возможно, попробовать опцию «запретить для учетных записей домена». Другая потенциальная проблема заключается в том, что вы включили NLA (аутентификация на уровне сети). Попробуйте выключить и повторить попытку.

1
ответ дан 7 March 2021 в 20:46

Теги

Похожие вопросы