none
Remote Desktop Gateway, неудачная попытка входа RRS feed

  • Вопрос

  • Здравствуйте, коллеги.

    Прошу посодействовать в поиске причины следующей проблемы:
    Есть RDGW-шлюз на виртуальной машине, через который пользователи подключаются к внутренней инфраструктуре компании. Согласно CAP и RAP подключаться могут все доменные пользователи на все рабочие станции без ограничений. Сам сервер имеет последние апдейты.

    Проблема заключается в том, что некоторые клиенты могут авторизовываться на сервере, и, как результат, подключаться к удаленным хостам, а некоторые - нет. Какой-либо закономерности в том, кто может авторизоваться, а кто - нет, я не нашел. При попытке подключения на этапе авторизации на шлюзе после ввода логина/пароля появляется сообщение об ошибке "Попытка входа в систему неудачна".

    Сам шлюз из интернета доступен, я пробовал пробрасывать и отдельно 443 TCP порт, и даже делал редирект всего трафика на этот шлюз. Файерволл на сервере отключен до момента вывода в прод. В логах шлюза никаких сообщений о попытках авторизации нет. 

    19 февраля 2021 г. 8:03

Все ответы

  • Здравствуйте. 

    Согласно CAP и RAP подключаться могут все доменные пользователи на все рабочие станции без ограничений. 

    - Да, только я заметил, что по каким-либо кастомным DNS записям, типа A, CNAME, подключаться не удавалось, потому:

    я отключил политику в RAP RDG_RDConnectionBrokers и оставил RDG_AllDomainComputers, установив в Network Resource - Allow users to connect any network resource. 

    Сам шлюз из интернета доступен, я пробовал пробрасывать и отдельно 443 TCP порт, и даже делал редирект всего трафика на этот шлюз. Файерволл на сервере отключен до момента вывода в прод. В логах шлюза никаких сообщений о попытках авторизации нет. 

    - Вам нужно пробросить для работы только 443 порт, указывающий на RDGateway. Ну и желательно UDP 3391.

    - Попробуйте сделать полный доступ как я и посмотреть, политики всему виной или нет.

    19 февраля 2021 г. 8:52
  • Я перефразирую:

    При текущих настройках согласно CAP я разрешаю подключаться всем доменным пользователям и админам на все пользовательские устройства. Согласно RAP я разрешаю подключаться ко всем корпоративным ресурсам. 

    На роутере на текущий момент проброшен весь трафик на RDG-сервер. Файерволл временно отключен.

    Таким образом я исключаю некорректную конфигурацию сети. Но даже несмотря на это, ошибка по-прежнему возникает. При чем только на некоторых клиентах - часть из них авторизуется на шлюзе абсолютно нормально, с регистрацией в журналах.

    Да, забыл добавить: RDG-сервер хостится на Windows Server 2016 с последними апдейтами. Подключаюсь и из Windows 10 с последними апдейтами, и с Windows 7, и с MacOS. Вдобавок ко всему, у меня есть второй аналогичный шлюз с аналогичными настройками, на котором подобные проблемы не возникают. Пробовал разные гайды в инете по решению этой проблемы, но для себя решения так и не нашел.

    20 февраля 2021 г. 11:56
  • Смотрите что в 

    Applications and Services Logs\ Microsoft\ Windows\ TerminalServices-Gateway\

    20 февраля 2021 г. 12:55
  • Смотрите что в 

    Applications and Services Logs\ Microsoft\ Windows\ TerminalServices-Gateway\

    В логах ничего нет. Там фигурируют только удачные попытки входа.

    Кстати, сделал интересное наблюдение: есть пользователь, под которым я пытаюсь авторизоваться на шлюзе. Если я авторизовываюсь из вне, то появляется ошибка "Попытка входа не удачна", если авторизовываюсь во внутренней сети, то авторизация проходит. 

    Можно подумать, что дело в сети, но некоторым пользователям удается при этом подключаться к шлюзу из вне, к тому же на шлюз перенаправлен весь трафик на роутере, так что вопрос того, что какой-то трафик не доходит до шлюза, исключен.

    24 февраля 2021 г. 14:26
  • В логах ничего нет. Там фигурируют только удачные попытки входа.

    Ну вот такого не может быть. Значит у Вас беда с клиентом, не доходит его трафик до Вашего шлюза. У меня в CAP группа пользователей, которая может пользоваться шлюзом. Для теста я удалил самого себя из группы.

    Покажите, что у Вас в политике CAP, в разделе Requirements

    А так же в RAP, раздел User Groups, Network Resource.

    • Изменено Андрей Михалевский 25 февраля 2021 г. 7:25
    • Помечено в качестве ответа asnxxx 25 февраля 2021 г. 8:47
    • Снята пометка об ответе asnxxx 25 февраля 2021 г. 8:47
    25 февраля 2021 г. 7:16
  • попробуйте вот это

    https://windowsnotes.ru/other/otklyuchaem-tcp-window-auto-tuning-v-windows-7-i-windows-server-2008/

    у нас долго(года пол боролись) была похожая проблема с подключением по РДП, помогло именно это. никак это не диагностируется и не высекается.

    • Помечено в качестве ответа asnxxx 25 февраля 2021 г. 8:47
    • Снята пометка об ответе asnxxx 25 февраля 2021 г. 8:47
    25 февраля 2021 г. 7:27
  • @Sergey2005

    К сожалению, этот вариант не помог.


    @Андрей Михалевский

    К сожалению, не могу прикрепить скриншот, поэтому опишу текстом:
    В CAP установлена проверка паролем, могут авторизовываться группы: Domain Users, Domain Admins. Группы компьютеров не указаны.

    В RAP аналогично указаны группы Domain Users и Domain Admins. Во вкладке Network Resourse выбран пункт Allow users to connect to any network resource.

    Действительно, можно подумать, что трафик не доходит, но как я и говорил, некоторые клиенты могут достучаться до RDP-шлюза и успешно на нем авторизовываются. В роутере есть только одно правило, которое перенаправляет трафик, поэтому я считаю, что оно либо работает, либо не работает. Ввиду того, что есть клиенты, у которых отсутствует проблема с подключением, я считаю, что правило работает. По этой же причине я пока не снифферил трафик, хотя, похоже, все к этому и идет.

    У меня относительно мало клиентов на Маке, но пока что на всех этих клиентах проблемы с авторизацией нет. Также есть как минимум один пользователь, о котором я знаю, на Windows 7, который тоже удачно авторизовывался на шлюзе.

    25 февраля 2021 г. 9:19
  • Тогда Вам остается только найти проблемного клиента и начать диагностику с него. Банально хотя бы с проверки телнетом доступность порта 443. Далее посмотреть, есть ли вообще коннекты на Ваш маршрутизатор.
    25 февраля 2021 г. 9:30
  • Проснифферил трафик на клиенте и на роутере - пакеты ходят с клиентского компьютера до RDGW, RDGW отвечает.
    В логах RDGW по-прежнему нет никакой информации.

    Остается дело в самом сервере.

    3 марта 2021 г. 13:07
  • С какой ОС заходит клиент ? Куда ? На какую ОС ? Возможно дело не в RDgateway, а в политиках безопасности и шифрования сервера.

    Мои удаленные юзеры которые имеют не обновленные Win 7 с такими настройками по умолчанию не могут войти:

    По мере снятия галки NLA, приходилось еще Encryption Level в Low переводить. Но это в рамках теста, по хорошему я их заставлял ставить апдейты.

    Попробуйте посмотреть: Applications and Services Logs -> Microsoft -> Windows -> Terminal-Services-RemoteConnectionManager -> Operational


    4 марта 2021 г. 6:32
  • Андрей, спасибо за наводку.

    На домашнем и рабочем компьютерах стоит Windows 10 Pro с последними апдейтами, на RDGW-шлюзе - Windows Server 2016 с последними апдейтами. Попробую включить все возможные методы шифрования из поддерживаемых, как и поддержку всех версий TLS. На текущий момент поддерживается только версия 1.2. А также в рамках тестов отключу на шлюзе все политики, раздаваемые контроллером.

    4 марта 2021 г. 10:20
  • На выходных пробовал отключать политики, раздаваемые контроллером, а также включал поддержку ненадежных методов шифрования и поддержку устаревших версий TSL, SSL, однако, это тоже не привело к результату.

    11 марта 2021 г. 8:09
  • Кроме того, как смотреть в момент после неудачного входа, все логи RDGateway и сервера, на который пытаются зайти, идей нет. Что-то в любом случае должно быть.

    Windows Logs\Security\

    Custom Views\Server Roles\

    Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operationa

    Application and Services Logs\Microsoft\Windows\Terminal Services-Gateway\


    11 марта 2021 г. 10:02