Подключение к удаленному рабочему столу в домене windows
Обновлено: 04.07.2024
По умолчанию удаленный RDP-доступ к рабочему столу контроллеров домена Active Directory разрешен только членам группы администраторов домена (Domain Admins). В этой статье мы покажем, как предоставить RDP доступ к контроллерам домена обычным пользователям без предоставления административных полномочий.
Многие могут вполне обоснованно возразить, зачем, собственно, рядовым пользователям нужен удаленный доступ к рабочему столу DC. Действительно, в small и middle-size инфраструктурах, когда всю инфраструктуру обслуживают несколько администраторов, обладающих правами администратора домена, такая необходимость вряд ли понадобится. Обычно хватает возможностей делегирования пользователям административных полномочия в Active Directory или предоставления прав с помощью PowerShell Just Enough Administration (JEA).
Однако в больших корпоративных сетях, обслуживаемых большим количеством персонала, нередко возникает необходимость предоставления RDP доступа к DC (как правило к филиальным DC или RODC) различным группам администраторов серверов, команде мониторинга, дежурным администраторам и прочим техническим специалистам. Также бывают ситуации, когда на DC разворачивают сторонние службы, управляемые не доменными администраторами, которое также необходимо как-то обслуживать.
Совет. Microsoft не рекомендует одновременно устанавливать роли Active Directory Domain Services и Remote Desktop Service (роль терминального сервера) на один сервер. Если имеется только один физический сервер, на котором требуется развернуть и DC и терминальные службы, лучше прибегнуть к виртуализации, тем более лицензионная политика Microsoft разрешает запуск сразу двух виртуальных серверов на одной лицензии Windows Server с редакцией Standard.Чтобы войти в систему удаленно, вам нужно право на вход через службы удаленных рабочих столов
После повышения роли сервера до контроллера домена в оснастке управления компьютером пропадает возможность управления локальными пользователями и группами. При попытке открыть консоль Local Users and Groups (lusrmgr.msc). появляется ошибка:
The computer xxx is a domain controller. This snip-in cannot be used on a domain controller. Domain accounts are managed with the Active Directory Users and Computers snap-in.
Как вы видите, на контроллере домена отсутствуют локальные группы. Вместо локальной группы 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"
Однако и после этого пользователь не может подключиться к DC через Remote Desktop с ошибкой:
Политика “Разрешить вход в систему через службу удаленных рабочих столов”
Чтобы разрешить доменному пользователю или группе удаленное RDP подключение к Windows, необходимо предоставить ему право SeRemoteInteractiveLogonRight. Вы можете предоставить это полномочие с помощью политики Allow log on through Remote Desktop Services (Разрешить вход в систему через службу удаленных рабочих столов).
В Windows Server 2003 и ранее политика называется Allow log on through terminal services.Чтобы разрешить RDP подключение членам группы Remote Desktop Users, нужно изменить настройку этой политики на контроллере домена:
- Запустите редактор локальной политики ( gpedit.msc );
- Перейдите в раздел Computer Configuration -> Windows settings -> Security Settings -> Local policies -> User Rights Assignment;
- Найти политику с именем Allow log on through Remote Desktop Services (Разрешить вход в систему через службу удаленных рабочих столов);
Обратите внимание, что группа, которые вы добавили в политику Allow log on through Remote Desktop Services, не должны присутствовать в политике “Deny log on through Remote Desktop Services”, т.к. она имеет приоритет (см статью Ограничение сетевого доступа в домене под локальными учетками). Также, если вы ограничиваете список компьютеров, на которые могут логиниться пользователи, нужно добавить имя сервера в свойствах учетной записи в AD (поле Log on to, атрибут LogonWorkstations).
Примечание. Чтобы разрешить пользователю локальный вход на DC (через консоль сервера), его учетную запись или группу, нужно добавить также в политику Allow log on locally. По умолчанию это право есть у следующих доменных групп:- Account Operators
- Administrators
- Backup Operators
- Print Operators
- Server Operators.
Лучше всего создать в домене новую группу безопасности, например, AllowDCLogin. Затем нужно добавить в нее учетные записи пользователей, которым нужно разрешить удаленный доступ к DC. Если нужно разрешить доступ сразу на все контроллеры домена AD, вместо редактирования локальной политики на каждом DC, лучше через консоль управления доменными политиками ( GPMC.msc ) добавить группу пользователей в доменную политику Default Domain Controllers Policy (политика Allow log on through Remote Desktop Services находится в разделе Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment).
Важно. Если вы изменяете доменную политику, не забудьте добавить в нее группы администраторов домена/предприятия, иначе они потеряют удаленный доступ к контроллерам домена.
Теперь пользователи, которых вы добавили в политику, смогут подключаться к рабочему столу контроллеру домена по RDP.
Если вам нужно предоставить обычным пользователями права на запуск/остановку определенных служб на DC, воспользуйтесь следующей инструкцией.Доступ к требуемому сеансу RDP отклонен
В нескорых случаях при подключении по RDP к контроллеру домена, вы можете получить ошибку:
Если вы подключаетесь к DC под неадминистративной учетной записью, это может быть связано с двумя проблемами:
С момента выпуска Windows 10 поддерживает удаленные подключения к ПК, подключенным к Active Directory. Начиная с версии 1607 Windows 10, можно также подключаться к удаленному компьютеру, присоединенному к Azure Active Directory (Azure AD). Начиная с Windows 10, версия 1809, можно использовать биометрию для проверки подлинности на удаленном сеансе рабочего стола.
Настройка
Убедитесь, что на клиентских КОМПЬЮТЕРАх, которые вы используете для подключения к удаленному компьютеру, отключается функция remote Credential GuardWindows 10 версии 1607.
На компьютере, к который необходимо подключиться:
откройте свойства системы для удаленного компьютера.
Включите функцию Разрешить удаленные подключения к этому компьютеру и выберите вариант Разрешать подключения только от компьютеров с удаленным рабочим столом с сетевой проверкой подлинности.
Если кроме пользователя, который присоединил компьютер к Azure AD, никто больше не собирается использовать удаленное подключение, дополнительные настройки не требуются. Чтобы разрешить дополнительным пользователям или группам подключаться к компьютеру, необходимо разрешить удаленные подключения для указанных пользователей или групп. Пользователи могут добавляться вручную или с помощью политик MDM:
Добавление пользователей вручную
Вы можете указать отдельные учетные записи Azure AD для удаленных подключений, запуская следующий комдлет PowerShell:
где атрибут upN-attribute-of-your-user — это имя профиля пользователя в C:\Users, который создается на основе атрибута DisplayName в Azure AD.
Эта команда работает только для пользователей устройств AADJ, уже добавленных в любую из локальных групп (администраторов). В противном случае эта команда бросает приведенную ниже ошибку. Пример:
- только для пользователя облака: "Нет такого глобального пользователя или группы: имя"
- для синхронизированного пользователя: "Нет такого глобального пользователя или группы: имя"
Для устройств, Windows 10 версии 1703 или более ранних версий, пользователь должен сначала войти на удаленное устройство перед попыткой удаленного подключения.
Начиная с Windows 10 версии 1709, можно добавить других пользователей Azure **** AD в группу Администраторы на устройстве в Параметры и ограничить удаленные учетные данные администраторам. **** При возникновении проблем с удаленным подключение убедитесь, что оба устройства присоединены к Azure AD и что доверенный платформенный модуль работает правильно на обоих устройствах.
Добавление пользователей с помощью политики
Начиная с Windows 10 версии 2004 года вы можете добавлять пользователей или группы Azure AD в удаленные пользователи настольных компьютеров с помощью политик MDM, как описано в описании управления группой локальных администраторов на устройствах Azure AD.
Если вы не можете подключиться с помощью удаленного подключения к рабочему столу 6.0, необходимо отключить новые функции RDP 6.0 и вернуться к RDP 5.0, внося несколько изменений в файл RDP. Подробные сведения см. в этой статье поддержки.
Поддерживаемые конфигурации
В таблице ниже перечислены поддерживаемые конфигурации для удаленного подключения к компьютеру с поддержкой Azure AD:
Если клиент RDP работает Windows Server 2016 или Windows Server 2019, чтобы иметь возможность подключения к компьютерам с Azure Active Directory-подключенными компьютерами, он должен разрешить запросы на проверку подлинности на основе шифрования общедоступных ключей для пользователей (PKU2U)для использования удостоверений в Интернете.
Настроить удаленный рабочий стол Windows на VDS можно за несколько минут. Фактически для этого нужно создать сервер и поднять на нем операционную систему. Из среды Windows подключение к удаленному десктопу будет выполняться через стандартную утилиту, а вот на других ОС понадобится дополнительное приложение.
Для чего нужен удаленный рабочий стол Windows на VDS
Самый распространенный случай — решение корпоративных задач. Например, управление бухгалтерией. Сама база находится на сервере компании, а сотрудники получают к ней доступ через удаленный рабочий стол. Это безопасно и удобно — например, системный администратор может настроить ежедневное сохранение резервной копии. Если что-то пойдет не так, достаточно будет откатиться к предыдущему состоянию.
Можно также использовать VDS с Windows в качестве игрового сервера или платформы для различных ботов: для торговли, соцсетей, SEO-накрутки.
Настройка VDS с Windows Server
Для начала нужно создать сервер с установленной Виндоус. Посмотрим на примере хостинга Timeweb, как это сделать.
Откройте панель управления VDS.
Нажмите на кнопку «Создать сервер».
Укажите название сервера и комментарий, если есть такая необходимость.
Выберите версию Windows Server, которую хотите установить. Доступны версии от 2012 R2 до 2019.
Настройте конфигурацию сервера. Например, для Windows Server 2019 нужен процессор с частотой не менее 2 ядер 1,4 ГГц и 2 ГБ ОЗУ (для установки сервера с рабочим столом). Абсолютный минимум объема диска — 32 ГБ. Лучше сразу брать с запасом, особенно если вы будете активно пользоваться удаленным рабочим столом.
Добавьте SSH-ключ и включите защиту от DDoS, если это необходимо.
Оплатите стоимость тарифа. В нее уже входит лицензия на Windows, так что цена окончательная.
После успешного создания сервера на почту придет письмо от хостера. В нем указаны данные для доступа к VDS с Windows. Не удаляйте его — эта информация понадобится для подключения к удаленному рабочему столу.
Производительные VDS с минимальным steal time — 15 дней бесплатно
Дарим 15 дней на тарифе Scarlett! Закажи VDS, внеси платеж от 50 рублей и активируй промокод community15.
Подключение к удаленному рабочему столу
Для подключения к VDS с Windows Server используется протокол RDP. Встроенное приложение для его выполнения есть только на Windows. На других ОС для подключения через RDP потребуется установка сторонних приложений.
Подключение по RDP c Windows
Откройте меню «Пуск» и найдите утилиту «Подключение к удаленному рабочему столу». Например, на Виндоус 10 она находится в разделе «Стандартные Windows». Можно также воспользоваться встроенным поиском или утилитой «Выполнить»: нажать на сочетание клавиш Win+R и ввести запрос mstsc.
Введите в окне программы IP-адрес сервера, к которому хотите подключиться. Он указан в письме, которое прислал хостер. Нажмите «Подключить».
Выберите учетную запись для авторизации и введите пароль. Эти данные хостер присылает на почту.
При первом подключении может появиться предупреждение о недостоверном сертификате. Причина такого поведения — шифрование соединения сертификатом, который выдает не авторизованный центр, а сам сервер. Однако это не значит, что у вас есть проблемы с безопасностью. Подключение по RDP зашифровано, так что можете спокойно пропускать предупреждение. Чтобы оно не раздражало, отметьте пункт «Больше не выводить запрос о подключениях к этому компьютеру».
Если нужно перенести небольшое количество файлов, то самый простой способ — использование буфера обмена. Вы копируете файл на локальной машине, затем подключаетесь к удаленному рабочему столу и вставляете файл.
Если нужно перемещать большое количество файлов, то гораздо удобнее подключить диск. На локальном компьютере с Win это делается так:
Подключитесь к удаленному рабочему столу с помощью встроенной утилиты.
Перейдите на вкладку «Локальные ресурсы».
Выберите диски или другие источники.
После выбора локальных источников вы можете получить к ним доступ с удаленного рабочего стола на VDS с Windows Server.
Подключение по RDP c Linux
На Linux нет официального протокола для подключения через RDP к Win-серверу. Однако это не проблема. Установить соединение можно с помощью клиента Remmina.
В качестве примера установим утилиту на Ubuntu. Откройте терминал и выполните следующие команды:
После установки клиент появится в списке приложений. Найдите его и запустите. Нажмите на плюсик для добавления нового подключения и введите уже знакомые данные: IP-адрес сервера, логин, пароль. Главное — выбрать в строке Protocol значение RDP (Remote Desktop Protocol).
Нажмите на кнопку Save, чтобы сохранить новое подключение. Оно отобразится в списке. Чтобы использовать его, щелкните по нему два раза левой кнопкой.
При первом подключении может появиться предупреждение о недоверенном сертификате безопасности. Ситуация такая же, как в случае с WIndows. Никакой угрозы безопасности нет, поэтому просто игнорируйте предупреждение. Нажмите ОК в появившемся окне.
Подключение с macOS
На macOS для подключения к удаленному рабочему столу на Windows Server используется фирменное приложение Microsoft, которое называется Remote Desktop. Его можно установить из App Store.
Запустите программу и нажмите на кнопку New.
В Connection name укажите любое имя для подключения — например, VDS Windows.
В строке PC name пропишите IP-адрес сервера, к которому вы будете подключаться.
В разделе Credentials укажите логин и пароль для подключения к VDS.
После сохранения настроек в списке подключений появится новое соединение. Выделите его и нажмите на кнопку Start или используйте двойной клик.
При первом подключении может появиться предупреждение о недоверенном сертификате. Нажмите на кнопку «Показать сертификат» и отметьте пункт «Всегда доверять». Больше предупреждение не будет появляться. Проблем с безопасностью из-за этого не возникнет.
RDP на Android и iOS
Подключиться к удаленному рабочему столу с Windows Server можно и с мобильного устройства. На Android и iOS для этого используется фирменное приложение Microsoft, которое называется Remote Desktop.
На обеих мобильных системах подключение через RDP настраивается одинаково.
Запустите приложение и нажмите на плюс для добавления нового соединения.
Выберите тип «Рабочий стол» (Desktop).
В поле «Имя ПК» укажите адрес сервера.
Впишите имя администратора и пароль.
При появлении предупреждения о недоверенном сертификате отметьте пункт «Больше не спрашивать» и нажмите «ОК».
После успешного подключения вы увидите удаленный рабочий стол, размещенный на VDS с Windows Server.
Добавление новых пользователей на Windows Server
Выше мы разобрали ситуацию подключения к удаленному рабочему столу только одного пользователя — владельца сервиса. Однако часто нужно открыть доступ для нескольких человек. Для этого нужно добавить новых пользователей и раздать другим людям данные для авторизации.
Первым делом нужно установить и настроить DNS-сервер, Active Directory и DHCP-сервер. Подробно об этом я рассказывал в материале о первоначальной настройке Windows Server 2012 R2. В более новых версиях принципиально ничего не изменилось.
После первоначальной настройки WS добавьте новых пользователей.
Откройте «Диспетчер серверов».
Раскройте меню «Средства» и выберите в списке «Пользователи и компьютеры Active Directory».
Кликните правой кнопкой по пункту User и выберите опцию «Создать» — «Пользователь».
Укажите имя, фамилию, полное имя, имя входа пользователя.
Введите пароль и отметьте чекбокс «Требовать смены пароля при следующем входе». В таком случае пользователь получит предложение установить свой пароль при первой авторизации.
Проверьте сводную информацию и нажмите «Готово» для сохранения пользователя.
Пользователей можно объединять в группы, а группы — размещать внутри подразделений. Это актуально при настройке сервера компании, когда удаленный рабочий стол требуется большому количеству сотрудников с разными обязанностями.
В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (Remote Desktop Gateway или RDG) на отдельном сервере с Windows Server 2019. Действия будут аналогичны для Windows Server 2012 и 2016 (даже, в основных моментах, 2008 R2). Предполагается, что в нашей инфраструктуре уже имеются:
1. Служба каталогов Active Directory — настроено по инструкции Как установить роль контроллера домена на Windows Server.
Пошагово, мы выполним следующие действия:
Установка роли
Открываем Диспетчер серверов:
Переходим в Управление - Добавить роли и компоненты:
При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):
На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:
Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:
Ставим галочку Службы удаленных рабочих столов:
Дополнительные компоненты нам не нужны:
. просто нажимаем Далее.
На странице служб удаленных рабочих столов идем дальше:
Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты:
Откроется окно для настроек политик:
. нажимаем Далее.
Откроется окно роли IIS:
. также нажимаем Далее.
При выборе служб ролей веб-сервера ничего не меняем:
В последнем окне ставим галочку Автоматический перезапуск конечного сервера, если требуется:
Нажимаем Установить:
Дожидаемся окончания установки роли:
Сервер может уйти в перезагрузку.
Настройка RDG
Для настройки Microsoft Remote Desktop Gateway мы создадим группу компьютеров в Active Directory, настроим политику для RDG и создадим сертификат.
Создание групп для терминальных серверов
Политика ресурсов позволит задать нам конкретные серверы, на которые терминальный шлюз позволит нам подключаться. Для этого мы откроем консоль Active Directory - Users and computers (Пользователи и компьютеры Active Directory) и создаем группу:
* в данном примере мы создаем группу All terminals в организационном юните Servers Group. Это группа безопасности (Security), локальная в домене (Domain local).
Добавим в нашу группу терминальные серверы:
* в данном примере у нас используются два сервера — Terminal-1 и Terminal-2.
Закрываем консоль Active Directory - Users and computers.
Настройка политик
Для предоставления доступа к нашим терминальным серверам, создадим политики для подключений и ресурсов.
В диспетчере сервера переходим в Средства - Remote Desktop Services - Диспетчер шлюза удаленных рабочих столов:
Раскрываем сервер - кликаем правой кнопкой по Политики - выбираем Создание новых политик безопасности:
Устанавливаем переключатель в положении Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов (рекомендуется):
Даем название политике:
Задаем параметры авторизации:
* мы указали, что пользователи должны подтверждать право вводом пароля, также мы указали, что для применения политики они должны принадлежать группе Domain Users.
В следующем окне есть возможность настроить ограничения использования удаленного рабочего стола. При желании, можно их настроить:
* в нашем случае ограничений нет. При необходимости, устанавливаем переключатель в положение Отключить перенаправление для следующих типов клиентских устройств и оставляем галочки пункты для ограничений.
Далее настраиваем временные ограничения использования удаленного подключения. Если в этом есть необходимость, оставляем галочки в состоянии Включить и указываем количество минут, по прошествии которых сеанс будет отключен:
В следующем окне мы увидим вне введенные настройки:
Откроется страница создания политики для авторизации ресурса — задаем для нее название:
Указываем группу пользователей, для которой будет применяться политика:
* как и при создании первой политики, мы добавили группу Domain Users.
Теперь выбираем группу ресурсов, на которую будет разрешен доступ со шлюза терминалов:
* мы выбрали группу, созданную нами ранее в AD.
Указываем разрешенный для подключения порт или диапазон портов:
* в данном примере мы разрешим подключение по порту 3389, который используется по умолчанию для RDP.
Нажимаем Готово:
Политики будут созданы.
Настройка сертификата
Запускаем «Диспетчер шлюза удаленных рабочих столов» - кликаем правой кнопкой по названию нашего сервера - выбираем Свойства:
Переходим на вкладку Сертификат SSL:
Выбираем вариант Создать сомозаверяющий сертификат и кликаем по Создать и импортировать сертификат:
Задаем или оставляем имя для сертификата - нажимаем OK:
Мы увидим информацию о создании сертификата:
Консоль диспетчера шлюза перестанет показывать ошибки и предупреждения:
Сервер готов к работе.
Подключение к серверу терминалов через шлюз
Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.
Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:
* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.
Переходим на вкладку Дополнительно и кликаем по Параметры:
Переключаем параметр приложения в положение Использовать следующие параметры сервера шлюза удаленных рабочих столов и указываем внешнее имя сервера:
* важно указать именно имя сервера, а не IP-адрес. В моем примере имя сервера rdp.dmosk.local (данное имя не является правильным внешним, но это только пример).
Кликаем Подключить:
Если мы используем самозаверенный сертификат, приложение выдаст ошибку. Кликаем по Просмотреть сертификат:
Переходим на вкладку Состав и кликаем Копировать в файл:
Указываем путь для выгрузки файла:
Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:
Выбираем Локальный компьютер - Далее:
В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:
После снова пробуем подключиться к удаленному рабочему столу через шлюз:
Система запросит логин и пароль для подключения (возможно, дважды) — вводим данные для учетной записи с правами на подключение (на основе настройки политики RDG).
Настройка Remoteapp через Gateway
Предположим, у нас есть опубликованное приложение Remoteapp и мы хотим подключаться к терминальному серверу через настроенный шлюз. Для этого открываем rdp-файл приложения на редактирование (например, блокнотом) и вносим в него изменения:
- gatewayhostname:s:rdg.dmosk.local — добавленная строка. Настройка говорит, что если при подключении к серверу нужно использовать шлюз, то это должен быт rdg.dmosk.local.
- gatewayusagemethod:i:1 — отредактированная строка. Указывает, что необходимо использовать шлюз.
Несколько терминальных серверов и dns round robin
При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:
Для решения переходим в настройку шлюза - кликаем правой кнопкой по Политики авторизации ресурсов и выбираем Управление локальными группами компьютеров:
Выбираем нужную группу компьютеров и нажимаем Свойства:
* в моем случае это была единственная группа, созданная по умолчанию.
На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:
Теперь подключение будет выполняться без ошибок.
Возможные ошибки
При подключении мы можем столкнуть со следующими ошибками.
1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.
Причиной является отсутствие пользователя, под которым идет подключение к шлюзу, в группе, которой разрешено использование политики. Для решения проблемы проверяем настройки политики — группы пользователей, которым разрешено использование политики и к каким ресурсам разрешено подключение. В итоге, наш пользователь должен быть в нужной группе, а терминальный сервер, к которому идет подключение должен быть указан в соответствующей группе ресурсов.
3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.
В данном случае нужно проверить, какой сертификат привязан к RDG. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.
Читайте также: