Статус: Активный участник
Группы: Участники
Зарегистрирован: 20.08.2020(UTC) Сообщений: 40  Откуда: Москва Сказал(а) «Спасибо»: 7 раз
|
Ситуация такая. На компьютерах локальной сети (на всех) в свойствах доступа к удаленному рабочему столу выбран чекбокс "Разрешить подключения только... с проверкой NLA". На все компы с любого компа в лок. сети я могу успешно зайти через RDP с помощью смарт-карты.
На сервере S-RD установлена роль шлюза RD. И когда я пытаюсь удаленно через шлюз подключиться к какому-либо компу в лок. сети ситуация следующая:
1. с помощью логина-пароля я подключаюсь сначала к шлюзу и далее - к компу. Все ОК.
2. если же использовать смарт-карту - то на шлюз подключаюсь нормально, а вот с компа идет отлуп - "Удаленный компьютер ... требует проверки NLA" и т.п.
3. и самое занятное: если пытаюсь удаленно подключиться к самому S-RD (через шлюз, каковым он же и является) - то к шлюзу коннект нормальный, а к компу (то бишь к нему же самому) - та же ошибка NLA.
То есть основных вопроса два:
- почему ошибка NLA возникает только при подключении со смарт-картой?
- почему один и тот же комп одновременно ведет себя по разному?
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 20.08.2020(UTC) Сообщений: 40 Откуда: Москва Сказал(а) «Спасибо»: 7 раз
|
Еще один эксперимент поставил.
На том же сервере S-RD есть роль веб-доступа к удаленным столам. В RemoteApp публикую приложение mstsc.exe и через https:/.....RDWeb запускаю. Коннект к шлюзу (через смарт-карту) проходит нормально, открывается окошко клиента mstsc. В нем ввожу имя компа в локальной сети - и появляется окно с ошибкой, но другой - "Произошла ошибка проверки подлинности. В пакете безопасности отсутствуют учетные данные. Удаленный комп - ххх".
Причем если на втором этапе (при коннекте к локальному компу) использовать логин-пароль - коннект нормальный
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Вставлю 5 копеек, раз уж тема похожа на то с чем сейчас бьюсь - NLA бывает разная. Так, у меня на старый сервер подключаюсь (по паролю, клиент поддерживает протокол 8.1), тупит при подключении примерно минуту, щелкаю на "замочек" пишет "подлинность проверена с помощью Kerberos", а на новый сервер подключаюсь (с того же компьютера, по паролю, чуть быстрее) пишет "подлинность проверена с помощью сертификата и Kerberos".
Вот тоже гадаю в чем разница и как убрать задержку. На прошлой неделе перевел доменный УЦ на SHA256 и выдал новые сертификаты контроллерам домена (для центра ключей керберос) (автозапрос каждые 8 часов долбил запрос с ключом 512 бит и ловил отказ, вручную запросил с ключом 2048 бит - выпустило и заработало), так вообще сразу несколько компов перестали цепляться к старому серверу. Причем через раз - то подключатся без NLA, то с NLA (только керберос), то в отказ идут. Еще и туча событий на сервере от schannel что получено tls 1.2, но не удалось согласовать шифросьют. Причем не пишет откуда куда соединение и какие шифросьюты, чтобы хоть узнать от какого приложения, но по времени похоже на ту минуту когда висит RDP. Вряд ли это совпадение, но непонятно что отключить чтобы не висело минуту на согласовании шифросьютов.
Для полноты картины желательно больше деталей - какой вид NLA срабатывает, какая версия RD протокола на клиенте/шлюзе/опубликованном mstsc и т.д. Так может быть и дойдем до сути. Еще думается могут быть приколы с сертификатами и с тем откуда подключаетесь - извне или изнутри сети (NAT/брандмауэр/антивирус дает и не такие приколы). Что один комп ведет себя по разному также может зависеть от используемого адреса.
У меня ранее была проблема с адресами сервера, когда один из адресов (сервера удаленного доступа) был недоступен из локалки (хотя удовлетворял маске сети), но сервер его исправно регистрировал в dns (штатного интерфейса отключить регистрацию этого адреса не нашел - регистрацию локалки или wifi можно отключить, а для "входящих подключений" Майкрософт не сподобилась сделать нормальный интерфейс, слепив кучу оснасток без нужного чекбокса), dns проводил ротацию какой адрес сервера выдать первой строчкой, и при выдаче недоступного адреса первым клиенту, клиент обламывался с подключением. Потом конечно клиент пробовал второй адрес и подключался. Пришлось удаленный доступ выделить в отдельный диапазон адресов, чтобы недоступный адрес не подходил по маске локальной сети.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 20.08.2020(UTC) Сообщений: 40 Откуда: Москва Сказал(а) «Спасибо»: 7 раз
|
Сама суть мне кажется, в принципе понятна: на всех компах в домене NLA включено. Внутри - подключаюсь ко всем нормально (смарт-картой). Снаружи, через шлюз - к самому шлюзу (смарт-картой) нормально, а в конкретному компу - ошибка NLA. Хотя если через логин-пароль - то все нормально. Выходит, что само по себе NLA работает (раз по логину могу войти) и работает без ошибок, а ошибка только при использовании смарт-карты.
В чем разница при выполнении проверки NLA при использовании смарт-карты и при использовании логина? Причем - через шлюз (внутри сети разницы нет)
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 20.08.2020(UTC) Сообщений: 40 Откуда: Москва Сказал(а) «Спасибо»: 7 раз
|
Посетила вообще крамольная мысль - а насколько необходимо использовать NLA во внутренней сети, если подключение к компам идет через шлюз RDG? По идее сама тема NLA создана для защиты прямого подключения по RDP... Насколько я не прав?
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
