Тему можно закрывать. Еще раз спасибо!

«Описанная проблема заключается в используемом терминальном клиенте. В нём не в полной мере реализован стандартный интерфейс WinsCard. В частности, функция ScardLocateCardsByATR().
Можем рекомендовать сменить терминальный клиент или его версию. Мы учтем этот момент а будущих версиях и вероятно поддержим клиентов даже без этой функции. Но это не ошибка нашего продукта. Это недоработка используемого терминального клиента.»

С уважением, Алексей Лазарев

to Алексей Лазарев
Пробовал разные комбинации: брал драйвер для Win из дистрибутива SNS 8.4 (при использовании с SNS 8.4), из дистрибутива SN7 (при использовании с ним), последнюю версию с оф.сайта; также брал последнюю версию драйвера для Linux с оф.сайта и самую первую версию, которая заработала с Астрой 1.3 при прошлом обращении 6 лет назад (ifd...-1.0.1.deb). Результат всегда один (хотя со старым драйвером для Linux наблюдалось еще и постоянное мигание светодиода Рутокен S, но, думаю, это не критично):

• при подключении из-под Win 8.1 к Win Server 2008R2/2012R2 или из-под Linux Mint (не принципиально, как мне кажется) к Win Server 2008R2/2012R2 Rutoken S корректно пробрасывается RDP-клиентом, "виден" в Панели управления Рутокеном, а также "виден" всеми механизмами SNS (SN7);

• при подключении из-под Astra Linux SE 1.6 к Win Server 2008R2/2012R2 Rutoken S пару раз мигает (с последним драйвером для Linux), будто бы идет опрос, но в терминальной сессии ни Панель управления Рутокеном, ни SNS (SN7) его уже "не видят" (Панель выдает стандартную ошибку, будто бы не включена служба поддержки смарт-карт)

Проброс Rutoken S в терминальную среду делаю через:

/usr/bin/xfreerdp /sec:rdp /cert-ignore /smartcard:"0a89:0020" /v:192.168.1.1

Правила udev для Rutoken S:

SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="0a89", ATTRS{idProduct}=="0020", RUN+="/bin/systemctl start rutoken.service"
SUBSYSTEM=="usb", ACTION=="remove", ENV{ID_VENDOR_ID}=="0a89", ENV{ID_MODEL_ID}=="0020", RUN+="/bin/systemctl stop rutoken.service"

Systemd-сервис для Rutoken S:

[Unit]
Description=Rutoken S (un)plug service
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/RutokenS.sh plug
ExecStop=/usr/bin/RutokenS.sh unplug

Впрочем, systemd-сервис и правила udev модифицированы под нужную задачу (скрипт RutokenS.sh выполняет доп.действия при подключении токена, но также выполняет chgrp для /dev/usb..., как и в оригинале после установки драйвера). Если их оставить по умолчанию (после установки драйвера), все равно ничего принципиально не меняется.
В ходе ковыряния проблемы на стенде дошел до того, что отключил почти все защитные механизмы Astra Linux, до которых смог добраться: мандатный контроль целостности, модули Parsec для PAM, киоск, затирание, мандатные метки уровня файловой системы. Но проблема осталась...

К сожалению, в "репозитории" (диск установки) Astra Linux SE 1.6 отсутствует пакет pcsc-tools, поэтому непосредственную отладку через консоль не проводил. Если необходимо, могу встроить аналогичный пакет от Debian 9 и проверить вывод.
Любопытный факт: после пары-тройки подключений к терминальному серверу с подключенным Rutoken S, сервис pcscd переходит в состояние inactive и требует перезапуска. Почему и грешу на переполнение буфера...

ЗЫ Складывается ощущение (особенно после заработавшей связи с Dallas Lock 8.0-C), что SNS (SN7) производит слишком много "лишних" обращений к Rutoken S, в результате чего служба в Astra Linux не выдерживает и "отбивает"...

Скажите пожалуйста, а вы не пробовали провести следующий эксперимент: На терминальном сервере установить комплект драйверов с дистрибутивного диска Secret Net Studio 8.4, после чего проверить будет ли возникать проблема описанная в обращении. Суть проблемы в том, что SNS чувствителен к версии драйвера.

И еще момент, можете уточнить, какие защитные компоненты включены в Astra Linux SE 1.6?

UPD. Имеются ввиду драйверы Рутокен для Windows, которые шли на диске. Там должна быть версия 4.3.0.0

Приносим извинения за длительное ожидание.
На почту, указанную при регистрации на форуме, мы направили письмо с необходимой нам дополнительной информацией для анализа проблемы.

Пытаюсь реализовать схему проброса аппаратного идентификатора (Rutoken S) в терминальную среду (Windows Server) с клиентской nix-машины (Mint / Astra).
На обеих машинах установлены свежие драйверы ifd-rutokens-1.0.4.deb для x64 архитектуры, а также необходимые зависимости:  libccid, pcscd и libpcsclite1. С той лишь разницей, что под Linux Mint имеется пакет pcsc-tools для проверки работы Rutoken S, а под Astra Linux он отсутствует.
В Astra Linux специально отключена поддержка мандатного контроля целостности (МКЦ) через astra-mic-control disable и пользователю (user) превентивно выставлены права работы исключительно в 0 мандатной сессии.

Проблематика

• Если не устанавливать Secret Net (Secret Net Studio) в терминальную среду Windows Server, то и под Linux Mint, и под Astra Linux проброс Rutoken S через xfreerdp выполняется корректно. Панель управления Рутокен (Windows) "видит" проброшенный токен, позволяет к нему обратиться, отформатировать и т.д.

• Если установить Secret Net (Secret Net Studio), то из-под Astra Linux проброс "отваливается": при создании терминальной сессии токен несколько раз мигает, но затем обращение к нему полностью прекращается. В результате, токен не видится ни средствами Secret Net (Secret Net Studio), ни средствами Панели управления (Windows) - выводится работы ошибка службы смарт-карт с предложением посетить страницу настройки Рутокена для RDP-сессии. Демон pcscd в свою очередь периодически уходит в inactive режим - приходится его рестартовать через systemctl.

• Из-под Linux Mint аналогичная связка полностью отрабатывает: токен "виден" и средствами Панели управления, и средствами Secret Net (Secret Net Studio).

Очевидно, что корень зла в компонентах Astra Linux Special Edition, однако никак не могу сообразить, в каких конкретно. Такое ощущение, что обращение к токену средствами Secret Net (Secret Net Studio) в RDP-сессии приводит к переполнению буфера или иной схожей проблеме демона pcscd или самого драйвера Rutoken S.

Собственно, хотел узнать:
- возможно, существует свежий драйвер, разработанный именно под Astra Linux Special Edition и новее 2014 г.в.?
- возможно, что проблема в демоне pcscd или зависимостях (libccid, libpcsclite1) из комплекта Astra Linux Special Edition?
- возможно, имеется определенная схема специальной настройки Astra Linux Special Edition для полной поддержки Rutoken S?

К сожалению, перейти на Рутокен ЭЦП 2.0 не получается - приходится использовать Rutoken S в связи с его сертификатом под "особые" АС...