*ночное включение передачи для полуночных НСДшников*
Который год бьюсь с маленькой частной проблемкой (в масштабах страны, ага) совместимости AstraLinux SpecialEdition (и не только) и СЗИ НСД SecretNet/SecretNetStudio при использовании персональных идентификаторов (eToken, Rutoken, etc) в RDP-сессиях...
Краткая суть проблемы: при опросе идентификаторов средствами SN/SNS в терминальной сессии используются некие "дополнительные вызовы" функции ScardLocateCardsByATR. Что, к сожалению, не полностью поддерживается утилитой freerdp-x11 версии 2 (и всеми обертками над ним типа Remmina)...
Проект freerdp-x11 переживает второе дыхание, но переписан с 0 относительно прошлой версии (которая, кстати, таких проблем совместимости не имеет и, в то же время, входит в состав ALSE 1.5). В ALSE 1.6, соответственно, перекочевал из Debian 9, а в ALSE 1.7 - (модуль экстрасенсорики подсказывает) перекочует из Debian 10.
В сущности, за неимением альтернативы, разобрался, что некорректная поддержка функции ScardLocateCardsByATR связана с дочерним проектом разработчиков freerdp-x11 - библиотекой winpr. Увы, запросы и к одним разработчикам, и к другим особого эффекта не дают, поскольку конкретика вызовов ScardLocateCardsByATR сокрыта в недрах СЗИ НСД SecretNet/SecretNetStudio. Путь оказался слишком тернист: нужно допросить "Код Безопасности", чтобы они дали информацию, требуемую разработчиками winpr, которые внесут изменения (возможно) в их библиотеку, которую (возможно) будут использовать с новым релизом freerdp-x11, который (возможно) попадет в Debian 10, из которого (возможно) попадет в ALSE 1.7 в рамках обновлений и инспекционного контроля. И самый первый шаг его уж больно сложен: "Код безопасности" не спешит делиться информацией...
Внезапное условное решение: взглянул на альтернативный и старый проект - rdesktop, от которого отказался еще в 2013 г. (уж больно он был падуч и багован). Оказалось, проект 2 года назад ожил и пофиксил часть багов. И, внезапно, в нем задача обработки вызовов решается на 4+. Для корректного проброса идентификатора в RDP-сессию через rdesktop требуется вот такой ключ вызова: -r scard:"имя-идентификатора-в-системе"="имя-идентификатора-в-Win;имя-организации-разработчика-идентификатора" (ключи типа -k -e -E -5 -P -K добавить по вкусу, чтобы уменьшить нагрузку на клиента и сеть, но только при условии корректной настройки сервера). Имя идентификатора в локальной системе можно узнать по выхлопу утилиты pcsc_scan. Имя идентификатора в Win рекомендую узнавать, подключившись к удаленному серверу через Windows-клиент (это имя на поведение SN/SNS не влияет, но может поломать работу с идентификатором как со смарт-картой родными утилитами)...
К чему вся эта простыня текста? Primo, памятка самому себе. Secundo, помощь лицам, столкнувшимся со схожими проблемами (уверен, такие найдутся). Tertio, для наглядности - авось при разработке/сертификации ALSE 1.7 или ее обновлений rdesktop будет включен в состав или случайно не выпилен из него...
ЗЫ Лучше бы "Коду безопасности" переписать свой драйвер и выпилить из него указанные "дополнительные вызовы". Или разработчикам freerdp-x11 пофиксить winpr для их обработки. Или разработчикам rdesktop допилить проект до нормального состояния - да, указанную задачу он решает, но как были у него проблемы с клавиатурным вводом и не только, так и остались. Эх, мечты-мечты...
И первым, и вторым, и третьим уже писал. Результата пока нет (см. опус про тернистый путь)...
Который год бьюсь с маленькой частной проблемкой (в масштабах страны, ага) совместимости AstraLinux SpecialEdition (и не только) и СЗИ НСД SecretNet/SecretNetStudio при использовании персональных идентификаторов (eToken, Rutoken, etc) в RDP-сессиях...
Краткая суть проблемы: при опросе идентификаторов средствами SN/SNS в терминальной сессии используются некие "дополнительные вызовы" функции ScardLocateCardsByATR. Что, к сожалению, не полностью поддерживается утилитой freerdp-x11 версии 2 (и всеми обертками над ним типа Remmina)...
Проект freerdp-x11 переживает второе дыхание, но переписан с 0 относительно прошлой версии (которая, кстати, таких проблем совместимости не имеет и, в то же время, входит в состав ALSE 1.5). В ALSE 1.6, соответственно, перекочевал из Debian 9, а в ALSE 1.7 - (модуль экстрасенсорики подсказывает) перекочует из Debian 10.
В сущности, за неимением альтернативы, разобрался, что некорректная поддержка функции ScardLocateCardsByATR связана с дочерним проектом разработчиков freerdp-x11 - библиотекой winpr. Увы, запросы и к одним разработчикам, и к другим особого эффекта не дают, поскольку конкретика вызовов ScardLocateCardsByATR сокрыта в недрах СЗИ НСД SecretNet/SecretNetStudio. Путь оказался слишком тернист: нужно допросить "Код Безопасности", чтобы они дали информацию, требуемую разработчиками winpr, которые внесут изменения (возможно) в их библиотеку, которую (возможно) будут использовать с новым релизом freerdp-x11, который (возможно) попадет в Debian 10, из которого (возможно) попадет в ALSE 1.7 в рамках обновлений и инспекционного контроля. И самый первый шаг его уж больно сложен: "Код безопасности" не спешит делиться информацией...
Внезапное условное решение: взглянул на альтернативный и старый проект - rdesktop, от которого отказался еще в 2013 г. (уж больно он был падуч и багован). Оказалось, проект 2 года назад ожил и пофиксил часть багов. И, внезапно, в нем задача обработки вызовов решается на 4+. Для корректного проброса идентификатора в RDP-сессию через rdesktop требуется вот такой ключ вызова: -r scard:"имя-идентификатора-в-системе"="имя-идентификатора-в-Win;имя-организации-разработчика-идентификатора" (ключи типа -k -e -E -5 -P -K добавить по вкусу, чтобы уменьшить нагрузку на клиента и сеть, но только при условии корректной настройки сервера). Имя идентификатора в локальной системе можно узнать по выхлопу утилиты pcsc_scan. Имя идентификатора в Win рекомендую узнавать, подключившись к удаленному серверу через Windows-клиент (это имя на поведение SN/SNS не влияет, но может поломать работу с идентификатором как со смарт-картой родными утилитами)...
К чему вся эта простыня текста? Primo, памятка самому себе. Secundo, помощь лицам, столкнувшимся со схожими проблемами (уверен, такие найдутся). Tertio, для наглядности - авось при разработке/сертификации ALSE 1.7 или ее обновлений rdesktop будет включен в состав или случайно не выпилен из него...
ЗЫ Лучше бы "Коду безопасности" переписать свой драйвер и выпилить из него указанные "дополнительные вызовы". Или разработчикам freerdp-x11 пофиксить winpr для их обработки. Или разработчикам rdesktop допилить проект до нормального состояния - да, указанную задачу он решает, но как были у него проблемы с клавиатурным вводом и не только, так и остались. Эх, мечты-мечты...
И первым, и вторым, и третьим уже писал. Результата пока нет (см. опус про тернистый путь)...