Не видит USB-токен при аутентификации в web-приложении, ОС Windows Server 2016. Как победить?
Для обмена налоговыми накладными бухгалтерия использует ПО MEDoc, где для получения/подписания документов использовали файл электронной подписи. Сказали, что файл -это не безопасно, а вот USB-токен – самое то. Приобрели USB-токен Avest PKCS#11, физически подключили к серверу, где установлена серверная часть MEDoc. Пользователи с рабочих станций подключаются, клиенты видят токены, есть возможность выбора. Да и сам сервер, OC Windows Server 2016, видит их как «Устройство чтения смарт-карт Microsoft Usbccis(WUDF)» и Смарт-карту «AvestUA AvestKey». Всё было бы хорошо, если бы эти ключи использовали только для работы с MEDoc, но они ещё используются для авторизации в личных кабинетах, в которые можно зайти только через Web-страницу, к примеру "Кабінет платника податків" от ДФС. Вот в этом случае браузер их не видит, ни Chrome, ни Explorer, ни FF. Если токен физически подключен к Пк пользователя с WIndows 10, то всё замечательно заходит. Служба поддержки сетует на паранойю Microsoft и блокировку в Windows Server взаимодействия браузера с токенами, чуть ли не на уровне ядра. Допускаю что так и есть, но ничего внятного найти не смог. Какие варианты: пробрасывать флешки на ПК пользователей, виртуализация на хосте ОС не Windows Server?
Решение найдено - использовать VNC :(
А теперь к сути проблемы: всё плохо и виной всему RDP клиент, в частности winscard.dll. Начиная с Windows Server 2008, эта библиотека определяет смарт-карты при своём первом запуске и получается так, что если логин был локальным, то смарт-карты считываются с хоста, если логин был удалённым - то с ПК пользователя. При этом, если вы залогинились локально, а потом подключились к этой сессии через RDP, то он продолжит видеть смарт-карты установленные на хосте, но не видеть смарт-карты на ПК пользователя. Это работает и в обратном направлении, если вы зашли через RDP, а потом подключились к этой сессии локально - то он будет видеть смарт-карты на ПК пользователя, который инициировал эту сессию, но не видеть локальные.
Знаю, что Сбис работает через USB-ключ, но с веб-формой он коннектится при помощи доп. устанавливаемого плагина их разработки. Ставишь его и можно заходить в ЛК при помощи ЭЦП. Вероятно ваша веб-форма не приспособлена. Либо нужно какой то посредник для работы, по типу Крипто-Про и аналогов.
да, у данного производителя токенов есть доп.плагин, эта связка работает, если токен физически подключен к ПК пользователя с Windows 10. Но тоже самое, но на Windows Server - не работает.
MHEMOHuK, Так может вы просто не пробросили SMART-card в свойствах удаленного рабочего стола?
У вас на локальном ПК кто заходит терминально на сервер, должна быть активной и работающей служба "Смарт-карта", она вроде по умолчанию в ручном запуске, и в свойствах подключения РДП должна стоять галочка на проброс USB токена.
Служба SMART-card запущена как на сервере так и на ПК пользователя, в RDP стоит галка проброса SMART-card. Но, токены физически подключены к серверу, к которому я подключаюсь по RDP, то есть пробрасывать мне ничего не надо, оно там уже присутствует. Или я что-то не правильно понял?
MHEMOHuK, Вы правильно поняли, я не внимательно прочитал и думал пользователи пользуются ими лично. Тогда скорее всего что-то с правами надо смотреть на запуск, т.е. как система делит кто будет пользоваться этим ключом если одновременно сидит 10-ть человек.
Может сам плагин нужно ставить под пользователем каждым. Сбисовский плагин ставится в локальные папки юзера, т.е. в AppData и не доступны другим кто залогинился.
Процесс Chrome, Explorer, FF не может получить доступ к ПО по шифрованию, например, КриптоПРО. НЕ ПРОСТО не может получить, а не должен, иначе заходя на сайт можно было запускать все что угодно и не только вирусы. )))
Нужен в браузерах плагин, прослойка между браузером и криптографическим ПО. Например, для КриптоПРО - это КриптоПро ЭЦП Browser plug-in
UPD
Опять до конца не прочитал вопрос )))
1. gpedit.msc - в помощь. Политика безопасности запрещает доступ к физическим устройствам если пользователь подключен по RDP (сильно ограничивает).
2. Лицензия? Например у КриптоПРО клиентские лицензии работать не будут на серверных ОС, нужны серверные лицензии.
1. Не могу даже представить куда они могли это засунуть в GPO. К тому же MEDoc, если запустить его на РДП, видит токены и отображает подписи в окне выбора.
2. На сайте производителя токенов и центре сертификации, нет упоминаний про лицензирование, могу предположить что оно едино для всех ОС.
MHEMOHuK,
Токены - Это физические носители, как USB-флешки, там нет лицензий, только драйверы. Вопрос по лицензии криптографического ПО. ПО читает контейнер с зашифрованной информацией находящейся на USB-токене.
С GPO иногда тяжело, например, попробуй записать DVD диск по RDP - Этот Windows, зараза, не хочет записывать диски по RDP.
Попробуй заходить в Chrome, Explorer, FF в включеным режиме "Отладчика", если в консоль будут ошибки связанные с плагином, то где то что то не пускает запуститься плагин.
3. Открытые ключи. Например, нужно правильно установить открытые ключи. В режиме RDP возможно они не активны (их система не видит), но смотреть их надо из под браузеров.
