«Попытка входа в систему не удалась» для аутентификации шлюза TS (RD)
Я использую TS Gateway, чтобы разрешить удаленный доступ для наших сотрудников уже несколько месяцев, и все было хорошо. Пользователи либо подключаются к традиционному рабочему столу терминального сервера, либо заходят на наш веб-сайт и запускают приложение TS RemoteApp - в обоих случаях соединение маршрутизируется через шлюз TS.
Однако сегодня утром я пришел на работу и обнаружил, что аутентификация пользователей через шлюз TS прекратилась, каждый раз возвращая сообщение «Попытка входа в систему не удалась», как показано на изображении, даже если учетные данные верны.
Следует отметить, что все работает нормально, если исключить шлюз, эти проблемы вызывает компонент шлюза TS.
Пользователи сталкиваются с этой проблемой независимо от того, подключаются ли они через XP SP3, Vista или 7.
На сервере в общей сложности 4 записи появляются в журнале безопасности Windows в одно и то же время для каждой неудачной попытки входа в систему: два сообщения 4624 «Учетная запись была успешно зарегистрирована» для пользователя, сразу за которыми следуют два сообщения 4634 «Учетная запись была зарегистрирована. выкл. Это говорит о том, что сервер принимает учетные данные как правильные, а затем загружает пользователя. В журналах NPS и сервера терминалов вообще ничего не записывается.
Перезагрузка ничего не меняет. Также не происходит полного удаления и переустановки ролей NPS и сервера терминалов. Я не понимаю, как это может произойти внезапно без предупреждения.
Любые предложения будут ценны.
Эта проблема мучила меня в течение нескольких месяцев на машине SBS 2008, но никогда не была настолько критичной, чтобы принять безумные меры для ее исправления.
После удаления и повторной установки службы шлюза служб терминалов, которая все еще не работает, я перешел в диспетчер IIS → Сайты → Веб-приложения SBS → Rpc → Проверка подлинности и обнаружил, что включена только «Обычная проверка подлинности».
Хотя подробностей об этой конкретной ошибке в Интернете мало, я заметил, что Outlook Anywhere, похоже, меняет схемы аутентификации IIS. Поскольку это SBS, я подумал, что Exchange и TS Gateway могут бороться за настройку аутентификации.
Я включил «Аутентификацию Windows», а затем выполнил сброс IIS. Когда IIS вернулся в онлайн, я смог подключиться через TS Gateway к двум серверам и по крайней мере одной рабочей станции. Я подключался и отключался несколько раз, и у меня не было проблем.
Я не могу гарантировать, что это будет навсегда, но я определенно надеюсь.
РЕДАКТИРОВАТЬ: после внесения этого изменения у меня не было проблем с TS Gateway.
Хорошо, вот ответ?
2k8r2 и iis7
TSGateway неоднократно запрашивает учетные данные, но не входит в систему ...
Оказывается, TSGateway не выполняет подключение и аутентификацию, а IIS делает. Сюрприз, я знаю….
TSGateway только фильтрует и направляет.
Итак, теперь, какая часть IIS выполняет подключение и аутентификацию для TSGateway? Я не знаю. И, видимо, никто другой тоже. Но если вы испортите настройки аутентификации RDWEB, RPC, RPCWCERT, Default WEB SITE, Authdiscover, вы можете заставить его работать ...
Это хорошая статья. Но, как видите, с ними это тоже выстрел в темноте.
ПРИМЕЧАНИЕ. Очевидно, перенаправление веб-сайта по умолчанию прерывает связь с RDWeb и, следовательно, с TSGateway.
HTTP - перенаправление HTTPS…
Похоже, мой веб-сайт по умолчанию работает по протоколу HTTP, но я хотел, чтобы он был доступен для пользователей HTTP. Поэтому я создал веб-сайт перенаправления для перенаправления HTTP-запросов на веб-сайт по умолчанию как HTTPS. Что отлично работает, но остановило мою аутентификацию TSGateway. (Я думаю, это произошло потому, что порт 80 использовался веб-сайтом перенаправления. И по какой-то причине RDWEB использует порт 80, а также 443 для связи…)
Кстати, если вы отключите параметр Требовать SSL в настройках SSL на веб-сайте по умолчанию в IIS, он будет работать правильно и будет делать то же самое ...
В любом случае, начните покупать, чтобы RDWEB работал корректно, тогда работайте на TSGateway.
RDWEB должен иметь только: Включена анонимная проверка подлинности. Для AutoDiscovery должна быть включена анонимная, базовая проверка подлинности и проверка подлинности Windows. OWA: только базовый уровень. RPC: должен иметь: базовую проверку подлинности и проверку подлинности Windows. RPCWCert: ничего не должно быть включено. По крайней мере, это настройки в Моих настройках…
Удачи.
Роберт
У меня была похожая проблема. Я обнаружил, что мне нужно отредактировать IIS Manager → Sites → SBS Web Applications → Rpc With Cert → Authentication и добавил проверку подлинности Windows. Потом выполнил и IISRESET и все заработало как надо.
Служба Windows шлюза служб терминалов продолжала у нас отказывать.
В отсутствие чего-либо полезного в журналах событий я просто заставляю планировщик задач «запускать net start tsgateway» несколько раз каждый час. Ужасно, но с тех пор жалоб нет.
Были те же проблемы, что и исходный пост. Я также перенаправлял веб-сайт по умолчанию в / RDWeb / Pages / en-US, как только я отключил это перенаправление, все работало как обычно.
Честно говоря, я не понимаю, как это вообще вызвало проблему.
У меня была аналогичная проблема. Экран входа в шлюз все время всплывал. Журналы безопасности сервера показывали особые привилегии входа в систему, входа в систему и выхода из системы для каждой попытки. Журналы шлюза ничего не показали.
Попробовав все, я заметил, что область в нижней части экрана входа в систему шлюза, которая должна показывать домен, была пустой. Я добавил домен на экран входа в систему с именем пользователя: домен \ имя пользователя и вуаля, все работает как надо.
Это была трата примерно 4 или 5 часов моей жизни на поиск решений и попытку сложных исправлений ... Надеюсь, это сэкономит время кому-то еще ...
Если у вас возникла эта проблема на SBS 2008, я предлагаю использовать комбинацию анализатора соответствия рекомендациям SBS 2008 и мастера «исправить мою сеть» консоли SBS (Сеть -> Связь -> Исправить мою сеть). SBS привередлив и иногда отменяет настройки, заданные вручную, поэтому по возможности лучше использовать мастеров.
В моем случае BPA сказал запустить "get-outlookanywhere | set-outlookanywhere -iisauthenticationmethods basic, ntlm -clientauthenticationmethod basic" в командной консоли Exchange, и мастер "fix my network" также внес исправления.
У меня был билет в службу поддержки MS, поэтому я попросил их посмотреть на это. Они просто изменили мировоззрение на NTLM и VIOLA!
Та же проблема и для меня: SBS2008 внезапно начал сообщать "сбой входа в систему" всякий раз, когда использовался шлюз TS. Обнаружено, что сайт RPCwithCert в IIS не имеет метода проверки подлинности, установлен флажок Проверка подлинности Windows, и теперь он снова работает ....
Что касается меня, у меня все настроено для SSO, затем я внес несколько изменений, и он сломался. Я мог попасть на сайт RemoteApps, но при попытке запустить приложение мне было предложено ввести мои учетные данные, а внизу окна входа в систему появилось сообщение «попытка входа не удалась». Благодаря сообщению Роберта сверху я узнал, что это перенаправление, которое я вставил в IIS7. Моя установка - это один сервер, действующий как шлюз, брокер и веб-доступ. Я оставил все работать под «Веб-сайтом по умолчанию». Чтобы расширить сообщение Роберта, я оставил перенаправление на месте, но проверил «Только запросы перенаправления к контенту в этом каталоге (не в подкаталогах)», так как я хочу, чтобы запросы к корневому сайту попадали в RDWeb, и это отлично работает для меня.