Подключение было запрещено так как учетная запись не имеет прав для удаленного входа в систему
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в российском сегменте интернета Pyatilistnik.org. В прошлый раз мы с вами научились находить скрытые папки в Windows, разобрали их применение. Сегодня мы разберем ситуацию, когда у вас не получается подключиться к RDS ферме, получая ошибку «Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему«.
Описание инфраструктуры
И так есть RDS ферма построенная на базе Windows Server 2012 R2 и работающая в режиме HA. В какой-то момент пользователи стали обращаться в техническую поддержку, что у них возникла проблема со входом на терминальный стол и сбрасывали скриншот ошибки:
Алгоритм решения ошибки подключения к RDS ферме
Первое, что нужно проверить, это наличие нужных прав у пользователей на подключение к вашим хостам RDSH. Для этого откройте консоль управления 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 и кликаем правой кнопкой мыши по имени вашего сервера. Из контекстного меню выберите пункт «Очистить кэш«. Напоминаю, что сделать это нужно на всех контроллерах.
Подключение было запрещено так как учетная запись не имеет прав для удаленного входа в систему
Сообщения: 567
Благодарности: 146
| Конфигурация компьютера | |
| Процессор: AMD FX-8320 8-core 3.5 Ghz | |
| Материнская плата: ASUS M5A97 r2.0 | |
| Память: Corsair Vengeance Pro 32 Gb | |
| HDD: OCZ Vector SSD 240 Gb, HDD WD blue 1Tb | |
| Видеокарта: Radeon HD7850 | |
| Блок питания: OCZ 750W | |
| Монитор: hp 23′ | |
| ОС: Windows 8.1 Pro |
——-
MCSA:Windows Server 2012, MCSE:Messaging, MCSE:Communication, VCP5:Datacenter Virtualization, CCENT
Ит блог, бесплатные курсы по администрированию
Сообщения: 30
Благодарности: 4
ИО Капитана Очевидности
Сообщения: 5354
Благодарности: 1101
| Дело в том, что это доменная группа, которая была создана при создании домена. Для получения доступа необходимо добавлять пользователей в локальные группы "Пользователи удаленного рабочего стола" на нужных серверах. » |
——-
Самое совершенное оружие, которым забиты арсеналы богатых и процветающих наций, может легко уничтожить необразованного, больного, бедного и голодного. Но оно не может уничтожить невежество, болезнь, нищету и голод. (Фидель Кастро)
Почему всех осужденных за измену Родине при Сталине реабилитировали при Горбачёве по отсутствию состава преступления? Потому что при Горбачёве измену Родине перестали считать преступлением.
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://<TSVURL>
На сервере с ролью RDCB найдём значение параметра RDPFileContents в ключах реестра вида:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<Collection>\RemoteDesktops\<Collection>
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<Collection>\Applications\<RAApplication>\
Скопируем значение из параметра реестра RDPFileContents в текстовый редактор и убедимся в том, что фактически это содержимое RDP-ярлыка которое доступно нам как RemoteApp приложение с веб-странички RD Web Access и совпадает со значением, о котором мы говорили ранее .
Копируем это значение в новый параметр реестра DefaultTsvUrl (тип REG_SZ) в ключе:
Так как серверов с ролью RDCB в нашем случае два, то и соответствующую правку реестра выполняем на обоих.
После этого проверяем подключение обычным RDP-клиентом на FQDN адрес DNS RR имени нашего высоко-доступного экземпляра RDCB и убеждаемся в том, что клиент успешно перенаправлен в заданную нами коллекцию сеансов по умолчанию. Более того, теперь у нас появится возможность подключаться и на отдельные узлы HA RDCB, и даже на отдельные серверы RDSH, сеансы которых управляются RDCB. И во всех случаях клиентское подключение должно успешно попадать в коллекцию сеансов по умолчанию с перенаправлением клиента в его сессию.