учетная запись пользователя не имеет прав для удаленного входа в систему
Учетная запись пользователя не имеет прав для удаленного входа в систему
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в российском сегменте интернета Pyatilistnik.org. В прошлый раз мы с вами научились находить скрытые папки в Windows, разобрали их применение. Сегодня мы разберем ситуацию, когда у вас не получается подключиться к RDS ферме, получая ошибку «Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему«.
Описание инфраструктуры
И так есть RDS ферма построенная на базе Windows Server 2012 R2 и работающая в режиме HA. В какой-то момент пользователи стали обращаться в техническую поддержку, что у них возникла проблема со входом на терминальный стол и сбрасывали скриншот ошибки:
Алгоритм решения ошибки подключения к RDS ферме
На вкладке «Группы пользователей» будут перечислены пользователи и группы, для которых вы позволили удаленное подключение к вашим хостам подключений.
По сути данные группы будут добавлены на каждом хосте RDCH в локальную группу «Пользователи удаленного рабочего стола». Убедитесь, что на нужных хостах RDSH и RDCB (Брокерах подключений). ваши группы присутствуют. Если их нет то добавьте их в ручную.
Если вы до сих пор получаете ошибку с отсутствием прав на подключение, то тут может быть вариант, как у меня из-за ошибки на DNS сервере. В большинстве случаев при работе с RDS фермой используют балансировку подключений DNS Round-Robin, так как не у всех есть оборудования по типу KEMP. Round-Robin, это поочередное переключение одного DNS имени на разные ip-адреса. За счет этого каждый пользователь уже будет обращаться к следующей записи. В моем случае есть DNS запись, по которой подключаются все пользователи к RDS ферме terminal.root.pyatilistnik.org. Данное DNS имя ссылается на два брокера подключений RDCB01 и RDCB02. В результате этого пользователи поочередно обращаются к разным брокерам. Так же может быть ситуация, что брокеров вообще может не быть и у вас есть две и более A записи ссылающихся на разные ip-адреса ваших хостов с терминальной службой. Проверить, это можно через команду nslookup или командлет Resolve-DnsName.
Зная это, необходимо со стороны клиента проверить во, что разрешается ваше имя терминальной фермы, откройте командную строку и введите:
Как видим в моем примере имя terminal ответило, как два хоста с адресами 192.168.31.10 и 192.168.31.1. Теперь сделаем nslookup к данным хостам:
В итоге я увидел, что у одной записи не верное значение, оно ссылается на контроллер домена dc01.root.pyatilistnik.org.
Как показало дальнейшее разбирательство один из коллег не правильно восстановил удаленные ранее записи. В результате этого, каждый второй пользователь за счет чередования Round-Robin хотел подключиться к контроллеру домена, и логично, что он получал ошибку об отсутствии прав на него.
Тоже самое можно вычислить и с помощью PowerShell, где вам необходимо выполнить:
В итоге я вернул все в привычное русло, но есть еще два нюанса, это локальный кэш на пользовательских машинах и на самом DNS сервере, который нужно почистить. Первым делом на всех ваших контроллерах домена открываем оснастку DNS и кликаем правой кнопкой мыши по имени вашего сервера. Из контекстного меню выберите пункт «Очистить кэш«. Напоминаю, что сделать это нужно на всех контроллерах.
Учетная запись пользователя не имеет прав для удаленного входа в систему
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
Вопрос
Ответы
проверьте групповые политики\конфигурация компьютера\конфигурация 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 на сервер терминалов.
В продолжение темы, ранее описанной в заметке Windows Server 2012 R2 Remote Desktop Connection Broker — Невозможно подключиться к высоко-доступной ферме RDS — Подключение было запрещено… один из комментаторов к этой заметке навёл на идею использовать для подключения к высоко-доступному экземпляру RDCB вместо специально настроенного RDP-файла на стороне клиентов, настройку параметра реестра DefaultTsvUrl на серверах RDCB.
В первую очередь, нам потребуется определить имя коллекции, к которой должны подключаться все клиенты, не имеющий явной направленности в ту или иную коллекцию. Это имя имеет специальный формат вида 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\ \
Копируем это значение в новый параметр реестра DefaultTsvUrl (тип REG_SZ) в ключе:
Так как серверов с ролью RDCB в нашем случае два, то и соответствующую правку реестра выполняем на обоих.
После этого проверяем подключение обычным RDP-клиентом на FQDN адрес DNS RR имени нашего высоко-доступного экземпляра RDCB и убеждаемся в том, что клиент успешно перенаправлен в заданную нами коллекцию сеансов по умолчанию. Более того, теперь у нас появится возможность подключаться и на отдельные узлы HA RDCB, и даже на отдельные серверы RDSH, сеансы которых управляются RDCB. И во всех случаях клиентское подключение должно успешно попадать в коллекцию сеансов по умолчанию с перенаправлением клиента в его сессию.
В соединении было отказано, поскольку учетная запись пользователя не авторизована для удаленного входа
В соединении было отказано, поскольку учетная запись пользователя не авторизована для удаленного входа
Если вы столкнулись с этой проблемой, вам необходимо выполнить следующие задачи, чтобы решить эту проблему:
1] Проверка группы пользователей удаленного рабочего стола
Если у группы «Пользователи удаленного рабочего стола» нет прав для вашей учетной записи, которую вы используете для создания удаленного подключения, вы можете столкнуться с этой проблемой. Поэтому выполните следующие действия, чтобы убедиться, что ваша учетная запись является членом группы «Пользователи удаленного рабочего стола».
Откройте командную строку и выполните эту команду:
После этого нажмите кнопку ОК и сохраните настройки. Теперь проверьте, можете ли вы подключиться к удаленному хосту или нет.
2] Добавление пользователя в группу безопасности
Вы можете разрешить или запретить пользователю вход в систему через Службы удаленных рабочих столов. Если у вас нет правильной настройки, вы не сможете использовать эту функцию.
Чтобы подтвердить этот параметр, вам нужно открыть панель локальной политики безопасности. Введите эту команду в поле Начать поиск и нажмите Enter-
После сохранения изменений перезагрузите компьютер и попробуйте подключиться к хосту.
3] Проверка группы пользователей удаленного рабочего стола
Существует служба, которая должна быть запущена и должна быть правильно настроена. Вы должны убедиться, что служба запущена и работает. Для этого откройте панель «Услуги». Вы можете найти «услуги» в окне поиска на панели задач и открыть диспетчер служб. После этого найдите службу с именем Службы удаленных рабочих столов и дважды щелкните ее, чтобы открыть Свойства.
Дважды щелкните по нему и сохраните настройки.
Перезагрузите компьютер и проверьте, можете ли вы подключиться к удаленному хосту или нет. Я надеюсь, что это поможет вам решить проблему.
Удаленное подключение было отказано в Windows 10
Удаленный рабочий стол – это один из самых простых способов удаленного решения проблем на компьютере, но, похоже, у этой функции есть некоторые проблемы в Windows 10.
Пользователи сообщали об ошибке Удаленное соединение было отказано в Windows 10, поэтому давайте посмотрим, как это исправить.
Что делать, если в удаленном соединении было отказано
Удаленное подключение было отклонено, поскольку учетная запись пользователя не авторизована для удаленного входа [FIX]
Решение 1. Изменить настройки пульта
По словам пользователей, они не могут запустить сеанс Remote Destkop из-за этой ошибки, поэтому для решения этой проблемы вам необходимо проверить настройки Remote на вашем хост-компьютере. Для этого выполните следующие действия:
Если у вас есть группа «Пользователи удаленного рабочего стола», обязательно добавьте ее, выполнив действия, описанные выше.
Решение 2. Изменить параметры локальной политики безопасности
Немногие пользователи утверждают, что вы можете решить эту проблему, удалив локальный и перемещаемый профиль. Мы не знаем, работает ли это решение, но вы можете попробовать его.
Пользователи сообщали, что ошибка Удаленное подключение было отклонено появляется, если для входа службы удаленных рабочих столов установлено значение «Локальная система». Чтобы изменить это, выполните следующие действия:
После изменения входа службы удаленных рабочих столов в службу сети, проблема должна быть полностью решена.
Решение 5 – измените свой реестр
Одним из предложенных пользователями решений является редактирование вашего реестра. Чтобы решить эту проблему, вам нужно предоставить определенные разрешения группе пользователей. Прежде чем мы начнем, мы должны упомянуть, что редактирование вашего реестра может вызвать определенные проблемы, поэтому вы можете создать резервную копию вашего реестра на всякий случай. Чтобы отредактировать реестр, сделайте следующее:
Решение 6 – воссоздать доменные сертификаты
После небольшого исследования немногие пользователи обнаружили, что их сервер входа в систему предупреждает их о событии 29, и именно это предупреждение стало причиной этой проблемы. Чтобы устранить эту проблему, вам необходимо заново создать доменные сертификаты, выполнив следующие действия:
После удаления сертификата вам необходимо запросить новый, выполнив следующие действия:
Наконец, вам просто нужно проверить сертификат. Для выполнения этого шага вы должны быть членом группы администраторов домена или иметь соответствующие привилегии, назначенные вашей учетной записи вашим администратором. Чтобы проверить Kerberos Key Distribution Center (KDC), выполните следующие действия:
Если процедура прошла успешно, перезагрузите контроллер домена и сервер, к которому вы пытаетесь подключиться, и проблема должна быть решена.
По словам пользователей, вы можете решить эту проблему, создав новый DWORD в реестре. Для этого выполните следующие действия:
Решение 9. Добавьте пользователей домена вместо пользователей удаленного рабочего стола
Пользователи сообщали об ошибке Удаленное соединение было отказано на их ПК при попытке использовать функцию удаленного рабочего стола, и, по их мнению, по какой-то странной причине они не смогли добавить пользователей удаленного рабочего стола. Чтобы обойти эту проблему, предлагается добавить пользователей домена вместо пользователей удаленного рабочего стола. После этого эта ошибка должна быть исправлена.
Исправлено – «Удаленное соединение было отклонено из-за комбинации имени пользователя и пароля» Windows 10
Решение 2. Используйте команду rasphone
Решение 3. Создание DWORD совместимости NTLMv2
Вы должны быть в состоянии решить эту проблему, добавив определенный DWORD в реестр. Для этого выполните следующие действия: