В первом случае пользователь сообщает, что использует некий Activclient. Могу предположить, что он пытается использовать токен вашего производства.

Однако хочется подчеркнуть, что эта же проблема воспроизвелась при использовании rdesktop, а не только xfreerdp.
Также имеется очень похожее поведение (но с восстановлением работоспособности) при использовании windows-клиента.

Более того, в ходе наших испытаний мы использовали различные версии протокола (параметр build-number использовали 2600, и ряд других, на которых вообще имеется поддержка проброса смарткарт), однако выявить его влияние на поведение не удалось.

Кроме того, пока что не удалось воспроизвести наш сценарий на токенах других производителей. Честно признаемся, не очень сильно пытались, но можем постараться.

Это все дает основания предположить, что, возможно, дело не на стороне xfreerdp, либо есть какая-то тонкость, которая происходит при автоматическом восстановлении работоспособности при подключении с windows, и не проихсодит при использовании других клиентов.

Быть может, есть возможность собрать логи с серверной части рутокена, чтобы понять, что происходит в момент падения при подключении? Возможно, это позволит, например, сделать костыль для freerdp, который бы также смог посылать подобный сигнал, если его вообще инициирует клиент?

Изначально проблему обнаружили так, как описывал Евгений: в некоторых случаях во время работы с rdp со временем терялся доступ к токену с симптомами: пропадает возможность авторизации в заблокированной системе в рамках имеющегося подключения; панель управления рутокен сообщает, что якобы не работает служба смарт-карт; Никаких экстраординарных ошибок в логах не видно. С помощью /smartcard-logon аналогичное поведение удалось получить с более четкой воспроизводимостью на более коротком промежутке времени.

billic_infotecs, добрый день.
Ошибка в Панели управления Рутокен при подключении с linux клиентов пропадает после перезапуска Панели?

при подключении с windows - да. с xfreerdp или rdesktop - нет.

собственно, токен не пробрасывается, и после блокировки сеанса пользователь не может воспользоваться токеном для авторизации в открытой сессии.

Иногда это также приводит к тому, что не работают какие-либо иные проверки сертификата. Повторюсь, главная черта - в некоторых подключениях после нескольких секунд просто прекращается обмен запросами к смарткарте через удаленное подключение (завершаются активные соединения, новые не открываются). в логах на обеих сторонах (Windows/Linux) никаких пометок с повторением ошибки не появляется. на скриншотах вся корреляция, что удалось выявить.

В ходе последующей эксплуатации токенов в связке с 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-клиента (с авторизацией по токену) также заметили, что иногда на панели также появление сообщение панели о недоступности сервиса, однако в таких случаях после перезапуска панели управления Рутокен работоспособность восстанавливается, а в системном логе появляется ошибка.

На ПК "А", к которому были подключены рутокены 3, 4, 5, 11:

• В настройках всех ВМ был контроллер USB 2.0.

• На этом ПК один из токенов был подключен к синему USB-порту, остальные 3 к черным. Номер единственного рутокена, который который был физически подключен к USB 3.0 и проброшен средствами VBox в ВМ с контроллером 2.0 мы не записали и не запомнили.

• Команда pcsc_scan на 4-ёх ВМ с ПК "А" не выдавала ошибок.

• VirtualBox Версия 6.1.16 r140961 (Qt5.6.2)

Посмотрел наличие операций с токеном в логах "grep -rc smartcard". Такие операции отсутствуют в логах 3, 4, 5, но присутствуют во всех остальных. То есть нет операций с токенами в логах FreeRDP при пробросе тех рутокенов lite, для которых в панели управления рутокен отображалась ошибка "служба смарткарт не запущена". Видимо с сервера не приходили удаленные вызовы процедур для работы с токеном?