Вы не авторизованы. Пожалуйста, войдите или зарегистрируйтесь.
Форум Рутокен → Рутокен для Linux → Проброс 11 рутокенов средствами FreeRDP
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Добрый день.
Извините за ожидание. Провел серию экспериментов. Попробовал для подключения к серверу RDP использовать не чистый freerdp, а remmina.
Ошибок, связанных с незапущенной службой смарт-карт не повторил.
Можете на вашем ПК "А" повторить подключение с нескольких виртуальных машин с помощью remmina?
Не думаю, что стоит смотреть в сторону remmina. Это же просто графический интерфейс в нашем случаи для RDP.
Пакет remmina-plugin-rdp зависит от libfreerdp-client2-2, libfreerdp2-2 и libwinpr2-2.
Пакет freerdp2-x11 зависит от этих же libfreerdp-client2-2, libfreerdp2-2 и libwinpr2-2.
То есть backend, который будет осуществлять подключение по RDP и реализовывать WinPR на Linux тот же.
Ошибка с подключением xfreerdp повторяется даже с пустым считывателем смарт-карт ACS.
С remmina ошибку воспроизвести не смог.
Коллеги, здравствуйте!
В ходе последующей эксплуатации токенов в связке с ViPNet Terminal столкнулись со смежной проблемой: при использовании первичной авторизации на windows-машине с помощью проброшенного через rdp токена иногда повторяется проблема с неработающей службой смарткарты. Как и в представленных ранее сообщениях, службы работают, однако панель утверждает обратное. При этом с некоторой долей вероятности помогает переподключиться к этому серверу.
Мы провели несколько экспериментов.
В частности, при последовательном подключении с одной и той же машины с помощью xfreerdp (использовали 2.8.0, 2.10.0, 3.0.0-beta) на один и тот же сервер (Windows 10) с одним токеном, с помощью которого проходит первичная авторизация, панель управления токенами теряет связь со службой примерно в 30-40% случаев. Типичная картина: пробрасывается поряд 3-6 раз, потом 1-2 раза не пробрасывается. Также нередки были ситуации, когда после серии успешных подключений (около 10 раз) начиналась серия из неудачных подключений (на 5-8 раз).
При этом ошибка проявляется значительно реже, если первую авторизацию проходить с помощью пароля.
Проблема также повторяется при использовании rdesktop.
Несколько раз без каких-то существенных отметок в логах происходило восстановление работоспособности. Тогда экран удаленного рабочего стола моргал, в журнале windows появлялась запись от igfxCUIService2.0.0.0
Возможно, одно с другим и не связано, однако есть подозрение, что в случае подключения виндового клиента он каким-то образом сбрасывает где-нибудь что-нибудь, после чего работоспособность восстанавливается, тогда как при подключении линуксовых клиентов подобный сигнал о сбросе может сгенерировать только какая-то другая подсистема, вроде сбоя аппаратного ускорения графики.
На воспроизведение ситуации при работе с linux в качестве клиента не зависит наличие или установленная версии драйверов на linux. Успешные и провальные попытки были как на последние версии, так и без дарйверов вовсе.
Мне кажется, что эта ситуация - прямой наследник этого обращения. Подскажите, необходимо ли завести новую ветку обсуждения, или же может быть сюда имеет смысл что-нибудь добавить?
В ходе экспериментов с подключением с windows-клиента (с авторизацией по токену) также заметили, что иногда на панели также появление сообщение панели о недоступности сервиса, однако в таких случаях после перезапуска панели управления Рутокен работоспособность восстанавливается, а в системном логе появляется ошибка.
billic_infotecs, добрый день.
Ошибка в Панели управления Рутокен при подключении с linux клиентов пропадает после перезапуска Панели?
Кроме ошибки в ПУР есть какие-то еще проявления проблем с пробросом токенов?
billic_infotecs, добрый день.
Ошибка в Панели управления Рутокен при подключении с linux клиентов пропадает после перезапуска Панели?
при подключении с windows - да. с xfreerdp или rdesktop - нет.
Кроме ошибки в ПУР есть какие-то еще проявления проблем с пробросом токенов?
собственно, токен не пробрасывается, и после блокировки сеанса пользователь не может воспользоваться токеном для авторизации в открытой сессии.
Иногда это также приводит к тому, что не работают какие-либо иные проверки сертификата. Повторюсь, главная черта - в некоторых подключениях после нескольких секунд просто прекращается обмен запросами к смарткарте через удаленное подключение (завершаются активные соединения, новые не открываются). в логах на обеих сторонах (Windows/Linux) никаких пометок с повторением ошибки не появляется. на скриншотах вся корреляция, что удалось выявить.
стоит особенно подчеркнуть в свете предыдущих комментариев в этом посте:
remmina является оберткой для freerdp (это можно видеть, например, в коде плагина rdp от remmina, где значительная часть подключаемых библиотек - это библиотеки freerdp), которая реализует не все функции бакенда. В частности, в ней не поддерживается опция /smartcard-logon. Без использования этой возможности проблема не воспроизводится в этом виде.
Если использовать подключение без этой опции, тогда проблему уловить оказывается значительно сложнее, однако она существует, и ее описывал ранее Евгений.
Изначально проблему обнаружили так, как описывал Евгений: в некоторых случаях во время работы с rdp со временем терялся доступ к токену с симптомами: пропадает возможность авторизации в заблокированной системе в рамках имеющегося подключения; панель управления рутокен сообщает, что якобы не работает служба смарт-карт; Никаких экстраординарных ошибок в логах не видно. С помощью /smartcard-logon аналогичное поведение удалось получить с более четкой воспроизводимостью на более коротком промежутке времени.
billic_infotecs, наши коллеги исследовали эту проблему.
В результате оказалось, что проблема с пробросом токена воспроизводится чаще на компьютере, который включен в домен. При этом проблема именно на уровне проброса токена средствами freerdp и от наличия Драйверов Рутокен не зависит.
Вот тут пишут, что поведение с пробросом смарт-карты может меняться в зависимости от версии протокола rdp https://github.com/FreeRDP/FreeRDP/issu … 1471388813
Так же есть похожий сценарий https://github.com/FreeRDP/FreeRDP/issues/8179
Аверченко Кирилл, Спасибо большое за исследование.
Действительно, в issue проекта имеются подобные сообщения. Более того, по последней ссылке в конце мною описан наш сценарий, который несколько отличается от описанного автором обращения.
В первом случае пользователь сообщает, что использует некий Activclient. Могу предположить, что он пытается использовать токен вашего производства.
Однако хочется подчеркнуть, что эта же проблема воспроизвелась при использовании rdesktop, а не только xfreerdp.
Также имеется очень похожее поведение (но с восстановлением работоспособности) при использовании windows-клиента.
Более того, в ходе наших испытаний мы использовали различные версии протокола (параметр build-number использовали 2600, и ряд других, на которых вообще имеется поддержка проброса смарткарт), однако выявить его влияние на поведение не удалось.
Кроме того, пока что не удалось воспроизвести наш сценарий на токенах других производителей. Честно признаемся, не очень сильно пытались, но можем постараться.
Это все дает основания предположить, что, возможно, дело не на стороне xfreerdp, либо есть какая-то тонкость, которая происходит при автоматическом восстановлении работоспособности при подключении с windows, и не проихсодит при использовании других клиентов.
Быть может, есть возможность собрать логи с серверной части рутокена, чтобы понять, что происходит в момент падения при подключении? Возможно, это позволит, например, сделать костыль для freerdp, который бы также смог посылать подобный сигнал, если его вообще инициирует клиент?
Мы воспроизводили проблему и на токенах других производителей.
Скорее всего дело в том, что сервис смарт-карт pcsc-lite не до конца совместим со службой смарт-карт Windows.
Начиная с Windows 10 служба смарт-карт находится в "спящем" режиме, если нет подключенных устройств. И в момент подключения по rdp она не выходит из этого режима, видимо. Как ее заставить запускаться принудительно, нам не известно.
Спасибо большое!
Можно было бы предположить, что проблема действительно в "спящем" режиме сервиса, однако при этом первая авторизация в системе проходит, что говорит о том, что кто-то со смарт-картой все же работает.
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Форум Рутокен → Рутокен для Linux → Проброс 11 рутокенов средствами FreeRDP
