Доступ к требуемому сеансу отклонен в Windows Server
Доступ к требуемому сеансу отклонен в Windows Server
Добрый день! Уважаемые читатели и гости блога pyatilistnik.org, в прошлый раз мы с вами разобрали синий экран с ошибкой 0x00000050, который мы благополучно вылечили. Сегодня я расскажу, про одну, небольшую ошибку, которую начинающий системный администратор, может встретить в своей практике при подключении к удаленным рабочим столам, на терминальную ферму или выделенный хост и звучит она вот так: Доступ к требуемому сеансу отклонен в Windows Server 2008 R2 по Windows Server 2016.
Описание ситуации
Есть сервер терминалов Windows Server 2012 R2, при попытке зайти на участника фермы, хотя это может быть и независимый хост, учетная запись, которая точно имеет права на удаленный доступ по RDp, получает ошибку входа:
Решение
Как оказалось, все очень просто и банально. В моей организации, как и во многих есть инфраструктура активного каталога Active Directory, и по best practice (рекомендации вендора) системный администратор, за своим локальным компьютером, должен сидеть под обычной пользовательской учетной записью, без административных прав, а вот уже подключаться к серверам, от имени другой. В итоге, я запускал клиента удаленных рабочих столов с ключом /admin, в итоге прав не было у локальной учетной записи, так как она не являлась администратором.
Тут два варианта решения проблемы:
- Запускать клиента mstsc /admin от имени учетной записи имеющей административные права на локальный компьютер
- Либо запускать удаленный рабочий стол, без ключа /admin
В итоге при следующем подключении я не увидел ошибку: Доступ к требуемому сеансу отклонен в Windows Server 2008 R2 ни в Windows Server 2012 R2.
Про смартфон — цены, обзоры и реальные отзывы покупателей
На сайте Pro-Smartfon найдёте отзывы и обзоры топовых смартфонов 2017 года. Всё о плюсах и минусах мобильных телефонов. Свежие фотографии, цены и реальные отзывы покупателей о лучших смартфонах
Rdp доступ к требуемому сеансу отклонен
Доступ к требуемому сеансу отклонен в Windows Server
Доступ к требуемому сеансу отклонен в Windows Server
Добрый день! Уважаемые читатели и гости блога pyatilistnik.org, в прошлый раз мы с вами разобрали синий экран с ошибкой 0x00000050, который мы благополучно вылечили. Сегодня я расскажу, про одну, небольшую ошибку, которую начинающий системный администратор, может встретить в своей практике при подключении к удаленным рабочим столам, на терминальную ферму или выделенный хост и звучит она вот так: Доступ к требуемому сеансу отклонен в Windows Server 2008 R2 по Windows Server 2016.
Описание ситуации
Есть сервер терминалов Windows Server 2012 R2, при попытке зайти на участника фермы, хотя это может быть и независимый хост, учетная запись, которая точно имеет права на удаленный доступ по RDp, получает ошибку входа:
Решение
Как оказалось, все очень просто и банально. В моей организации, как и во многих есть инфраструктура активного каталога Active Directory, и по best practice (рекомендации вендора) системный администратор, за своим локальным компьютером, должен сидеть под обычной пользовательской учетной записью, без административных прав, а вот уже подключаться к серверам, от имени другой. В итоге, я запускал клиента удаленных рабочих столов с ключом /admin, в итоге прав не было у локальной учетной записи, так как она не являлась администратором.
Тут два варианта решения проблемы:
- Запускать клиента mstsc /admin от имени учетной записи имеющей административные права на локальный компьютер
- Либо запускать удаленный рабочий стол, без ключа /admin
В итоге при следующем подключении я не увидел ошибку: Доступ к требуемому сеансу отклонен в Windows Server 2008 R2 ни в Windows Server 2012 R2.
Данная ошибка может возникать, когда пользователь пытается подключиться к консольной сессии.
При этом подключаться как обычный терминальный пользователь ничего не мешает.. но эта галочка в тонком клиенте может быть где-то далеко запрятана и слаучайно поставлена.. вот и разбирайтесь почему от админа пускает а от простого юзера ни в какую.
При использовании виндового mstsc данная проблема возникать не должна, если только Вы не используете при подключении параметр /admin.
Miller777
Внезапно перестали подключаться юзеры. При попытке подключения выдает ошибку: «удалённый сеанс отключён поскольку отсутствуют доступные серверы лицензирования». Не могут подключиться ни обычные пользователи, ни администраторы.
Проблема и решение:
Помог запуск mstsc с параметром:
По-моему, раньше это называлось «нулевая сессия».
В таком варианте подключиться смог. Юзеров с правами пользователей по-прежнему не пускает. Ошибка: «Доступ к требуемому сеансу отклонен».
В диспетчере сервера — ошибки службы лицензирования рабочих столов. Отсутствует сервер лицензирования.
Настройки удаленных рабочих столов и их службы лицензирования — правильные. Поиграл настройками, удалил и заново прописал сервер лицензирования, изменил режим лицензирования с «на пользователя» на «на устройство» и обратно «на пользоателя».
После этого ошибка у юзеров при подключении сменилась на другую:
«Удаленный компьютер отключил сеанс, из-за ошибки в протоколе лицензирования».
Прочитал, что надо удалить ключ в реестре:
HKLMSYSTEMCurrentControlSetControlTe rminal ServerRCMGrace Period
Проблема в том, что просто так его не удалить даже с правами администратора. Редактор реестра нужно запускать с правами системы. Для этого служит PCTools от Марка Руссиновича, инструкция здесь:
После этого перезагрузился и сеансы у пользователей заработали.
Были бы лицензии — их, вероятно, можно было бы просто переактивировать.
Windows 2008 доступ к требуемому сеансу отклонен
Вопрос
Ответы
проверьте групповые политики\конфигурация компьютера\конфигурация Windows\параметры безопасности\назначения прав пользователя\разрешить вход в систему через службу терминалов Здесь должны быть 2 группы- Администраторы и Пользователи удаленного рабочего стола, если нет, то добавьте.
Все ответы
юзер должен быть в группе пользователи удаленного рабочего стола, администраторы в ней по умолчанию.
пользователь входит в группу «Remote Desktop Users»?
В доменную учетку добавил группу «пользователи удаленного рабочего стола», теперь получаю сообщение:
—————————
Подключение к удаленному рабочему столу
—————————
Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему.
—————————
ОК Справка
—————————
проверьте групповые политики\конфигурация компьютера\конфигурация Windows\параметры безопасности\назначения прав пользователя\разрешить вход в систему через службу терминалов Здесь должны быть 2 группы- Администраторы и Пользователи удаленного рабочего стола, если нет, то добавьте.
Попробуйте добавить доменную учетную запись в локальную (не доменную) группу пользователи удаленного рабочего стола на указанном сервере.
Благодарю за ответы. Последовал вашим рекомендациям и получил то, что требовалось.
я столкнулся с такойже проблеммой но никак не могу найти где этот пункт в server 2008 R2 в русской версии
групповые политики\конфигурация компьютера\конфигурация Windows\параметры безопасности\назначения прав пользователя\
дальше даже близко ничего нет про права доступа и учетки
но есть в другой ветке — локальных политиках — там добавил и получил странную вещь
сервер у меня стоит в гипервизоре
так вот с других виртуальных машин захожу без проблемм а с физических компов всети получаю ошибке как у автора
при этом с виртуалок заходит как с серверных ОС так и с вин7/вин ХР
так вот с других виртуальных машин захожу без проблемм а с физических компов всети получаю ошибке как у автора
не заходит только с той учеткой, с которой запускаю RDP
тоесть если я залогинился на комп, то с этойже учетки я не могу подключится к серверу
при этом с другой учеткой нормально заходит, даже если она гдето уже включена
тоесть если я залогинился на комп, то с этойже учетки я не могу подключится к серверу
если я захожу на комп с учеткой «А» и подключаюсь по рдп с учеткой «А» — то НЕ пускает
если я захожу на комп с учеткой «Б» и подключаюсь по рдп с учеткой «Б» — то НЕ пускает
если я захожу на комп с учеткой «А» и подключаюсь по рдп с учеткой «Б» — то пускает
если я захожу на комп с учеткой «Б» и подключаюсь по рдп с учеткой «А» — то пускает
при этом если если я с компа «А» подключаюсь с учеткой «Б» но при этом она уже включена на другом компе то тоже пускает (ну и наоборот тоже)
если я захожу на комп с учеткой «А» и подключаюсь по рдп с учеткой «А» — то НЕ пускает
если я захожу на комп с учеткой «Б» и подключаюсь по рдп с учеткой «Б» — то НЕ пускает
если я захожу на комп с учеткой «А» и подключаюсь по рдп с учеткой «Б» — то пускает
если я захожу на комп с учеткой «Б» и подключаюсь по рдп с учеткой «А» — то пускает
при этом если если я с компа «А» подключаюсь с учеткой «Б» но при этом она уже включена на другом компе то тоже пускает (ну и наоборот тоже)
На сервере терминалов проверьте данную настройку:
Administrative Tools > Terminal Services Configuration > Server Settings > «The Restrict each user to one session»
Что у Вас там установлено?
Данный форум является бесплатным сервисом Microsoft с целью оказания посильной помощи пользователям и повышения уровня знаний о продуктах Microsoft. Информация, представленная на форуме, распространяется «как есть» без официальной ответственности компании Microsoft.
Добрый день! Столкнулся с описанной проблемой. В домене есть группа «1» с большим количеством доменных учетных записей пользователей. Эта группа входит в группу «Пользователи удаленного рабочего стола» на сервере терминалов, который состоит в этом же домене. Таким вот образом все учетки группы «1» упешно ходят по RDP на сервер терминалов.
Одна из учетных записей (моя), состоящая в группе «1», ранее обладала правами доменного администратора. После того, как я лишил ее этих прав, а также прав локального администратора на моей машине, больше я не могу попасть под этой учеткой на сервер терминалов. Если опять дать ей права доменного админа — все работает. Остальные учетки как работали, так и работают.
Однако обнаружил такую вещь: под этой учеткой попасть на сервер терминалов я не могу только со своей машины. Пробовал с машины другого сотрудника (не администратора) — работает, пробовал с домашней Linux-машины (через VPN) — работает.