Включение nla windows 7 — Ваш верный помощник с OS Windows

При подключении к рабочему столу удаленного компьютера с помощью встроенного RDP клиента (mstsc.exe) может появится ошибка:

Произошла ошибка проверки подлинности.
Указанная функция не поддерживается.

An authentication error has occurred.
 The function requested is not supported.

RDP Произошла ошибка проверки подлинности. Указанная функция не поддерживается

Данная ошибка связана с тем, что Windows по-умолчанию блокирует RDP подключения к удаленным компьютерам, на которых используется уязвимая версия протокола CredSSP (CVE-2018-0886). Протокол CredSSP (Credential Security Support Provider) используется для пре-аутентификации пользователей, когда для RDP доступа включен протокол NLA (Network Level Authentication / Проверка подлинности на уровне сети). Microsoft выпустило обновление для уязвимости CredSSP в 2018 г (https://support.microsoft.com/en-us/topic/credssp-updates-for-cve-2018-0886-5cbf9e5f-dc6d-744f-9e97-7ba400d6d3ea), но какой-то причине это обновление не установлено на удаленном хосте, к которому вы пытаетесь подключиться.

Как исправить ошибку проверки подлинности RDP?

Что нужно сделать, чтобы исправить ошибку и подключиться к вашему RDP/RDS серверу?

1. (Рекомендованный способ) Самый правильный способ решения проблемы – установить последние кумулятивные обновлений безопасности Windows на удаленном компьютере/сервере, к которому вы подключаетесь по RDP. Скорее всего этот компьютер был недавно развернут из старого образа, или на нем отключено служба обновлений Windows. Проверьте последнюю дату установки обновлений Windows с помощью модуля PSWindowsUpdate или командой:
  gwmi win32_quickfixengineering |sort installedon -desc
  
  Картинка с сайта: winitpro.ru
  
  Обновления можно получить автоматически через Windows Update, или вы можете скачать и установить обновления Windows вручную. Нужно установить любое кумулятивное обновления для вашей версии Windows, выпущенное после 2019 года;
2. (Не рекомендуется) Временный способ 1. Вы временно разрешить подключение к RDP серверам с небезопасной версией CredSSP на своем компьютере (клиенте). Для этого нужно изменить ключ реестра AllowEncryptionOracle командой:
  REG ADD
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2
  
  или можно изменить настройки локальной политики Encryption Oracle Remediation / Исправление уязвимости шифрующего оракула), установив ее значение = Vulnerable / Оставить уязвимость (см. описание в статье Ошибка RDP подключения: CredSSP encryption oracle remediation).
  
  Картинка с сайта: winitpro.ru
  
  Это позволит вам подключиться к удаленному серверу по RDP и установить последние обновления безопасности (способ 1). После обновления сервера отключите политику или измените значение ключа AllowEncryptionOracle на 0 :
  REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 0
3. (Не рекомендуется) Временный способ 2. Можно отключить проверку подлинности на уровне сети (NLA) на стороне RDP сервера (описано ниже).

Отключить проверку подлинности уровня сети (NLA) для RDP в Windows

Если на стороне RDP сервера, которому вы подключаетесь, включен NLA, это означает что для преаутентификации RDP пользователей используется протокол CredSPP.

Вы можете отключить Network Level Authentication в свойствах системы (SystemPropertiesRemote.exe) на вкладке Удаленный доступ (Remote), сняв галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети / Allow connection only from computers running Remote Desktop with Network Level Authentication (recommended)».

В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию «Разрешить подключения от компьютеров с любой версией удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)».

Также можно отключить проверку подлинности на уровне сети (NLA) с помощью редактора локальной групповой политики.

Для этого перейдите в разделе Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Безопасность (Computer Configuration –> Administrative Templates –> Windows Components –> Remote Desktop Services – Remote Desktop Session Host –> Security), отключите политику Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require user authentication for remote connections by using Network Level Authentication).

Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети

Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.

Для применения новых настроек RDP нужно обновить настройки групповых политик (
gpupdate /force
) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.

Источник

Хочу поделиться несколькими советами по настройке удаленного подключения к рабочим местам по RDP. Расскажу как проапгрейдить древний RPC-HTTP до UDP, похвалю и поругаю Windows 10 и AVC, разберу решение нескольких типичных проблем.

Считаем, что для подключения используется Remote Desktop Gateway (RDGW), а в качестве серверов выступают рабочие станции. Использовать RDGW очень удобно, потому что шлюз становится общей точкой входа для всех клиентов. Это дает возможность лучше контролировать доступ, вести учет подключений и их продолжительность. Даже если VPN позволяет подключиться к рабочим машинам напрямую — это не лучший вариант.

RDGW настраивается быстро, просто, а Let’s Encrypt и win-acme легко решают проблему с доверенным сертификатом.

Есть три транспортных протокола по которым клиент может подключиться с серверу:

RPC-HTTP (

плохо)
HTTP (лучше)
HTTP+UDP (отлично)

Под сервером будем понимать рабочую машину, под клиентом — домашнюю.
Первое, с чего стоит начать, это «плохо» превратить в «отлично».

Апгрейд RPC-HTTP до HTTP

Подключение в сессию с использованием RPC-HTTP легко определить по внешнему виду полоски подключения.

Здесь нет значка качества подключения (о нем ниже), а значит мы используем старый RPC, обернутый в TLS — это очень медленно. Дело, конечно, не только в обертке — сам протокол меняется с каждым релизом ОС, меняются кодеки, алгоритмы упаковки изображения. Чем свежее протокол, тем лучше.

Что делать?

Windows XP или Vista

В XP можно поднять протокол с 5.1 до 7. Хотфикс windowsxp-kb969084-x86.exe

В Vista — c 6 до 7. Хотфикс имеет тот же номер, файлы windows6.0-kb969084-x64.msu или Windows6.0-KB969084-x86.msu

Но RDP 7 не работает по HTTP и UDP. Поможет только апгрейд клиента и сервера до Windows 7 и новее.

Windows 7

Сначала надо обновить протокол до RDP 8.1, а затем включить его. Поддержка добавляется обновлениями, которые сгруппированы в один загрузочный пакет:

www.microsoft.com/en-US/download/details.aspx?id=40986
Windows6.1-KB2574819-v2-x64.msu
windows6.1-kb2592687-x64.msu
Windows6.1-KB2830477-x64.msu
Windows6.1-KB2857650-x64.msu

~~Windows6.1-KB2913751-x64.msu~~

(заменен kb2923545)

windows6.1-kb2923545-x64.msu

Так вы получите и свежий клиент mstsc.exe, и поддержку RDP 8.1 серверной части ОС.
Было:

Стало:

После этого протокол надо включить ключом реестра (для этого можно использовать adm шаблон в комплекте с Windows 7).

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
"fServerEnableRDP8"=dword:00000001
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows NT\Terminal Services]
"fServerEnableRDP8"=dword:00000001

Включите поддержку транспорта UDP в групповой политике.

Перезагружаем сервер с Windows 7. Тот самый случай, когда может потребоваться перезагрузиться дважды — значение в реестре должно быть установлено до того, как включился RDP, а групповая политика применяется позже.

Если все получилось, то при подключении к серверу в полоске сессии появится иконка качества подключения (как в телефоне для мобильной сети):

Windows 8 и новее

Протокол работает «из коробки».

Апгрейд HTTP до HTTP+UDP

Если ваша сеть не склонна к потере пакетов, UDP существенно (для CAD — радикально) повышает отзывчивость сервера за счет использования FEC для сокращения ретрансмиссии, а также перехода подтверждения доставки пакетов с уровня системного стека TCP/IP на уровень протокола RDP-UDP.

От каждого клиента подключается одна основная управляющая сессия по HTTP (в этом канале также передается клавиатура/мышь), плюс одна или несколько сессий UDP для передачи картинки или других виртуальных каналов.

Мы коснемся только верхушки айсберга. Есть 3 различных версии протокола RDP-UDP. Кроме того, сам UDP может работать в двух режимах UDP-R (reliable) и UDP-L (lossy). С Microsoft ничего просто не бывает. Но поскольку от нас здесь ничего не зависит, просто имейте в виду — чем новее операционная система, теме более современный протокол используется.

Снаружи RDP-UDP оборачивается в Datagram Transport Layer Security (DTLS) RFC4347, в чем вы можете убедиться открыв Wireshark.

Подробнее в документах:
[MS-RDPEMT]: Remote Desktop Protocol: Multitransport Extension
[MS-RDPEUDP]: Remote Desktop Protocol: UDP Transport Extension
[MS-RDPEUDP2]: Remote Desktop Protocol: UDP Transport Extension Version 2
Где не прав — поправьте, пожалуйста.

Что же нужно для включения UDP?

RDP-UDP поддерживается начиная с RDP 8.

На клиенте должен быть открыт порт udp/3389. Если вы его закрыли локальным firewall, ACL на свитче или внешнем файрволле — порт надо открыть.

Для сервера Remote Desktop Gateway к порту tcp/443 надо открыть udp/3391.

Порт можно поменять, вот как он настраивается:

Для Windows 7 обязательно должен быть включен NLA (Network Level Authentication).

Можно включить в групповой политике

или через реестр

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"SecurityLayer"=dword:00000001

В чем связь непонятно. Но без NLA на 7-ке не работает, на более свежих релизах NLA для работы UDP не обязателен.

После установления сессии по HTTP, клиент и сервер пробуют согласовать подключение по UDP. Если есть выпадение пакетов или задержки, то сессия UDP не запустится. Точный алгоритм отказа согласования UDP до конца не понятен.

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

На шлюзе это выглядит так:

Windows 10

Если у вас Windows 10 и на сервере, и на клиенте, то это самый быстрый и беспроблемный вариант. В Microsoft активно дорабатывают RDP, и в свежих релизах 10 вы можете рассчитывать на неплохую скорость работы. Коллеги не смогли обнаружить разницу между Citrix и Windows 10 RDP по скорости работы в AutoCAD.

Про эволюцию кодеков RDP на базе AVC в Windows 10 есть хорошая статья
Remote Desktop Protocol (RDP) 10 AVC/H.264 improvements in Windows 10 and Windows Server 2016 Technical Preview

Согласование AVC с аппаратным кодированием можно увидеть в журнале событий (подробнее в статье выше):

Замечу только, что проблема искажений все же есть даже с h.264 4:4:4. Она сразу бросается в глаза если работать в PowerShell ISE — текст ошибок выводится с неприятным искажением. Причем на скриншоте и на фотографии все отлично. Волшебство.

Также косвенным признаком работы AVC являются время от времени появляющиеся зеленые квадраты по углам.

AVC и аппаратное кодирование в свежих билдах должно работать из коробки, но групповая политика никогда не бывает лишней:

С учетом того, что AVC кодируется аппаратно видеокартой, то обновить драйверы видео — хорошая идея.

О проблемах

XP и Vista

Если проблема возникает на Windows XP или Vista, попробуйте сначала обновить протокол до 7 версии (писал в начале статьи). Обязательно включите поддержку CredSSP. На сайте Microsoft статьи уже удалены, но Интернет помнит.

Если не помогло — «доктор говорит в морг, значит в морг». Что испытала на себе операционная система за последние 15 лет — лучше об этом даже и не думать.

NLA

Иногда помогает отключение NLA на сервере. Выяснить причину не получилось, домашние машины все разные.

NTLM

Некоторые клиенты пытаются авторизоваться с использованием NTLMv1. Причины разные, но исправить на клиенте можно так:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LmCompatibilityLevel"=dword:00000003

Перезагрузка обязательна.

Если вы

~~молоды и дерзки~~

ничего не боитесь, то есть более радикальное решение — отключение Channel Binding на Remote Desktop Gateway

HKLM\Software\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core
Type: REG_DWORD
Name: EnforceChannelBinding
Value: 0 (Decimal)

Делать так не надо. Но мы делали. Для клиента, который настаивал (нет не так, НАСТАИВАЛ) что NTLMv1 на рабочих станциях ему необходим. Не знаю, может там серверы на NT4 без SP еще в работе.

Отключение RDP 8+ в Windows 10

Если ничего не помогает, а идеи кончились, можно воспользоваться недокументированным ключом для даунгрейда протокола RDP до 7 версии.

[HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client]
"RDGClientTransport"=dword:00000001

Сам не делал, и вам не советую. Но кому-то, пишут, что помогает.

DrWeb

Компонент Dr.Web SpIDerGate может запретить подключение. В этом случае возвращается ошибка:

В статистике Dr.Web будет запись:

В комментариях к этой статье со мной связался сотрудник Dr.Web и наша проблема решилась в ближайшем обновлении антивирусных баз.
Если у вас такая же ошибка, лучше обратиться в поддержку.
Как временное решение, можно внести URL вашего RDGW в исключения:

И только если не помогло отключить компонент SpIDer Gate полностью.

Системный прокси

Встретился списанный компьютер из какой-то компании, где в качестве системного прокси был прописан местный TMG, и подключение к RDGW не работало. Это можно исправить так:

netsh winhttp show proxy && netsh winhttp reset proxy

Переключение раскладок клавиатуры

Иногда приезжают лишние раскладки. Можно отключить проброс раскладки с клиента

[HKLM\System\CurrentControlSet\Control\Keyboard Layout]
"IgnoreRemoteKeyboardLayout"=dword:00000001

Проблемы с DPI

Масштабирование приходит с клиентской машины, и если на домашнем ноутбуке стоит 125%, то и на рабочей машине будет так же. На серверах это можно отключить, а на рабочих станциях не нашел как. Но в магазине приложений Windows 10 есть «современный» клиент.

В нем можно настроить DPI:

Как мониторить шлюз с RDGW

Есть счетчик производительности «Шлюз служб терминалов\Текущие подключения», который немного глючит, если нет подключений или сервер долго не перезагружался. Он показывает именно число подключений, но как мы помним, для HTTP+UDP их как минимум два, а может быть и больше. Поэтому это не совсем объективный показатель числа подключений сотрудников.

Есть класс WMI Win32_TSGatewayConnection. Его содержимое соответствует тому, что вы видите в разделе «Наблюдение» шлюза удаленных рабочих столов.

С ним число подключений можно посчитать поточнее:

Get-WmiObject -class "Win32_TSGatewayConnection" -namespace "root\cimv2\TerminalServices" 
|?{$_.transportprotocol -ne 2}|select username,connectedresource|sort username|Get-Unique -AsString| measure|select -ExpandProperty count

Just for fun есть утилита Remote Display Analyzer. Бесплатная версия мне ничего полезного не показала, но вдруг кому-то пригодится.

А как же тонкий тюнинг, настройка нескольких десятков параметров сессии?

Здесь уместен принцип Парето: 20% усилий дают 80% результата. Если вы готовы инвестировать ваше время в оставшиеся 20% результата — отлично. Только имейте в виду, что когда вы читаете статью о настройке протокола в Windows 7, то не знаете про какой протокол писал автор — 7, 8 или 8.1. Когда читаете про Windows 10 без указания релиза — проблемы те же. Например, пишут что в свежих билдах Windows 10 кодек AVC/h.264 изменился на RDPGFX_CODECID_AVC444V2, а в Windows Server 2016 остался RDPGFX_CODECID_AVC444.

Из всех таких советов мы используем только две настройки:

16 bit цвет, об этом можно почитать в статье MS RDP Performance / Bandwidth Usage
Отключение сглаживания шрифтов font smoothing:i:0 по статье выше или Performance Tuning Remote Desktop Session Hosts

Сомневаюсь, что они дают какой-то ощутимый результат.

Вот мы и подошли к концу статьи. Хотел покороче, а получилось как всегда. Рад, если кому-то эти советы помогут сэкономить время или улучшить настройку своей инфраструктуры.

Источник

NLA (Network Level Authentication) is per default enabled since Windows 8 / 8.1 and Windows Server 2012.

Due to this option remote connection is refused if you try to connect from Linux client, iOSx (iPhone, iPad), Android devices, etc which do not support NLA.

If you are running Windows 8 Professional, Enterprise or Windows 2012 server you can easily uncheck NLA

«Computer» — right click «Properties» — «Remote Settings»:

Unfortunately this user interface is not available with Standard version.

Here you have to modify the according registry key.

Open Registry-Editor (Start — Run — Enter: regedit) and move to path

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\ Winstations\RDP-Tcp

in the right pane look for value «UserAuthentication» and change the value to «0»

(reboot required!)

Tags: disable, Network Level Authentication, NLA, WIndows 7, Windows 8, Windows 8.1

Источник

Привет.

Вчера, общаясь с Иваном Никитиным, получил дельный совет осветить работу и настройку протокола RDP. Мысль дельная, дальше – подробнее.

Введение

Протокол RDP – удобное, эффективное и практичное средство для удалённого доступа как для целей администрирования, так и для повседневной работы.
Учитывая, что его реализации есть практически везде (различные платформы и ОС), и их много, нужно хорошо представлять его возможности.
По крайней мере, это будет нужно по ряду причин:

Зачастую вместо RDP используется другое решение (VNC, Citrix ICA) по простой причине – предполагается, что “встроенный RDP минимальный и ничего не умеет”.
Во многих решениях, связанных с модными сейчас облачными технологиями (перевод офисов на “тонкие клиенты”, да и просто организация терминальных серверов), бытует мнение что “RDP плохой потому что встроенный”.
Есть стандартный миф про то, что “RDP нельзя без VPN наружу выставлять, ломанут” (миф имеет под собой обоснование, но уже давно не актуален).
Ну, раз уж про мифы заговорили – бытует мнение, что “Перейдя с RDP на Citrix трафик в пару раз падает”. Ведь цитрикс – это дорого, следовательно как минимум на 157% круче.

Все эти мифы – ерунда и смесь устаревших “дельных советов”, актуальных во времена NT 4.0, а так же откровенных вымыслов, не имеющих никаких причин к существованию. Так как IT – это точная наука, надо разобраться. Хорошо настроеный протокол RDP новых версий, с учётом всех новых функциональных возможностей, является достаточно хорошим и надёжным инструментом для организации удалённого доступа.

Поэтому мы займёмся:

Кратким упоминанием про версии RDP
Настройкой режима защиты RDP-сессии
Настройкой шифрования для RDP
Привязкой к конкретному адаптеру и порту
- Меняем стандартный порт на нужный
- Делаем раздельные настройки RDP для нескольких сетевых адаптеров
Включением NLA
- Как включается NLA со стороны RDP-сервера
- NLA и Windows XP
- Как включить CredSSP в XP
Выбором правильного сертификата для RDP
Блокированием подключений по RDP учётным записям с пустым паролем
Настройка ACL для подключения по RDP
Оптимизацией скорости RDP
- Отключаем редирект неиспользуемых устройств
- Настраиваем общую логику оптимизации визуальных данных RDP
Оптимизацией сжатия RDP
- Настраиваем общее сжатие RDP
- Настраиваем сжатие аудиопотока RDP
Оптимизацией соотношения потоков данных RDP
Включением Require secure RPC communication для RDP

Приступим.

Версии протокола RDP

Протокол имеет достаточно длительную историю, начиная с NT 4.0. Исторические детали мы оставим в стороне по простой причине – на данный момент имеет смысл говорить только про версию RDP 7.0, которая есть в Windows Vista SP1 / Windows Server 2008 и бесплатно добавляема в Windows XP установкой SP3 и обновлённого клиента RDP (находится по ссылке на KB 969084). Я предполагаю, что у Вас как минимум Windows XP, и что Вы поставили/можете поставить последний Service Pack и не трачу Ваше время на обсуждение преимуществ RDP в Windows 2000 SP2 перед NT 4.0 SP5.

Настройка режима защиты RDP-сессии

В принципе, это самая простая часть задачи. Суть в следующем. В различных версиях RDP применяется два основных механизма защиты сессии – встроенный в RDP и “заворачивание” сессии в TLS. Встроенный является недостаточно безопасным, и рекомендация “RDP можно наружу только в VPN” – про него. Поэтому всегда включайте поддержку TLS. Это тот минимум, с которого Вы должны начать. Ограничениями будут разве что версия сервера не ниже Windows Server 2003 SP1 и клиент RDP 5.2 и выше, но, думается, это в конце 2011 года вполне решаемо.

Как включить RDP over TLS

Вариантов, как всегда, несколько. Первый – включение через групповую политику. Для этого надо зайти в целевой объект групповой политики (ну или локально на своей домашней рабочей станции запустить gpedit.msc) и там последовательно выбрать “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Remote Desktop Session Host” -> “Security” и там включить параметр Require use of specific security layer for remote connections, выбрав в нём SSL (TLS 1.0) only. Можно выбрать и более мягкий Negotiate, но я бы не рекомендовал, т.к. на данный момент это банально ниже приемлемого уровня безопасности. Как человек, создававший private cloud’ы с достаточно высоким уровнем безопасности, я могу сказать, что смысл выносить особо ценные данные в датацентр под Лондоном и ходить туда дефолтным RDP – нулевой и является поиском неприятностей.

Можно и проще – откройте оснастку Remote Desktop Session Host Configuration (найдёте в mmc или готовую в меню Administrative Tools -> Remote Desktop Connections), выберите из списка Connections нужное подключение (обычно оно одно и называется RDP-Tcp), и откройте Properties, после – вкладку General и там выбрать нужный Security Layer.

Для работы TLS необходим цифровой сертификат (как минимум – со стороны сервера). Обычно он уже есть (генерится автоматически), убедитесь в его наличии, про то, как сделать его хорошим, поговорим после. Пока надо, чтобы он просто был, иначе подключиться не получится.

Настраиваем шифрование для RDP

Для конфигурирования будет доступно 4 варианта шифрования. Рассмотрим каждый из них.

Режим RDP Low Encryption

Самый “никакой” режим. Наследие страшных времён и версий RDP 5.x. Может согласовать шифрование на базе 56ти битового DES или 40ка битового RC2, что на текущий момент является несерьёзным. Не нужен и опасен. Например, если включить его, то не включится TLS, т.к. TLS уже откажется согласовывать такие слабые шифры, которые предлагает этот вариант.

Режим RDP Client Compatible Encryption

Второй “никакой” режим. Наследие страшных времён и версий RDP 5.x. Попробует до 128 бит RC4, но сразу согласится на DES/RC2. Не нужен и опасен. Тоже не совместим с TLS.

Режим RDP High Encryption

Минимально допустимый режим. Потребует хотя бы 128ми битовый RC4. Работает со всеми серверами, начиная с Windows 2000 Server w/HEP.

Режим RDP FIPS140-1 Encryption

То, что нужно. Будет поддерживать современные симметричные алгоритмы и в явном виде не будет поддерживать RC2, RC4, одиночный DES, а также будет заставлять использовать для вычисления целостности (Message Authentication Code – MAC) алгоритм SHA-1, а не MD5. Включайте этот вариант всегда, найти сервер, который не умеет 3DES, AES или SHA-1 практически нереально.

Где делается эта настройка? Откройте оснастку Remote Desktop Session Host Configuration (найдёте в mmc или готовую в меню Administrative Tools -> Remote Desktop Connections), выберите из списка Connections нужное подключение (обычно оно одно и называется RDP-Tcp), и откройте Properties, после – вкладку General и там выберите нужный Encryption Level.

Привязываем RDP к конкретному адаптеру и порту

Для того, чтобы сервер работал безопасно и предсказуемо (например, не начинал принимать подключения с нового, свежедобавленного сетевого адаптера), необходимо в явном виде указать, на каких интерфейсах служба RDP-сервера должна принимать подключения. Плюс, достаточно часто бывает полезным переключить порт, на котором сервер слушает подключения. Конечно, можно это сделать и публикуя сервер с RDP через какой-нибудь шлюз, но можно и без этого. Такие, казалось бы, базовые действия в реальности ощутимо снизят процент дураков-скрипткиддисов, которые очередной “мощной тулзой” проверяют wellknown-порты.

Как привязать службу RDP к конкретному сетевому адаптеру или сделать несколько RDP с разными настройками для разных адаптеров

Откройте оснастку Remote Desktop Session Host Configuration (найдёте в mmc или готовую в меню Administrative Tools -> Remote Desktop Connections), выберите из списка Connections нужное подключение (обычно оно одно и называется RDP-Tcp), и откройте Properties, после – вкладку Network Interfaces. В ней Вы сможете выбрать один конкретный интерфейс, на котором надо ожидать подключения, плюс ограничить количество параллельных сессий.

Если у Вас много интерфейсов, и Вам надо, допустим, чтобы можно было подключаться через 2 из 5 доступных, то Вам надо будет привязать существующий по-умолчанию RDP-Tcp к одному адаптеру, после зайти в меню Action и там выбрать Create New Connection. Подключение может слушать либо на всех интерфейсах, либо на одном, и в случае, когда надо, чтобы оно слушало на N интерфейсах, придётся создать N подключений.

Соответственно, если у Вас есть задача “Чтобы на одном интерфейсе RDP слушал на одном порту, а на другом – на другом”, она решаема так же – отвязываете дефолтный RDP-Tcp от всех адаптеров и привязываете к конкретному, после – создаёте новое RDP-подключение и тоже привязываете к нужному сетевому интерфейсу.

Как привязать службу RDP к не-дефолтному порту

Порт по умолчанию – 3389 TCP. Кстати, не забудьте разрешить его в пакетном фильтре. Ну а если хотите другой – надо зайти в ключ реестра

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

и поправить в нём значение PortNumber. Учитывайте, что отслеживание конфликтов в плане занятости портов – на Вашей совести, сам он, обнаружив, что назначенный Вами порт занят, “перепрыгнуть” никуда не сможет.

Включаем NLA – Network Level Authentication

Функция NLA появляется в NT 6.0, а позже добавляется возможность её частичного использования в предыдущей версии ОС путём установки SP3 для XP.
Суть данной функции достаточно проста. В версиях RDP до 6.0 при подключении по RDP клиенту до аутентификации надо показать окно входа – т.е. вначале показать, а потом уже он попробует зайти в систему. Это создаёт простую уязвимость – сервер можно перегрузить пачкой запросов “а дай-ка мне попробовать новую сессию начать”, и он будет вынужден на все запросы отвечать созданием сессии и ожиданием входа пользователя. Фактически, это возможность DoS. Как с этим можно бороться? Логично, что надо придумать схему, целью которой будет как можно раньше запросить у клиента учётные данные. Оптимально – чтобы было что-то типа как kerberos в домене. Это и было сделано. NLA решает две задачи:

Клиент аутентифицируется до инициации терминальной сессии.
Появляется возможность передать данные локального клиентского SSP на сервер, т.е. начинает работать Single Sign-On.

Реализуется это через новый провайдер безопасности – CredSSP. Почитать его техническую спецификацию можно тут, ну, а говоря проще, надо всегда включать данную функцию. Конечно, учитывая, что для её работы нужно, чтобы:

Клиентская ОС (та, с которой идёт подключение) была Windows XP SP3 и выше.
Серверная ОС (та, к которой будет подключение) была Windows Server 2008 и выше.

Как включается NLA со стороны RDP-сервера

Лучше всего включить NLA на всех серверах через групповую политику. Для этого надо зайти в целевой объект групповой политики и там последовательно выбрать “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Remote Desktop Session Host” -> “Security” и там включить параметр Require user authentication for remote connections by using Network Layer Authentication.

Можно включить и локально. Это делается путём вызова подменю Properties (стандартное подменю у Computer) и выбора там вкладки Remote, в которой будет выбор из трёх вариантов – запрещать подключения по RDP к данному хосту, разрешать подключения по любому RDP, разрешать только с NLA. Всегда включайте вариант с NLA, это в первую очередь защищает сервер.

NLA и Windows XP

В случае, если у Вас Windows XP, то Вы также можете воспользоваться данной функцией. Распространённое утверждение “Для NLA нужна как минимум виста, это Microsoft сделал чтобы апгрейдились” ложно. В Service Pack 3 добавляется реализация CredSSP, позволяющая делегировать клиентские credentials’ы, которыми обладает местный SSP, на сервер. Т.е., говоря проще, это специально сделано, чтобы с Windows XP можно было подключаться на системы с NT 6.0+. На саму Windows XP SP3 с данной функцией подключаться не получится, поддержка NLA будет частичной (поэтому RDP сервер с поддержкой подключения клиентов с использованием NLA из Windows XP сделать штатными способами не получится, Windows XP будет только NLA-совместимым клиентом).

Включать данный функционал нужно в явном виде, так как несмотря на то, что Service Pack 3 добавляет приносит новую dll криптопровайдера, он её не включает.

Как включить CredSSP в XP

Ещё раз – данная операция проводится строго после установки Service Pack 3 на Windows XP и в контексте нашего разговора нужна для того, чтобы было возможно подключение к другим серверам по RDP 6.1 с использованием NLA.

Шаг первый – расширяем перечень Security Packages.
Для этого мы откроем ключ реестра

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

и найдём в нём значение Security Packages. Нажмём правую кнопку и выберем “Modify” (не Modify Binary Data, а просто Modify). Там будет список вида “название package на каждой строке”. Нам надо добавить туда tspkg. Остальное надо оставить. Место добавления некритично.

Второй шаг – подцепляем библиотеку.
Ключ будет другим:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders

В нём надо будет найти значение SecurityProviders (заметьте, как и в предыдущем случае, это не subkey, а значение), и модифицировать его по аналогии, только добавив credssp.dll. Остальное в списке, опять же, трогать не надо.

Теперь редактор реестра можно закрыть. После этих операций систему надо будет обязательно перезагрузить, т.к. криптопровайдеры – штука такая, которая на ходу точно не подцепится, и это скорее хорошо, чем плохо.

Выбираем правильный сертификат для RDP

Если у Вас есть возможность пользоваться не-дефолтным сертификатом для RDP, то лучше пользоваться именно им. Это не повлияет на безопасность сессии как таковой, но повлияет на безопасность и удобство подключения. В сертификате, который оптимально использовать, должны быть следующие момент:

Имя (в subject или SAN), посимвольно совпадающее с тем именем, которое вводит клиент, подключающийся к серверу.
Нормальное расширение CDP, указывающее на рабочий CRL (желательно хотя бы на два – OCSP и статический).
Желательный размер ключа – 2048 бит. Можно и больше, но помните об ограничениях CAPI2 в XP/2003.
Не экспериментируйте с алгоритмами подписи/хэширования, если Вам нужны подключения со стороны XP/2003. Чуть больше информации про это в статье про настройку TLS, но вкратце – выберите SHA-1, этого вполне достаточно.

Чуть подробнее остановлюсь на выпуске специального сертификата для RDP-сервера.

Делаем всё красиво – специальный шаблон сертификата для RDP-серверов

Идеально будет, если сертификат для RDP сделать не на основе обычного шаблона (типа Web Server) и иметь в поле Application Policy (которое в сертификате будет более привычно называться Enchanced Key Usage – EKU) стандартные значения Client Authentication и Server Authentication, а добавить свой шаблон, в котором будет единственное, специальное, не добавляемое стандартными способами значение применения – Remote Desktop Authentication. Это значение Application Policy придётся создать вручную, его OID’ом будет 1.3.6.1.4.1.311.54.1.2, ну а после – уже можно сделать новый шаблон сертификата, на основании которого и выпустить сертификат, адресно “заточеный” под RDP Server.

Чтобы полностью автоматизировать эту операцию, сделайте у нового шаблона предсказуемое название – например, “RDPServerCert” – и зайдите в объект групповой политики, а там откройте Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Выберите параметр Server Authentication Certificate Template и включите его, а в поле значения введите название – мы сделали RDPServerCert. Теперь все доменные хосты, подпадающие под эту политику, будут в случае включения на них RDP сами идти к Certification Authority, запрашивать в случае отсутствия себе сертификат на основе указанного шаблона, и автоматически делать его дефолтным для защиты подключений по RDP. Просто, удобно, эффективно.

Блокируем подключения по RDP учётным записям с пустым паролем

Мелочь, а забывать про неё не нужно.
Для блокировки подключения учёток без паролей к RDP надо зайти в настройку объекта групповой политики: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options и установить “Accounts: Limit local account use of blank passwords to console logon only” в Enabled. Не поленитесь проверить, что это так и есть.

Настройка ACL для подключения по RDP

По умолчанию для подключения к RDP-серверу необходимо иметь явное разрешение User Access или Guest Access.
Это разрешение есть у локальных групп Administrators и Remote Desktop Users. Лучше всего использовать для управления доступом к RDP-серверу группу Remote Desktop Users, добавляя в неё нужные доменные группы, а не отдельных пользователей. Модицифируйте содержимое вкладки Security в настройках Properties у RDP-Tcp только в крайних случаях, лучше всего – добавляя группу “имя хоста RDP Blocked”, которой явно запрещен доступ по RDP к указанному узлу.

Оптимизация скорости RDP

Оптимизация скорости RDP – достаточно обширная тема, поэтому я разделю её на части. В этой будут те способы, которые будут уменьшать нагрузку на протокол до сжатия и до оптимизации сетевого уровня.

Цветность (битовая глубина)

В RDP 7.0 и выше доступны варианты 32,16 и 8 бит. Если речь идёт о работе, то для неё будет достаточно 16 бит. Это ощутимо снизит нагрузку на канал, притом иногда больше, чем в 2 раза, что удивительно, но факт. 8 бит, конечно, тоже можно, но уж больно страшно оно будет выглядеть. 16 бит же вполне приемлемы.

Включите на сервере параметр Limit Maximum Color Depth, либо сделайте аналогичное действие в настройках RDP client.

Отключите ClearType

Когда у Вас выключен ClearType, протокол RDP передаёт не картинку, а команды по отрисовке символов. Когда включен – рендерит картинку со стороны сервера, сжимает и пересылает клиенту. Это с гарантией в разы менее эффективно, поэтому отключение ClearType значительно ускорит процесс работы и уменьшит время отклика. Сами удивитесь, насколько.

Это можно сделать как на уровне настроек клиента, так и на стороне сервера (параметр Do not allow font smoothing в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host).

Уберите wallpaper

Параметр Enforce removal of RD Wallpaper в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host резко улучшит ситуацию с перерисовкой экрана терминальной сессии. Пользователи без котиков на десктопе выживают нормально, проверено.

Включаем и настраиваем кэширование изображений

Если на клиенте есть достаточно оперативной памяти, то имеет смысл включить и настроить кэширование битмапов. Это позволит выиграть до 20-50% полосы пропускания. Для установки надо будет зайти в ключ

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\

и создать там параметры BitmapPersistCacheSize и BitmapCacheSize, оба типа DWORD 32.
Параметр BitmapPersistCacheSize обозначает размер в килобайтах дискового кэша. Значение по умолчанию – 10. Имеет смысл увеличить этот параметр хотя бы до 1000.
Параметр BitmapCacheSize обозначает размер в килобайтах кэша в RAM. Значение по умолчанию – 1500. Имеет смысл увеличить этот параметр хотя бы до 5000. Это будет всего 5 мегабайт на клиентскую сессию, при современных масштабах оперативной памяти это несущественно, и даже если приведёт к выигрышу 10% производительности, уже себя окупит. Кстати, этот же параметр можно поправить и в .rdp-файле; если сохранить своё RDP-подключение, а после открыть файл блокнотом, то среди параметров можно добавить что-то вида bitmapcachesize:i:5000, где 5000 – это 5МБ кэша.

Отключаем Desktop Composition

Desktop Composition привносит всякие “красивости” типа Aero и его друзей и ощутимо кушает полосу пропускания. Для работы это не нужно и вредно. Параметр Allow desktop composition for RDP Sessions в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host необходимо выставить в параметр Disabled.

Оптимизируем параметры Desktop Window Manager

Параметры, находящиеся в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Desktop Window Manager, будут управлять “красивым” отображением плавно выезжающих меню и подобного. Их три – Do not allow window animations, Do not allow desktop compositions и Do not allow Flip3D invocation. Все их надо переключить в режим Enabled, т.е. по сути – отключить все эти функции.

Отключаем редирект неиспользуемых устройств

Если у Вас не планируется подключение определённых классов устройств (например, COM и LPT-портов), или аудио, имеет смысл отключить возможность их перенаправления со стороны сервера. Чтобы клиенты с дефолтными настройками RDP Client не тратили время подключения на согласование неиспользуемого функционала. Это делается там же, где и остальные настройки сервера, в Properties у RDP-Tcp, вкладка Client Settings (там же, где мы делали настройки с глубиной цвета), раздел Redirection.

Настраиваем общую логику оптимизации визуальных данных RDP

Параметр, называющийся Optimize visual experience for RDP sessions, находящийся в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Enviroment, будет управлять тем, как RDP будет воспринимает визуальные данные – как мультимедийные или как текстовые. Это, грубо говоря, “подсказка” алгоритму сжатия, как грамотнее себя вести. Соответственно, для работы надо будет выставить этот параметр в Text, а если хочется много красивых flash-баннеров, HTML5 и просматривать видеоклипы – лучше вариант Rich Multimedia.

Оптимизация сжатия RDP

Сжатие в RDP прошло долгий путь развития. По RDP 5.2 включительно была подсистема сжатия (“компрессор”), имеющий внутреннее название “Version 1” – самый простой и лёгкий вариант с точки зрения загрузки процессора клиента, но самый плохой с точки зрения нагрузки сети трафиком. В RDP 6.0 сделали “Version 2”, который был незначительно, но улучшен по параметру эффективности сжатия. Нам интересен “Version 3”, который работает только при подключении к серверам Windows Server 2008 и старше. Он сжимает лучше всех, а затраты процессорного времени с учётом мощностей современных компьютеров несуществены.

Выигрыш при включении V3 может, судя по тестам, достигать 60% и, в общем-то, и без тестов ощутимо заметен на глаз.

Как включить оптимальное сжатие в RDP

Это – клиентская настройка. Откройте в нужном объекте групповой политики Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Enviroment, выберите там параметр Set compression algoritm for RDP data, включите его и выберите значение Optimize to use less network bandwidth.

Настройка сжатия звукового потока

RDP 7.0 приносит отличную возможность регулировать качество сжатия входящего звукового потока (т.е. звука, который идёт с сервера на клиента). Это достаточно полезно – например, если идёт работа на терминальном сервере, то кроме всяких служебных звуков вида “пришло сообщение в ICQ” другие особо как не планируются. Нет смысла передавать с сервера несжатый звук CD-качества, если для работы это не нужно. Соответственно, нужно настроить уровень сжатия звукового потока.
Данный параметр будет называться Limit audio playback quality и находиться в разделе Device and Resource Redirection в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host. Вариантов будет три:

High – звук будет идти без сжатия. Вообще. То есть, он будет подпадать под общее сжатие протокола RDP, но специфическое сжатие звука (с потерей качества) производиться не будет.
Medium – сжатие будет адаптироваться под канал так, чтобы не увеличивать задержку при передаче данных.
Dynamic – сжатие будет динамически адаптироваться под канал так, чтобы задержка не превышала 150ms.

Выберите подходящий. Как понятно, для офисной работы лучше выбрать Dynamic.

Оптимизация соотношения потоков данных в RDP

Трафик RDP-сессии не является чем-то монолитным. Наоборот, он достаточно чётко разделён на потоки данных перенаправляемых устройств (например, копирования файла с локального хоста на терминальный сервер), аудиопоток, поток команд примитивов отрисовки (RDP старается передавать команды примитивов отрисовки, и передаёт битмапы в крайнем случае), а также потоки устройств ввода (мышка и клавиатура).

На взаимное соотношение этих потоков и логику его (соотношения) вычисления (этакий локальный QoS) можно влиять. Для этого надо со стороны сервера зайти в ключ реестра

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermDD

и создать там для начала (если их там нет) четыре ключа:

FlowControlDisable
FlowControlDisplayBandwidth
FlowControlChannelBandwidth
FlowControlChargePostCompression

Тип у всех – DWORD 32. Функционал у ключей будет следующим.
Ключ FlowControlDisable будет определять, используется ли приоритезация вообще. Если задать единицу, то приоритезация будет выключена, если нуль – включена. Включите её.
Ключи FlowControlDisplayBandwidth и FlowControlChannelBandwidth будут определять взаимное соотношение двух потоков данных:

Поток взаимодействия с пользователем (изображение+устройства ввода)
Прочие данные (блочные устройства, буфер обмена и всё остальное)

Сами значения этих ключей не критичны; критично то, как они соотносятся. То есть, если Вы сделаете FlowControlDisplayBandwidth равным единице, а FlowControlChannelBandwidth – четырём, то соотношение будет 1:4, и на поток взаимодействия с пользователем будет выделяться 20% полосы пропускания, а на остальное – 80%. Если сделаете 15 и 60 – результат будет идентичным, так как соотношение то же самое.
Ключ FlowControlChargePostCompression будет определять, когда считается это соотношение – до сжатия или после. Нуль – это до сжатия, единица – после.

Я рекомендую для использования вида “наш удалённый сервак далеко и к нему все по RDP подключаются и в офисе и 1С работают” ставить соотношение 1:1 и считать его после сжатия. По опыту это может реально помочь в ситуации “печать большого документа с терминального сервера на локальный принтер”. Но это не догма – пробуйте, главный инструмент – знание, как это считается и работает – у Вас уже есть.

Включаем Require secure RPC communication для RDP

Данный параметр действует аналогично настройкам для Secure RPC, которые есть в разделе Security групповой политики и действуют на всю систему, только настраивается проще. Включив этот параметр Вы сделаете обязательным для всех клиентских RPC-запросов шифрование (в зависимости от настроек системы “нижняя планка” шифрования будет разной – RC4/DES или, в случае включения FIPS-140 – 3DES/AES) и использование как минимум NTLMv2 для аутентификации удалённого вызова процедур. Всегда включайте этот параметр. Есть миф про то, что он не работает во внедоменной среде. Это не так, и усиление защиты RPC никому не помешает.

Это – серверная настройка. Откройте в нужном объекте групповой политики Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security, выберите там параметр Require secure RPC communication и включите его.

Заключение

Так как все уже давно вытащили сервера на внешние площадки за бугром, то этот материал является Я надеюсь, что данный материал будет Вам полезен для оптимизации и защиты RDP. Если я что-то пропустил – прошу в комментарии.

Источник

Что такое сетевая аутентификация на уровне сети (NLA)?

Уровень аутентификации сети (NLA) — это функция безопасности, встроенная в службы удаленного рабочего стола (RDS) и протокол удаленного рабочего стола (RDP). Он требует, чтобы пользователи аутентифицировали себя перед установлением сеанса удаленного рабочего стола, обеспечивая дополнительный уровень безопасности. В отличие от традиционных соединений RDP, где экран входа в систему загружается до аутентификации, NLA гарантирует, что учетные данные проверяются перед установлением соединения. Этот метод «передней аутентификации» помогает защитить от несанкционированного доступа и потенциальных кибератак.

Как работает NLA

NLA повышает безопасность, требуя от пользователей аутентификации своих учетных данных перед созданием удаленной сессии. Вот более техническое разбиение:

Запрос на начальное подключение: Когда пользователь пытается подключиться к удаленному рабочему столу, клиент RDP отправляет запрос на подключение к серверу.
Проверка учетных данных: Перед тем как соединение будет полностью установлено, сервер запрашивает учетные данные пользователя. Клиент RDP использует поставщика поддержки безопасности учетных данных (CredSSP) для безопасной передачи этих учетных данных.
Установка безопасного канала: Если учетные данные действительны, устанавливается безопасный канал с использованием протоколов, таких как TLS или SSL, обеспечивая шифрование и защиту передаваемых данных во время сеанса от перехвата.

Исторический контекст и эволюция

NLA была впервые введена с RDP 6.0, изначально поддерживаемой в Windows Vista и последующих версиях. Она использует протокол CredSSP, который был доступен через интерфейс поставщика поддержки безопасности (SSPI) в Windows Vista. Этот протокол обеспечивает безопасную передачу учетных данных от клиента к серверу, улучшая общую безопасность.

Важность NLA

NLA необходим для защиты удаленных рабочих сред от различных угроз безопасности. Он предотвращает несанкционированный доступ даже к инициированию удаленной сессии, тем самым смягчая риски, такие как атаки методом перебора паролей, атаки отказа в обслуживании и выполнение удаленного кода.

Преимущества включения NLA

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

Усиленная безопасность

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

Предотвращает несанкционированный доступ: Требуя аутентификацию перед установлением сеанса, NLA гарантирует, что только законные пользователи могут подключаться, тем самым защищая чувствительные данные и системы.
Снижает уязвимость к угрозам: поскольку сервер проверяет учетные данные перед установлением сеанса, это снижает риск подвергания различным угрозам, которые могут использовать начальную фазу подключения.

Защита от кибератак

При требовании аутентификации перед началом сеанса NLA смягчает риск распространенных уязвимостей RDP, включая атаки отказа в обслуживании (DoS) и выполнение кода удаленно. Атаки DoS могут перегрузить сеть избыточными запросами, в то время как выполнение кода удаленно может позволить злоумышленникам запускать вредоносный код на целевой машине.

Предотвращает атаки DoS: Путем проверки пользователей перед созданием сеанса NLA предотвращает неаутентифицированные запросы, потребляющие ресурсы сервера, тем самым смягчая атаки DoS.
Предотвращает выполнение удаленного кода: поскольку аутентификация требуется заранее, вероятность эксплуатации уязвимостей выполнения удаленного кода во время фазы инициации сеанса значительно снижается.

Эффективное использование ресурсов

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

Снижает нагрузку на сервер: Избегая ненужной загрузки экрана входа для неаутентифицированных пользователей, NLA оптимизирует производительность сервера.
Улучшает эффективность сети: Обеспечение возможности инициирования сеансов только аутентифицированными пользователями помогает поддерживать оптимальную пропускную способность сети и время ответа сервера.

Возможность одностороннего входа (SSO)

NLA поддерживает единичный вход (SSO) NT, упрощая процесс аутентификации для пользователей. Эта функция позволяет пользователям аутентифицироваться один раз и получать доступ к нескольким службам без повторного ввода своих учетных данных, оптимизируя пользовательский опыт и административные издержки.

Упрощает аутентификацию пользователя: интеграция SSO с NLA позволяет пользователям без проблем получить доступ к нескольким ресурсам с помощью одного набора учетных данных.
Уменьшает административные издержки: Упрощенное управление учетными данными через SSO снижает нагрузку на ИТ-администраторов и повышает общую безопасность.

Как включить аутентификацию на уровне сети

Включение NLA — это простой процесс, который можно выполнить с помощью различных методов. Здесь мы описываем шаги по включению NLA через настройки удаленного рабочего стола и настройки системы и безопасности.

Метод 1: Включение NLA через настройки удаленного рабочего стола

Этот метод предоставляет простой подход к обеспечению безопасности удаленных подключений с помощью NLA через меню настроек Windows.

Пошаговое руководство

Откройте настройки Windows: Нажмите

Win + I

Для доступа к меню настроек Windows.
Перейдите в системные настройки: выберите «Система» в меню настроек.
Включить удаленный рабочий стол: Нажмите на «Удаленный рабочий стол» в левой панели и переключите переключатель «Включить удаленный рабочий стол».
Расширенные настройки: Нажмите на «Расширенные настройки» и убедитесь в том, что выбрана опция «Требовать использование сетевой аутентификации на уровне сети для подключения (рекомендуется)».

Преимущества использования настроек удаленного рабочего стола

Интерфейс, удобный для пользователя: настройки Windows предоставляют графический пользовательский интерфейс, что облегчает пользователям включение NLA, не углубляясь в более сложные конфигурации.

Быстрый доступ: Шаги просты и могут быть завершены за несколько минут, обеспечивая минимальные помехи в работе.

Метод 2: Включение NLA через настройки системы и безопасности

Альтернативный метод активации NLA включает использование настроек Системы и безопасности Панели управления.

Пошаговое руководство

Откройте Панель управления: Найдите «Панель управления» в строке поиска Windows и откройте ее.
Система и безопасность: Перейдите в раздел «Система и безопасность» и выберите «Система».
Разрешить удаленный доступ: нажмите «Разрешить удаленный доступ» на левой стороне экрана.
Включить NLA: На вкладке «Удаленный доступ» установите флажок «Разрешить удаленные подключения только с компьютеров, работающих с удаленным рабочим столом с сетевой аутентификацией уровня (рекомендуется)».

Преимущества использования системы и настроек безопасности

Комплексная настройка: доступ к NLA через Панель управления позволяет настраивать более детальные параметры конфигурации, обеспечивая больший контроль над политиками удаленного доступа.

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

Как отключить аутентификацию на уровне сети

При отключении NLA обычно не рекомендуется из-за рисков безопасности, но могут быть конкретные сценарии, когда это необходимо. Вот методы отключения NLA:

Метод 1: Использование системных свойств

Отключение NLA через свойства системы — это прямой метод, который можно выполнить через интерфейс Windows.

Пошаговое руководство

Открыть диалоговое окно Запуск: Нажмите

Win + R

Remote Desktop Services (RDS) is a comprehensive solution for remote access to applications, data, and desktops. With TSplus, you can enhance your RDS infrastructure with additional features and capabilities. Improve security, performance, and user experience with TSplus vs RDS.

sysdm.cpl

Welcome to our website where you can find a wide range of software products for your business needs.
Доступ к удаленным настройкам: В окне «Свойства системы» перейдите на вкладку «Удаленный».
Отключить NLA: Снимите флажок с опции «Разрешить подключения только с компьютеров, работающих с удаленным рабочим столом с сетевой аутентификацией уровня (рекомендуется)».

Риски и соображения

Увеличенная уязвимость: отключение NLA удаляет предварительную аутентификацию перед сеансом, подвергая сеть потенциальному несанкционированному доступу и различным киберугрозам.

Рекомендация: Рекомендуется отключать NLA только в случае крайней необходимости и внедрять дополнительные меры безопасности для компенсации сниженной защиты.

Метод 2: Использование редактора реестра

Отключение NLA через редактор реестра обеспечивает более продвинутый и ручной подход.

Пошаговое руководство

Открыть редактор реестра: Нажмите

Win + R

Remote Desktop Services (RDS) is a comprehensive solution for remote access to applications, data, and desktops. With TSplus, you can enhance your RDS infrastructure with additional features and capabilities. Improve security, performance, and user experience with TSplus vs RDS.

regedit

Welcome to our website where you can find a wide range of software products for your business needs.
Перейдите к ключу: Перейдите в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.
Изменить значения: измените значения «Уровень безопасности» и «Аутентификация пользователя» на

0

отключить NLA.
Перезапустите систему: перезагрузите систему, чтобы изменения вступили в силу.

Риски и соображения

Ручная настройка: Редактирование реестра требует тщательного внимания, поскольку неправильные изменения могут привести к нестабильности системы или уязвимостям безопасности.

Резервное копирование: Всегда создавайте резервную копию реестра перед внесением изменений, чтобы гарантировать возможность восстановления системы в предыдущее состояние при необходимости.

Метод 3: Использование редактора групповых политик

Для сред, управляемых через групповую политику, отключение NLA можно централизованно контролировать через редактор групповой политики.

Пошаговое руководство

Открыть редактор групповых политик: Нажмите

Win + R

Remote Desktop Services (RDS) is a comprehensive solution for remote access to applications, data, and desktops. With TSplus, you can enhance your RDS infrastructure with additional features and capabilities. Improve security, performance, and user experience with TSplus vs RDS.

gpedit.msc

Welcome to our website where you can find a wide range of software products for your business needs.
Перейдите в настройки безопасности: перейдите в Конфигурацию компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Хост сеансов удаленного рабочего стола -> Безопасность.
Отключить NLA: Найдите политику с названием «Требовать аутентификации пользователя для удаленных подключений с использованием сетевой аутентификации уровня сети» и установите ее в «Отключено».

Риски и соображения

Централизованное управление: Отключение NLA через групповую политику влияет на все управляемые системы, что потенциально увеличивает риск безопасности по всей сети.

Политические последствия: Убедитесь, что отключение NLA соответствует политикам безопасности организации и что введены альтернативные меры безопасности.

Повысьте безопасность с TSplus

На TSplus мы предлагаем передовые решения для удаленного рабочего стола, которые включают аутентификацию на уровне сети для обеспечения высочайшего уровня безопасности для ваших удаленных подключений. Исследуйте наши

TSplus Удаленный доступ

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

Заключение

Уровень аутентификации сети (NLA) является важной функцией безопасности для удаленных рабочих сред, обеспечивая надежную защиту от несанкционированного доступа и кибератак. Требуя аутентификации перед началом сеанса, NLA гарантирует, что только законные пользователи могут устанавливать удаленные соединения, обеспечивая защиту чувствительных данных и ресурсов. Включение NLA просто и может значительно улучшить безопасность вашей сети.

Для ИТ-специалистов, стремящихся укрепить защиту своей сети, внедрение NLA является критическим шагом. Однако важно взвесить преимущества безопасности по сравнению с возможной необходимостью отключения NLA, всегда отдавая приоритет защите инфраструктуры вашей сети.

TSplus Бесплатная пробная версия удаленного доступа

Ultimate альтернатива Citrix/RDS для доступа к рабочему столу/приложениям. Безопасное, экономичное, локальное/облачное.

Источник