Подключение было запрещено так как учетная запись не имеет прав для удаленного входа в систему
собственно выходит ошибка: подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему
Что сделано: на клиентской машине в свойствах компьютера пользователь уже имеет доступ, далее в локальной политиике безопасности в назначении прав пользователя : разрешить вход в систему через службу удаленных раб столов: Администраторы. пользователи удаленного раб стола
в чем дело? может еще где то надо настроить? машина клиентская находится в актив директори
(0) Иди к Системным Администраторам, и жалобно проси их дать тебе это право. 🙂
(1) И причем тут вообще ОСь? Если у тебя нет права на том ПК (сервере) куда ты подключаешься 🙂
+(0) >>> разрешить вход в систему через службу удаленных раб столов: Администраторы. пользователи удаленного раб стола
Вот тоже самое, только на сервере 🙂
Подключение было запрещено так как учетная запись не имеет прав для удаленного входа в систему
Не предлагать включить в группу пользователей Удаленных подключений.
Не предлагать через локальные политики Разрешение входа в систему через службы терминалов.
Не предлагать давать права локального админа пользователю.
Яду выпить?
Не предлагаю.
(1)Хороший вариант, ну после того как RDP для пользователя заработает.
(2) Не предлагай.
P.S. Windiws server 2008r2 standart.
Т.е. надо понимать так: 1. надо дать права. 2. Дать права не предлагать :)))
Вопрос где?
(4) Права уже даны, а по RDP не подключается.
(5)Почему не подключается?
Парни вроде не пятница, ну что то притормаживаю, от НГ все ещё отойти не могу)))
Ну значит не те права дал.
(8) Не на столько уж я user что бы дать не те права.
(9) позвать админа тоже не предлагать? 🙂
(10) Ну ты конечно не поверишь, сам админ))
Группа Пользователи удаленного рабочего стола и «Удаленные подключения» в твоем понимании одно и тоже?
Пользователь в группу Пользователи входит?
(11) Действительно, не поверю :)) ИМХО админ, который не может настроить RDP — не совсем админ или совсем не админ (на выбор) :))
И полностью текст ошибки приведи
Парни совсем затупил. Извините. Настраивал RDP не на том компе, а пытался подключиться на тот котором надо было. Все Спасибо
(13) Пусть будет по твоему.
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа. Фредерик Брукс-младший
Подключение было запрещено так как учетная запись не имеет прав для удаленного входа в систему
Индивидуальный RDP-доступ для администратора
Статья поможет сисадминам небольших предприятий организовать простое и достаточно безопасное удаленное администрирование, используя малоизвестные возможности реализации RDP на серверах под управлением Windows
Администраторам, обслуживающим малые предприятия в качестве аутсорсера (модное ругательство, да-да), часто приходится сталкиваться с ситуацией, когда необходим терминальный доступ к серверу организации из своего дома или с другого рабочего места за пределами LAN. При этом требуется обеспечить определенную безопасность подопечного предприятия от взломов, минимизировав собственные затраты — умственные и физические.
Сделать это можно, организовав для администрирования отдельный канал доступа по RDP, независимый от стандартно существующего, используемого другими сотрудниками, работающими в терминале.
Условия работы и постановка задачи
Давайте рассмотрим характерную ситуацию малого предприятия.
Руководство которого всячески экономит на ИТ-сегменте:
— В организации есть десяток-полтора рабочих станций и выделенный сервер, который, что называется, и жнец, и швец и на дуде игрец. То есть одновременно выполняет функции контроллера домена, файл-сервера, принт-сервера и так далее.
— Доступ в Интернет, как правило, в таких случаях организуется через дешевый роутер, а на прокси-сервере и услугах его администрирования контора экономит, благо безлимит ныне доступен любому.
— Внешний IP может быть статическим или же динамическим, и тогда, чтобы обратиться к серверу по имени, используется сервер динамического DNS.
Свойства нового RDP — соединения
В простейшем случае удаленное администрирование организуется через переадресацию порта 3389 с роутера на терминальный сервер (так называемый port mapping).
Но что делать, если на этом же сервере работает в терминальном режиме «1С» и тем самым в группу пользователей удаленных рабочих столов входит большая часть сотрудников фирмы?
Ситуация, как правило, усугубляется тем, что руководство и работники предприятия знать не хотят о требованиях ИТ-безопасности, т.е. не желают своевременно менять пароли и соблюдать требования к их стойкости. То есть каждый желающий, зная IP конторы и логин с паролем любого из сотрудников, которому разрешен терминальный доступ, может из любой точки планеты зайти на сервер.
Конечно же, данная ситуация совершенно неприемлема. Однако как быть, если организация «экономит на спичках» и не хочет платить за услуги по устройству VPN?
Хотя, положа руку на сердце, следует признать тот факт, что организация VPN для удаленного доступа одного человека — это явная избыточность. Да и нагружать несчастный сервер еще и функциями управления VPN — это верный путь к жалобам пользователей на невыносимо медленную его работу.
Относительно приемлемый и в то же время низкобюджетный режим ИТ-безопасности подобных организаций основывается на разделении доступа к сессиям RDP:
— сотрудники предприятия имеют терминальный доступ к серверу лишь из LAN;
— администратор предприятия — вдобавок к этому еще из Интернета.
Реализуется такая схема созданием дублирующего слушателя RDP и прописыванием соответствующих разрешений для него.
В результате персонал предприятия, входящий в группу пользователей удаленных рабочих столов, будет исключительно изнутри сети обращаться к серверу по стандартному порту 3389, а администратор — еще и снаружи по определенным им самим портам на роутере и сервере.
При этом сотрудники предприятия, даже зная номер открытого наружу порта, получить из Интернета терминальный доступ к серверу под своими логинами и паролями не смогут.
Создание нового слушателя RDP и его настройка
Итак, запускаем на сервере regedit и экспортируем узел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ ControlYTerminal Server\WinStations\RDP-Tcp в текстовый reg-файл, после чего открываем файл на редактирование. Собственно говоря, нас интересуют лишь две строки:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Terminal Server\WinStations\RDP-Tcp] «PortNumber»=dword:0 0 0 0 0d3d
Определяемся, на каком порту сервер (и роутер, конечно) будет нас слушать. ну, скажем, 4477 или 117D в шест-надцатеричке.
Правим название будущей ветки реестра на RDP-Tcp2 и номер порта на 117D. Можете назначить любой порт, не используемый предприятием, но все же избегайте тех, что задействованы широко распространенными сетевыми сервисами.
У вас должно получиться:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Terminal Server\WinStations\RDP-Tcp2] «PortNumber»=dword:0000117d
Сохраняем файл реестра, а потом двойным щелчком импортируем его.
Перезагружаем сервер и запускаем оснастку «Конфигурация узла сеансов удаленных рабочих столов» -tsconfig.msc (в Windows 2003 — «Настройка служб терминалов» — tscc.msc).
В свойствах интересующего нас подключения RDP-Tcp2 открываем вкладку «Безопасность» и удаляем там всех, кроме группы администраторов предприятия.
После этого не забудьте разрешить входящее подключение на порт 4477 в брандмауэре.
Теперь осталось лишь организовать переадресацию с роутера и проверить результат работы. В параметрах NAT роутера создаем виртуальный сервер, внешний порт 4477, внутренний 4477 на вашем терминальном сервере.
Пробуем соединиться. Запускаем на своем домашнем компьютере «Подключение к удаленному рабочему столу» по нужному белому IP или заблаговременно созданному на сервере dyndns.org адресу company.dyndns.org:4477. На приглашение ввести логин и пароль вводим данные администратора. Получаем доступ к удаленному рабочему столу подопечного сервера.
Для проверки завершаем сеанс и вновь подключаемся к company.dyndns.org:4477, но теперь вводим логин и пароль пользователя, входящего только в группу пользователей удаленных рабочих столов, но не в группу администраторов. Если настроено все правильно, то должны получить ответ сервера:
Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему.
Теперь осталось только удалить с роутера старый про-брос стандартного порта 3389, через который мы и настроили нового слушателя RDP, если, конечно, вы работали удаленно.
Цель достигнута: сотрудники компании изолированы внутри локальной сети организации, а вы можете администрировать сервер из любого удобного для вас места.
Дополнительная защита протокола
Что можно сделать еще? Ну, во-первых, защитить соединение. Во вкладке «Общие» свойств нашего нового RDP-подключения выставляем уровень шифрования в «Высокий» либо «FIPS-совместимый». Этот параметр потребует указания сертификата сервера — вполне подойдет автоматически созданный.
Во-вторых, если у вас Windows Server 2008, т.е. версия RDP 6.0 и выше, можно включить дополнительно проверку подлинности со стороны сети (NLA).
Суть ее в том, что клиент авторизуется на сервере до создания терминальной сессии, что служит защитой против DoS-атак, заставляющих сервер создавать RDP-сессии по каждому обращению на соответствующий порт.
Включается это флажком на той же самой вкладке «Общие -> Разрешить подключаться только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети».
Однако включение шифрования, и в особенности технологии NLA, требует в качестве клиентских машин Windows ХР SP3 и более поздние версии ОС. Причем если шифрование протокола на ХР после установки третьего сервис-пака будет работать сразу и «прозрачно», то для возможности проверки подлинности на уровне сети вам еще придется вручную добавить новый криптопровайдер CredSSP.
Но то, как это сделать, выходит за рамки данной статьи. Всех интересующихся отсылаю к публикации Руслана Кар-манова «Защищаем и оптимизируем RDP» [1].
Ну, и, в-третьих, забота о стойкости логина и пароля администратора к brut-force атакам, разумеется, полностью на вашей совести.
Конечно же, VPN, IPSec и прочие порождения сумрачного гения ИТ-технологов требуют обращать больше внимания на безопасность. но ведь все в конечном счете определяется тем, сколько работодатель готов потратить на труд администратора, и этот рецепт — лишь для случаев жесткой экономии.
Позаимствовано: Системный Администратор 06 / 2012 (Андрей Бусыгин)
Windows Server 2012 R2 Remote Desktop Connection Broker — Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему.
В продолжение темы, ранее описанной в заметке Windows Server 2012 R2 Remote Desktop Connection Broker — Невозможно подключиться к высоко-доступной ферме RDS — Подключение было запрещено… один из комментаторов к этой заметке навёл на идею использовать для подключения к высоко-доступному экземпляру RDCB вместо специально настроенного RDP-файла на стороне клиентов, настройку параметра реестра DefaultTsvUrl на серверах RDCB.
В общем случае, как я понял из статьи Ask the Performance Team Blog — Walkthrough on Session hint / TSVUrl on Windows Server 2012 , этот параметр реестра используется для совместимости RDCB в Windows Server 2012/R2 с RDP клиентами, которые не умеют принимать дополнительные параметры через RDP-файлы. Этот параметр способен принимать имя основной коллекции сеансов, к которой должны перенаправляться все пользователи, подключающиеся к серверам RDCB без явной передачи параметров нужной коллекции. В случае если у вас используется всего одна коллекция, то настройка параметра реестра DefaultTsvUrl на серверах RDCB снимет необходимость в формировании и распространении по клиентам специально сформированного RDP-файла .
В первую очередь, нам потребуется определить имя коллекции, к которой должны подключаться все клиенты, не имеющий явной направленности в ту или иную коллекцию. Это имя имеет специальный формат вида tsv://
На сервере с ролью RDCB найдём значение параметра RDPFileContents в ключах реестра вида:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\\RemoteDesktops\
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\\Applications\\
Скопируем значение из параметра реестра RDPFileContents в текстовый редактор и убедимся в том, что фактически это содержимое RDP-ярлыка которое доступно нам как RemoteApp приложение с веб-странички RD Web Access и совпадает со значением, о котором мы говорили ранее .
Копируем это значение в новый параметр реестра DefaultTsvUrl (тип REG_SZ) в ключе:
Так как серверов с ролью RDCB в нашем случае два, то и соответствующую правку реестра выполняем на обоих.
После этого проверяем подключение обычным RDP-клиентом на FQDN адрес DNS RR имени нашего высоко-доступного экземпляра RDCB и убеждаемся в том, что клиент успешно перенаправлен в заданную нами коллекцию сеансов по умолчанию. Более того, теперь у нас появится возможность подключаться и на отдельные узлы HA RDCB, и даже на отдельные серверы RDSH, сеансы которых управляются RDCB. И во всех случаях клиентское подключение должно успешно попадать в коллекцию сеансов по умолчанию с перенаправлением клиента в его сессию.