Доступ по rdp – Вариант удаленного доступа к корпоративной сети предприятия посредством VPN с разграничением доступа к внутренним ресурсам и аутентификацией в AD

Содержание

Подключиться к виртуальной машине Windows по RDP | Яндекс.Облако

В образах всех версий и редакций операционной системы Windows, подготовленных для запуска в Яндекс.Облаке, включен Remote Desktop Protocol (RDP). Вы можете подключиться к виртуальной машине по протоколу RDP, когда она будет запущена (в статусе RUNNING).

Для подключения по протоколу RDP укажите публичный IP-адрес или FQDN виртуальной машины. Доступ по FQDN возможен из другой виртуальной машины Яндекс.Облака, если она подключена к той же сети. IP-адрес и FQDN можно узнать в консоли управления, в блоке Сеть на странице виртуальной машины.

Для подключения к виртуальной машине:

  1. Нажмите Пуск.
  2. В поле поиска введите Подключение к удаленному рабочему столу и выберите соответствующий пункт.
  3. В окне Подключение к удаленному рабочему столу в поле Компьютер введите публичный IP-адрес виртуальной машины, к которой необходимо подключиться.
  4. Нажмите кнопку Подключиться.
  5. Укажите параметры учетной записи:
    • Имя пользователя:
      Administrator
      .
    • Пароль: пароль, который вы задали при создании виртуальной машины.
  6. Нажмите кнопку ОК.
См. также
  1. Установите и запустите Microsoft Remote Desktop (бесплатный официальный RDP-клиент для Mac).
  2. Нажмите imageDesktop.
  3. В диалоговом окне Add Desktop в поле PC Name введите публичный IP-адрес виртуальной машины, к которой необходимо подключиться.
  4. В поле User Account выберите Add User Account.
  5. В диалоговом окне Add User Account укажите параметры учетной записи:
    • User Name: Administrator.
    • Password: пароль, который вы задали при создании виртуальной машины.
  6. Дважды нажмите кнопку Save.
  7. Подключитесь к удаленной машине двойным нажатием на созданное подключение в главном окне Microsoft Remote Desktop.
См. также
  1. Установите Remmina (бесплатный RDP-клиент для Linux) с помощью команд:

    $ sudo apt-add-repository ppa:remmina-ppa-team/remmina-next
    $ sudo apt-get update
    $ sudo apt-get install remmina remmina-plugin-rdp
    
  2. Запустите Remmina.

  3. Нажмите значок image.

  4. В блоке Profile укажите следующие данные:

    • Name: произвольное имя подключения.
    • Protocol: RDP - Remote Desktop Protocol.
  5. На вкладке Basic укажите данные для подключения и авторизации:

    • Server: публичный IP-адрес виртуальной машины, к которой необходимо подключиться.
    • User Name: Administrator.
    • Password: пароль, который вы задали при создании виртуальной машины.
  6. Нажмите кнопку Save.

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

См. также
Что дальше

Защищаем и оптимизируем RDP

Привет.

Вчера, общаясь с Иваном Никитиным, получил дельный совет осветить работу и настройку протокола 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. Если я что-то пропустил – прошу в комментарии.

Как подключиться к серверу по RDP?

RDP (Remote Desktop Protocol) — протокол, который позволяет удаленно работать с сервером.

У всех арендованных VDS на ОС Windows доступно подключение по RDP.

Если у Вас VDS с OC Linux - используйте подключение по SSH.

 

 

Доступ к серверу

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

Необходимая информация сохранена в личном кабинете в раздел “Товары” — “Виртуальные серверы” — кнопка ”Инструкция”.

 

 

В новой вкладке откроется страница с необходимой информацией.

Если Вы подключаетесь к серверу с OC Windows

Нажмите комбинацию клавиш Win+R и в открывшемся окне наберите mstsc.exe и кликните “ОК”.

В открывшемся окне укажите IP-адрес VDS и кликните кнопку “Подключить”.

Затем укажите имя пользователя и пароль из инструкции и кликните “ОК”.

При подключении к серверу приложение покажет уведомление о недоверенном сертификате.

Уведомление указывает, что сервер шифрует передаваемые данные самоподписанным SSL-сертификатом.

Отметьте поле «Больше не выводить запрос о подключениях к этому компьютеру» и нажмите «Да».

В новом окне откроется рабочий стол сервера.

 

Подключение по RDP c Ubuntu

Microsoft не выпускает клиенты для подключения по RDP на Linux.

Рекомендуем использовать клиент Remmina.

Если приложение не установлено, откройте консоль и введите команды с правами root-пользователя:

sudo apt-add-repository ppa:remmina-ppa-team/remmina-next

sudo apt-get update

sudo apt-get install remmina remmina-plugin-rdp libfreerdp-plugins-standard

После перезагрузки приложение станет доступно в меню приложению Ubuntu.

В окне приложения выберите тип подключения RDP и введите IP адрес сервера.

Затем кликните кнопку “Подключиться” и укажите имя пользователя и пароль из инструкции.

При первом подключении Remmina уточнит информацию о недоверенном сертификате безопасности. Нажмите «Принять» и вы увидите рабочий стол сервера.

 

Android и IOS

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

Microsoft выпустила официальное приложение Microsoft Remote Desktop. Приложение доступно для загрузки в Google Play и AppStore.

Для подключения со смартфона создайте в приложении новое соединение.

В открывшемся окне укажите IP адрес. В поле “User name” выберите “Add user account”.

Затем введите логин и пароль администратора. Для сохранения нажмите кнопку “Save”.

Подключение будет доступно в главном меню приложения.

При подключении приложение также запросит подтвердить сертификат безопасности.

После подтверждения сертификата вы увидите рабочий стол сервера.

 

Теневое RDP подключение к рабочему столу пользователя в Windows 10 – DOGM.NET

Помимо использования Remote Assistance, вы можете удаленно подключиться к рабочему столу пользователя Windows 10 с помощью теневого RDP подключения (Remote Desktop Shadowing). Большинство администраторов так или иначе пользовались этим функционалом для подключения к сессиям пользователей на терминальных RDS серверах с Windows Server 2012 R2 / Server 2016. Однако далеко не все знают, что теневое подключение можно использовать для удаленного просмотра и взаимодействия с рабочим столом пользователя и на десктопной Windows 10. Рассмотрим, как это работает.

Как вы помните, если попытаться удаленно подключится к компьютеру с Windows 10 через RDP, то сессия пользователя, работающего локально выбивается (даже если вы включите возможность использования нескольких одновременных RDP сессий в Windows 10). Однако вы можете подключится непосредственно подключиться к консольной сессии пользователя без блокировки его сеанса.

Предположим, вам нужно подключиться с сервера Windows Server 2012 R2 к рабочему столу пользователя, работающего локально за рабочей станцией с Windows 10.

Для теневого подключения к сессии пользователя нужно использовать стандартную RDP утилиту mstsc.exe. Формат команды такой:

Mstsc.exe /shadow:<ID сессии> /v:<Имя или IP адрес компьютера>

Также можно использовать одну из опций:

  • /prompt – запросить имя и пароль пользователя, под которым выполняется подключение (если не указано, подключение выполняется под текущим пользователем).
  • /control – режим взаимодействия с сеансом пользователя. Если параметр не задан, вы подключитесь в режиме просмотра (наблюдения) сессии пользователя, т.е. вы не сможете управлять его мышью и вводить данные с клавиатуры;
  • /noConsentPrompt – не запрашивать у пользователя подтверждение на подключение к сессии.

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

Политика находится в разделе Конфигурация компьютера ->Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов –> Узел сеансов удаленных рабочих столов –> Подключения (Policies -> Administrative Templates -> Windows components -> Remote Desktop Services -> Remote Session Host -> Connections) и называется «Установить правила удаленного управления для пользовательских сеансов служб удаленных рабочих столов» (Set rules for remote control of Remote Desktop Services user sessions).

Вместо включения политики можно выставить значение dword ключа с именем Shadow в ветке реестра HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services. Допустимые значения:

  • 0 – запретить удаленное управление;
  • 1 — полный контроль с разрешения пользователя;
  • 2 — полный контроль без разрешения пользователя;
  • 3 — наблюдение за сеансом с разрешения пользователя;
  • 4 — наблюдение за сеансом без разрешения пользователя.

По умолчанию данный ключ не задан и теневое подключение осуществляется в режиме полного контроля с разрешения пользователя.

Чтобы удаленно подключится к компьютеру через теневое подключение, у подключающейся учетной записи должны быть права администратора на компьютере, а в свойствах системы включен удаленный рабочий стол (RDP).

Запросим удаленно список сессий на рабочей станции Windows 10 командой:

qwinsta /server:192.168.11.60

Как вы видите, на данном компьютере имеется одна консольная сессия пользователя с идентификатором ID = 1.

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

Mstsc /shadow:1 /v:192.168.11.60

На экране пользователя Windows 10 появится запрос:

Запрос на удаленное подключение
Username запрашивает удаленный просмотр вашего сеанса. Вы принимаете этот запрос.

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

Совет. Для завершения теневой сессии нажмите на компьютере alt+* или ctrl+* на RDS сервере.

Если проверить сетевые соединения с помощью TCPView, можно увидеть, что взаимодействие идет через RemoteRPC (а не по протоколу RDP с портом TCP 3389). Т.е. для подключения используется случайный TCP порт из высокого диапазона RPC. На стороне подключающегося компьютера соединение устанавливает mstsc.exe, на стороне клиента подключение обрабатывает rdpsa.exe или rdpsaproxy.exe (в зависимости от билда Windows 10). Поэтому на клиенте должен быть включен RemoteRPC:

HKLM\SYSTЕM\CurrеntCоntrоlSеt\Cоntrol\Tеrminal Sеrvеr
“AllоwRemotеRPС”=dwоrd:00000001

Функционал теневого подключения Remote Desktop Shadowing работает в Windows 10 / 8.1 и Windows Server 2012 R2 /2016. Чтобы теневое подключение работало на клиентах с Windows 7 SP1 (Windows Server 2008 R2) нужен RDP клиент версии 8.1 – поэтому придется установить обновление KB2830477 (требует наличия установленных KB2574819 и KB2857650).

Таким образом Remote Desktop Shadowing можно использовать как аналог Remote Assistance (Удаленный помощник) или TeamViewer для локальной или корпоративной сети.

 

взято с сайта winitpro

Вариант удаленного доступа к корпоративной сети предприятия посредством VPN с разграничением доступа к внутренним ресурсам и аутентификацией в AD

Часто (если не всегда) перед ИТ отделом рано или поздно встает задача организации удаленного доступа в сеть предприятия, например командированным сотрудниками или попросту заболевшим. Решать эту задачу можно по-разному. Я хочу рассказать об одном из решений реально используемом в нашем холдинге. Отличается это решение от многих других тремя основными вещами:
  1. На стороне удаленного пользователя требуется минимум настройки — используются все стандартные приложения и возможности ОС Windows;
  2. Удаленный пользователь работает на сервере терминалов, что обеспечивает его необходимой средой для выполнения своих должностных обязанностей
  3. Очень гибкое управление доступом к внутренним ресурсам компании (обеспечивается TMG\ISA файрволом согласно доменной аутентификации)

Если вам это интересно, добро пожаловать под кат

Итак, сначала расскажу что нам понадобится, собственно это всего две вещи:

  • Сервер с TMG или ISA
  • Сервер терминалов

У нас оба сервера — обычные виртуальные машины, развернутые на hyper-v.
Также понадобятся две свободные подсети (уж этого добра, думаю, у всех достаточно) — для чего именно две, расскажу дальше.
Доступ пользователя к конечным ресурсам можно разделить условно на три этапа:

  1. Доступ посредством pptp в изолированную сеть vpn-клиентов
  2. Доступ по rdp на сервер терминалов
  3. Непосредственный доступ с сервера терминалов к ресурсам ЛВС компании по любой маске доступа

Ниже — общая схема подключения и описание этапов.

Доступ посредством pptp в изолированную сеть vpn-клиентов

Для реализации этого нам нужен любой pptp сервер, мы используем cisco, но ничего не мешает пробросить pptp с граничного роутера\файрвола на туже TMG\ISA, которую мы будем использовать для доступа клиентов к ресурсам и поднять pptp сервер на ней. Вот кусок конфига нашей киски, отвечающий за pptp.

vpdn enable
!
vpdn-group 1
! Default PPTP VPDN group
accept-dialin
protocol pptp
virtual-template 1
ip pmtu
ip mtu adjust

username ras_user password 7 010157010906550075581B0C4F044011530F5D2F7A743B62643
14255
username ras_guest password 7 120B541640185F3B7E2C713D653075005F025A

interface GigabitEthernet0/0.3
description Internet
encapsulation dot1Q 3
ip address x.x.x.x 255.255.255.252
ip nat outside
ip virtual-reassembly max-fragments 64 max-reassemblies 256
ip policy route-map Internet-10-144-68
no cdp enable

interface Virtual-Template1
mtu 1400
ip unnumbered GigabitEthernet0/0.3
ip access-group 170 in
ip tcp adjust-mss 1360
peer default ip address pool vpn_users
no keepalive
ppp encrypt mppe auto
ppp authentication ms-chap-v2
ppp ipcp dns 172.22.1.201
!
ip local pool vpn_users 172.22.4.1 172.22.4.250

access-list 170 permit udp 172.22.4.0 0.0.0.255 host 172.22.1.201 eq domain
access-list 170 permit tcp 172.22.4.0 0.0.0.255 host 172.22.3.1 eq 3389
access-list 170 permit icmp any any
access-list 170 permit tcp 172.22.4.0 0.0.0.255 host 172.22.3.1 eq www

Ключевой момент на данном этапе — организация сети vpn-клиентов с возможностью коннекта из нее ТОЛЬКО на сервер терминалов на порт rdp.

Доступ по rdp на сервер терминалов

Итак, наш клиент подключился к pptp серверу и имеет доступ на сервер терминалов, далее с помощью удаленного рабочего стола происходит подключение к серверу терминалов, учетные данные при этом подключении — доменная учетная запись пользователя. Тут необходимо немного пояснить:

В AD создаются группы безопасности согласно маске, грубо говоря у нас есть к примеру четыре группы ресурсов, ну скажем, разбиты по проектам. Проект1, Проект2, Проект3 и общие. Соответтственно в AD мы создадим 4 группы безопасности и сделаем первые три членами группы «общие». Группе «общие» мы разрешим вход на сервер терминалов. Далее для подключения возможности удаленного доступа любому пользователю AD мы просто будем добавлять его в соответствующую группу.

Непосредственный доступ с сервера терминалов к ресурсам ЛВС компании по любой маске доступа

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

  • В TMG внешней сетью будет являться наша ЛВС
  • Внутренней сетью будет сеть с сервером терминалов
  • На сервере терминалов ОБЯЗАТЕЛЬНО устанавливается TMG\ISA клиент, для того чтобы мы могли привязать правила к пользователям.
  • Соответственно все правила в файрволе привязываются к созданным нами ранее группам безопасности Проект1, Проект2, Проект3 и общие.

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

Настройка RDP(РДП) Windows 10: пошаговая инструкция

Традиционный сценарий использования ПК предполагает, что вы подходите к компьютеру, садитесь в кресло и физически контактируете с устройством. Однако есть и другой вариант — настройка RDP Windows 10 и использование удаленного подключения. У такого метода масса достоинств: не нужно тратить время, чтобы добраться до рабочего места, можно со слабого устройства выполнять задачи на более мощном компьютере или даже попросить более компетентного специалиста подключиться и оказать помощь.

Настройка RDP на Windows 10

Но прежде, чем браться за настройку RDP в Windows 10, убедитесь, что у вас установлена версия Pro или выше: в Home отключены нужные системные компоненты. Плюс, потребуется защитить паролем вашу учетную запись:

  • если его нет – установите через соответствующий раздел в Панели управления;
  • выберите сложный пароль. Если его можно подобрать за 4 секунды – это плохой пароль.

Включение доступа и добавление пользователей

Первый шаг настройки – корректировка настроек Windows 10, чтобы сделать соединение через интернет с использованием RDP в принципе возможным. Откройте Пуск и нажмите на шестеренку Параметры.

Откройте раздел с настройкой системы.

Просмотрите детальные сведения (можно сразу открыть этот экран комбинацией Win-Pause или Win-Break).

Запомните, какое имя указано для компьютера. Далее перейдите к настройке удаленного доступа.

Если в системе настроено автоматическое переведение в «спячку», то будет показано предупреждение.

Нажмите Электропитание и далее настройки схемы, чтобы убрать помехи к использованию RDP в Win 10.

Выберите из списка «Никогда», если хотите, чтобы ПК был постоянно доступен.

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

В подразделе удаленного рабочего стола разрешите подключаться к компьютеру.

При желании можно провести настройку RDP Windows 10 для нескольких пользователей, нажав кнопку чуть ниже переключателя.

По умолчанию доступ дается администраторам, но можно добавить произвольного пользователя (например, специально созданного для этих целей).

Впишите его имя в системе.

Пользователь появится в списке допуска к RDP.

В зависимости от версии ОС, порядок действий может несколько отличаться. Например, официальное руководство предлагает перейти к параметрам рабочего стола непосредственно в подразделе «Система» или же открыть в браузере адрес «ms-settings:remotedesktop».

Настройка и управление IP

Вместо имени компьютера часто используется IP. Чтобы его просмотреть, правым кликом по значку текущего подключения вызовите Центр управления сетями.

Далее кликните непосредственно по каналу связи с интернетом (например, Ethernet) для просмотра состояния.

В просмотре состояния нажмите Сведения.

Отобразится детальная информация, из которой нужно запомнить или записать IP.

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

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

В окне просмотра состояния перейдите к свойствам. Далее выберите протокол IPv4 и откройте детальный просмотр.

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

Традиционно маска указывается в виде 255.255.255.0, так что IP должен отличаться от адреса шлюза (его не меняем) только последним числом.

В качестве DNS можно указать используемые в вашей сети значения или же воспользоваться публичными сервисами: 8.8.8.8 от Google, 1.1.1.1 от Cloudflare и так далее.

Если используется фиксированный адрес и прямое подключение (то есть у вашего ПК «белый» IP, уточните данную информацию у своего провайдера), его также можно просмотреть при помощи внешних сервисов вроде https://2ip.ru.

Настройка порта RDP

Если система, которой выполняется RDP подключение, находится за роутером, то может потребоваться настройка порта. Для этого стандартным образом подключитесь к роутеру через веб-интерфейс (используемый для этого адрес необходимо уточнить в инструкции к оборудованию). Далее найдите в настройках раздел Port Forwarding (перенаправление портов). Потребуется добавить в него правило со следующими параметрами:

  • название может быть произвольным;
  • в качестве порта выберите 3389 TCP;
  • IP введите от своего ПК;
  • локальный порт также пропишите 3389;
  • выберите протокол TCP из списка.

После этого станет возможно подключаться удаленно и работать с ПК.

Подключение к удаленному рабочему столу в Windows 10

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

Минимальные требования для соединения – указать имя или IP целевого компьютера.

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

Если показывается уведомление об отсутствии сертификата, его допустимо проигнорировать (вы же уверены в своем ПК, верно?).

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

Важно! В отличие от настройки RDP на Windows Server 2016, здесь одновременно работать может только один пользователь, независимо от того, прямо за компьютером или удаленно. Так что если попробуете подключиться к системе, куда уже кто-то вошел, появится предупреждение. Можно или отключить активного пользователя, или самому подключиться позже.

Если вам нужно настроить РДП с одновременной работой, переходите на серверные ОС, такие как Windows Server 2012 r2.

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

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

Чтобы полностью выйти в меню Пуск удаленной машины выберите «Отключиться».

Узнайте также:

Устранение неполадок при подключении к удаленному рабочему столу

Если брандмауэр Windows не дает соединиться, откройте его настройки в параметрах.

Нажмите на изменение параметров над списком.

Укажите для удаленного рабочего стола обе галочки.

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

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

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

Выберите частную, в противном случае компьютер может быть не виден даже при работе по локальной сети.

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

По умолчанию удаленный rdp-доступ к рабочему столу контроллеров домена Active Directory есть только у членов группы администраторов домена. В этой статье мы покажем, как предоставить rdp доступ к контроллерам домена обычным пользователям без предоставления административных полномочий.

Многие могут вполне обоснованно возразить, зачем, собственно, рядовым пользователям нужен удаленный доступ к рабочему столу DC. Действительно, в small и middle-size инфраструктурах, когда всю инфраструктуру обслуживают несколько администраторов, обладающих правами администратора домена, такая необходимость вряд ли понадобится. Однако в больших корпоративных сетях, обслуживаемых большим количеством персонала, нередко возникает необходимость предоставления rdp доступа к DC (как правило к филиальным DC или RODC) различным группам администраторов серверов, команде мониторинга, дежурным администраторам и прочим техническим специалистам. Также бывают ситуации, когда на DC разворачивают сторонние службы, управляемые не доменными администраторами, которое также необходимо как-то обслуживать.

Совет. Одновременное сосуществование ролей Active Directory Domain Services и Remote Desktop Service (роль терминального сервера) на одном сервере не поддерживается. Если имеется только один физический сервер, на котором требуется развернуть и DC и терминальные службы, лучше прибегнуть к виртуализации, тем более лицензионная политика Microsoft разрешает запуск сразу двух виртуальных серверов на одной лицензии Windows Server 2016 / 2012 R2 в редакции Standard.

После повышения роли сервера до контроллера домена из оснасток управления компьютерами пропадают инструменты управления локальными пользователями и группами. При попытке открыть консоль Local Users and Groups (lusrmgr.msc). появляется ошибка:

Оснастка Local Users and Groups (lusrmgr.msc) на контроллере домена

Как вы видите, на контроллере домена отсутствуют локальные группы. Вместо локальной группы Remote Desktop Users, на DC используется встроенная доменная группа Remote Desktop Users (находятся контейнере Builtin). Управлять данной группой можно из консоли ADUC или из командной строки на DC.

Выведем состав локальной группы Remote Desktop Users на контроллере домена:

net localgroup "Remote Desktop Users"

Как вы видите, она пустая. Добавим в нее доменного пользователя itpro (в нашем примере itpro—обычный пользователь домена без административных привилегий).

net localgroup "Remote Desktop Users" /add corp\itpro

Убедимся, что пользователь был добавлен в группу

net localgroup "Remote Desktop Users"

Добавить пользователя в доменную группу из командной строкиТакже можно проверить, что теперь пользователь входит в доменную группу Remote Desktop Users.

доменная группа Remote Desktop Users

Однако и после этого пользователь не может подключиться к DC через Remote Desktop.

To sign in remotely, you need the rights to sign in Remote Desktop Services. By default only members of the Administrators group have this right. If the group you’re in doesn’t have this right, or if the right has been removed from Administrators group, you need to be granted this right manually.

rdp доступ к контроллеру доменаДело в том, что возможность подключение к RDP в системах Windows определяется политикой Allow log on through Remote Desktop Services (в Windows 2003 и ранее политика называется Allow log on through terminal services). После повышения роли сервера до DC в этой политики остается только группа Administrators (это администраторы домена)..

Чтобы дать возможность подключения членам группы Remote Desktop Users нужно нужно на контроллере домена:

  1. Запустить редактор локальной политики (gpedit.msc)
  2. Перейти в раздел Computer Configuration -> Windows settings -> Security Settings -> Local policies -> User Rights Assignment
  3. Найти политику с именем Allow log on through Remote Desktop ServicesПолитика Allow log on through Remote Desktop Services
  4. Отредактировать политику, добавив в нее доменную группу Remote Desktop Users (в формате domain\Remote Desktop Users), либо непосредственно доменного пользователя или группу (в формате domain\somegroupname)
  5. Запустить обновление локальный политик
    gpupdate /force

Обратите внимание, что требуемые группы не должны присутствовать в политике «Deny log on through Remote Desktop Services», т.к. она имеет приоритет (см статью Ограничение сетевого доступа в домене под локальными учетками).

Примечание. Чтобы разрешить пользователю локальный вход на DC (через консоль сервера), его учетную запись или группу, в которой он состоит нужно добавить также и в политику Allow log on locally. По умолчанию это право есть у следующих доменных групп
  • Account Operators
  • Administrators
  • Backup Operators
  • Print Operators
  • Server Operators.

Лучше всего создать в домене новую группу безопасности, например, AllowDCLogin и добавить в нее учетные записи пользователей, которым нужно разрешить удаленный доступ к DC. Если нужно разрешить доступ сразу на все контроллеры домена AD, вместо редактирования локальной политики на каждом DC, лучше через консоль GPMC,msc добавить группу пользователей в доменную политику Default Domain Controllers Policy (политика Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment -> Allow log on through Remote Desktop Services).

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

разрешить rdp доступ через политику Default Domain Controllers Policy

После данных изменений у указанных пользователей и групп появится возможность rdp подключения к контроллеру домена. Попробуйте по RDP подключится к DC под учетной записью пользователя. Он должен увидеть рабочий стол контроллера домена. Обычным пользователями можно предоставить право на запуск/остановку определенных служб на DC следующим образом.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *