Всем здравствуйте. Имеется домен (win 2008r2), сервер бухгалтерии(win2008r2).
Ситуация. Пользователь на своей физической машине (xp) с подключённым к ней токеном (флэшка банк-клиента с ключами) подключается по rdp на сервер бухгалтерии и оттуда через браузер — заходит в банк клиент, где сначала делает авторизацию на сайте, потом выбор пользователя (для кого ключи юзать) и по идее должна идти авторизация токена (должно появляться окошко запроса пин кода), но почему-то вылезает ошибка — ключи не могут быть проверены. Пользователь с других машин под своей учёткой — всё ок заходит. Получается дело либо в самой физической машине к которой токен подключён. Либо непонятно почему через rdp usb не передаётся. Подскажите знатоки, где бы подсмотреть настройки?
ps на машине пользователя usb порты работают, все забиты мышка\клава\принтер\удлинитель usb и всё корректно работает.
Сообщения: 25794 Благодарности: 4314
Подскажите знатоки, где бы подсмотреть настройки?
Сообщение оказалось полезным? Поблагодарите автора, нажав ссылку Полезное сообщение чуть ниже.
Это сообщение посчитали полезным следующие участники:
Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля.
Источник
Банк клиент не работает через rdp
Вопрос
Возникла идея перевести работу бухов на RDS (или VDI), с размещением серверов на удаленной площадке.
Все будет на Win2012R2.
Вопрос в следующем.
Очень много банк-клиентов с usb ключами, по сути по 3-4 банка на каждого сотрудника бухгалтерии, следственно волнует вопрос : будет ли работа с usb ключами прозрачна и без заморочек для бухов, и что в связи с этим выбрать RDS или VDI?
Ответы
разве токены не распознаются rdp клиентом как смарткарта и не передаются в rdp сессию?
токены и смарткарты само собой не будут работать если их втыкать напрямую в сервер — это by design из соображений безопасности, вернее будут, но не в rdp сессии, а только с консоли.
Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 19 августа 2014 г. 6:01
Все ответы
Если не вникать в подробности (какие банки и т.д.), то не рекомендую переводить бухов в терминалку. Очень много проблем в этом вижу. Как правило, клиент-банки жестко привязываются к конфигурации и не только к ней. Рекомендация: оставлять локальные станции для подобных сотрудников.
Если решитесь, то 1) пилотное внедрение 2) продумать перенаправление USB 3) получить рекомендации от самих банков (а они будут примерно такие, как выше, на мой взгляд)
Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com
Спасибо за отклик, у меня такие же есть сомнения
А использования Virtual Desktop Infrastructure ( VDI ) не может упростить ситуацию?
Как по мне, оптимальный вариант для бухгалтерии — установка банк клиентов на локальный комп, а 1С и прочий «тяжелый» софт доставлять через RemoteApp.
Закрытый ключ ЭЦП, подключенный к хосту не передается через RDP на сервер из соображений безопасности.
Варианта работы с закрытыми ключами два:
1) Воткнуть все юсб ключи непосредственно в сервер.
2) Скопировать закрытые ключи с юсб в реестр сервера (но опять же копировать возможно только с юсб ключей, воткнутых в сервер)
Еще нюанс — некоторые банк клиенты блокируют все сетевые подключения при установлении соединения с банком, поэтому удаленный доступ может просто отвалится.
Также вполне допускаю что некоторые криптопровайдеры могут работать исключительно с рутокен или етокен и не позволят сохранить закрытый ключ в реестр.
Спасибо за отклик, у меня такие же есть сомнения
А использования Virtual Desktop Infrastructure ( VDI ) не может упростить ситуацию?
При VDI Вашим бухгалтерам будет выделено по 1 вирт.машине (если Private Desktop коллекция). И уже в неё необходимо все ключики пробрасывать,с которыми и проблемы могут возникнуть + не каждый клиент-банк поддерживает вирт.среду (предполагаю). Поэтому ещё раз.. по всем клиент-банкам получите рекомендации от производителя, соберите необходимые требования к каждому и сопоставьте со средой windows server (rds + vdi).
Из практики я видел 2 типа клиент-банков: 1) полностью браузерный (но так же требует ЭЦП) 2) отдельное ПО ( к примеру, СберБанк). К каждому свои требования и свои причуды.
Источник
Токены в терминале (RDP) для любого пользователя
Выкатил нам один из банков прикол — обязал перейти с ключей на диске на токены (смарт-карты). Все бы ничего, но с этим КБ привыкли работать в разделенном режиме. Более того, люди мало того, что работают на терминальном сервере, так еще и из разных городов и даже стран. Но токен виден в терминале только тому, кто его воткнул в свою рабочую станцию с которой идет подключение к терминалу. Остальные курят бамбук (часто за тысячи километров).
Банк рекомендует выделить одного человека, который будет работать с токенами, а остальные должны ему говорить что делать и когда. Но это беда жеж.
Если токен воткнуть напрямую в сервак, то его увидят только те, кто напрямую на серваке работает, а для RDP-подключений их не будет видно.
Может есть вариант проброски токенов по RDP так, что бы их видели все?
(0) Токен вероятно содержит криптоконтейнер, с именным сертификатом. По уму его должен использовать тот на кого сертификат выдан. В крайнем случае тот кому токен передан. Общий доступ без контроля это плохо. Приблизительно так же плохо как лежащие в приёмной фирменные бланки с подписью директора куда каждый может вписать свой текст.
Если с банком работает разумное количество пользователей то можно запросить сертификаты на всех пользователей. Это не дорого или даже бесплатно.
апну как я темку. может кто-то еще чего посоветует ))
платные решения за вменяемые разовые деньги тоже пойдут. Но их гугл выдает много. Может кто что подобное юзал/юзает?
(26) Проброс через usb/ip не решит проблему. Пробрасывал Рутокен с Юбунту на Винду, чтобы рса для Егаис перешить. Но USB/IP хочет монопольного доступа, чтобы достучаться пришлось останавливать демона Рутокен на Юбунте. Коммерческая версия USB Redirector тоже предупреждает об этом: https://www.incentivespro.com/helps/usb-redirector/features_inactivity_timeout.htm Так что пробросить ключ по получится, а вот работать одновременно нет. Разве что по очереди, но это все равно не то что нужно.
Патч SCardSvr.dll и WinSCard.dll скорее всего тоже не поможет, если будут запросы к ключу с разными параметрами, думаю, адские глюки неизбежны.
(29) Это банковские токены. В банках с легко копируемми закрытыми ключами лет десять борьба ведётся. И банковские безопасники всегда были против того что закрытый ключ можно легко скопировать и по слухам ФСБ тоже против. В лучшем случае выставлен флаг некопируемости. В этом случае теоретически можно скопировать, патчить криптопровайдер или пытаться закрытый ключ из памяти вытащить. Доступные сисадмину методы закончились лет восемь назад. Но там скорее всего всё ещё хуже, не флаг некопируемости выставлен а ключ не копируемый. Ключевая пара создана таким образом что нет документированного способа экспортировать закрытый ключ. Мало шансов что топикстартеру доступны недокументированные способы. Тогда только атаки по побочным каналам всякие.
У некоторых банков можно попросить копируемый ключ. Технически они могут.
Но смысла нет. Правильный ответ уже дали. Попросить у банка бесплатно или за деньги сертификаты на всех или на часть пользователей и выдать им полномочия юридически которые у них уже есть фактически.
(33) Так это не банк. Отчётность всякая в госорганы. У вас там другой мир со своими правилами игры. С чего вы взяли что у вас там есть хоть какая-то некопируемость?
У топикстартера банк:»Выкатил нам один из банков прикол. «
(37) Большинство банковских токенов закрытый ключ наружу не отдают и все операции с закрытым ключом проделывают внутри «флешки». Наиболее продвинутые вдобавок к этому умеют шифровать канал связи между приложением и токеном но я подозреваю что это банкам не особо нужно.
(38) Я по прежнему не понимаю почему вы считаете что у вас ключи не копируемые. Если вы получили «флешку» в банке то по умолчанию закрытый ключ или некопируемый или трудно копируемый, но если в удостоверяющем центре то по умолчанию закрытый ключ легко копируемый. В УЦ можно получить и некопируемый, но это отдельные деньги, отдельный геморрой в сравнении с которым часто деньги уже не так важны, частичная потеря совместимости и в итоге как правило не нужно никому.
(39) Скорее всего «облачный токен» потребует поддержки со стороны банка.
(41) Я вижу два основных варианта: 1. При копировании не копируется закрытый ключ. Но поскольку закрытый ключ доступен всё работает. 2. Какой-то способ скопировать криптоконтейнер без использования криптопровайдера. Поскольку при работе ключ в память загружается это возможно. Это наиболее интересный вариант. На случай очередных проблем с Казначейством. Любопытно как именно.
И ещё один вариант, токена нет а есть съёмный диск. Тогда криптопровайдер откажется копировать закрытый ключ если выставлен флаг некопируемости. Но операционной системе эти все флаги глубоко безразличны, она о них даже не знает, для неё это просто файлы и копируются они как файлы.
(44) Странно. Для сдачи отчётности обычно по умолчанию копируемые штатными средствами.
Большая часть отчётности на самом деле делегируется. То есть нужно не копировать криптоконтейнер а оформить документы. Типа сдача отчётности в Росстат поручена Иванову И.И., на Иванова И.И. выпускается сертификат. Иванов И.И. получает на руки «флешку» и инструкцию куда эту шнягу втыкать и куда не втыкать. В случае косяков с ИВанова И.И. можно спросить. Полномочия ограничены. И если злые хакеры украли закрытый ключ то они могут от вашего имени отправить отчётность в Росстат, могут не отправлять, но больше не могут ничего. Генеральный с практически неограниченными полномочиями по уставу типа не при делах. Есть конечно вещи которые не делегируются.
С банками такое тоже прокатывает. Но там геморроя сильно больше. Банкам выгодна подпись Генерального потому что эта подпись на основании устава, который практически вечный, а подпись буха она на основании довереннности у которой есть срок и этот срок нужно не прошляпить уже самому банку.
Источник
Банк клиент не работает через rdp
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
Вопрос
Есть сервер на котором замечательно работал клиент банк (iBank2) через RDP, пока не появилась необходимость заменить ключевой файл на eToken. Это требование банка, старый меттод с файлом больше не поддерживается.
Соответственно в RDP сессии iBank2 не видит токен, хотя он подключен, драйвер стоит, устройство видно в диспетчере устройств. Вопрос в том, как полностью запретить использование Smart Card и eToken перенаправленных через RDP? Похоже проблема как раз в настройках протокола.
1.Отключен редирект Smart Card через GPO : Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Client/Server data redirection\Do not allow smart card device redirection
2. Снята галочка со Smart Cards в настройках RDP connection на клиенте.
Наверняка это отключило перенаправление Smart Card и eToken, но в терминальной сессии похоже просто не видно родного токена, подключенного к хосту.
Ответы
1. Полагаю, автор понял, что форум не является официальной тех. поддержкой.
2. Майкрософт стремится к тому, чтобы любой автор вопроса получил ответ в течении 24 часов, но получение ответа это не гарантия получения решения проблемы.
3. Предлагаю закрыть это направление обсуждения и обсуждать суть вопроса автора
И так по существу вопроса.
1. Понятен ваш сценарий работы: клиента банка должен работать при доступе с любого устройства.
2. Когда был ключевой файл, то сценарий с терминальным сервером у вас работал, при появлении эл.ключа (ЭК) появилась проблема, которая заключается в том, что ЭК не виден в терминальной сессии, если его подключить к хосту.
3. ЭК виден при подключении к консоле.
Какие могут быть варианты?
Для начала предположу, или даже буду отверждать, что ЭК выдан банком определенному лицу — руководителю или гл. бухгалтеру — и только это лицо имеет право его использовать, ЭК должен быть всегда у этого лица и не может быть передан другому лицу, т.к. это прямое нарушение соглашения с банком. (В реальности ЭК ключ передают рядовому исполнителю, но уж точно не всей бухгалтерии разом!)
И так одному человеку надо увидеть ЭК на терминальном сервере. Самое очевидное это дать ему право консольного подключения. Да это права администратора и это издержки этого варианта. Полагаю это не смертельно 🙂
Второй вариант более правильный, когда ключ всегда у пользователя, и он подключает его к своему устройству. При подключении с обычного компьютера, я так понял, проблем нет: ЭК пробрасывается через RDP и распознается приложением — так и должно работать.
Проблема есть в другими устройствами. Ответ простой: его устройство должно поддерживать 1. ЭК 2. Должно иметь полноценный RDP клиент, который умеет пробрасывать ЭК на сервер.
Все это работает на iPad: 1. покупается софт для ЭК 2. Покупается RDP клиент — какие точно я не знаю, но поиск показывает что есть достаточно предложений и по первому и по второму пункту.
Если у вас есть потребность настроить другой тип клиента, то ответ аналогичен iPad: нужно найти и купить соответствующий софт.
Кстати буквально на днях должны появится в продаже устройства с Windows 8/RT, которые могут вами рассматриваться как вариант решения.
Профиль | Отправить PM | Цитировать 
Полезное сообщение чуть ниже. 
