Двухфакторная аутентификация в домене windows jakarta

Пароль является не очень надежным средством защиты. Очень часто используются простые, легко подбираемые пароли или же пользователи не особо следят за сохранностью своих паролей (раздают коллегам, пишут на бумажках и т.д.). В Microsoft уже давно реализована технология, позволяющая для входа в систему использовать SmartCard, т.е. аутентифицироваться в системе по сертификату. Но не обязательно использовать непосредственно смарт-карты, ведь для них нужны еще и считыватели, поэтому проще их заменить на usb токены. Они позволят реализовать двухфакторную аутентификацию: первый фактор — это пароль от токена, второй фактор — это сертификат на токене. Далее на примере usb токена JaCarta и домена Windows я расскажу как внедрить этот механизм аутентификации.

Первым делом в AD создадим группу «g_EtokenAdmin» и уч. запись «Enrollment Agent», входящую в эту группу. Эта группа и пользователь будут рулить центром сертификации.

Далее добавим серверу роль AD CA (центр сертификации).

Дополнительно установим Web службу для запроса сертификатов.

Далее выбираем вариант для предприятия. Выбираем Корневой ЦС (если у нас это первый центр сертификации в домене)
Создаем новый закрытый ключ. Длину ключа можно оставить туже, а вот алгоритм хеширования лучше выбрать SHA2 (SHA256).

Введем имя CA и выберем срок действия основного сертификата.
Остальные параметры оставляем по умолчанию и запускаем процесс установки.

После установки зайдем в оснастку центра сертификации и настроим права на шаблоны.

Нас будут интересовать два шаблона: Агент регистрации (Enrollment Agent) и Вход со смарт-картой (Smartcard logon).
Зайдем в свойства этих шаблонов и на вкладке безопасность добавим группу «g_EtokenAdmin» с правами чтение и заявка.

Далее включим эти шаблоны.

И они появятся у нас в общем списке.

Следующим шагом настроим групповые политики:
Первым делом расскажем всем компьютерам домена о корневом центре сертификации, для этого изменим Default Domain Policy.
Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Политики открытого ключа -> Доверенные корневые центры сертификации -> Импорт

Выберем наш корневой сертификат, расположенный по пути: C:WindowsSystem32certsrvCertEnroll. Закрываем Default Domain Policy.
На следующем шаге создадим политику для контейнера, в котором будут находится компьютеры с аутентификацией по токену (Смарт-карте).

По пути Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Параметры безопасности. Настроим два параметра «Интерактивный вход в систему: требовать смарт-карту» и  «Интерактивный вход в систему: поведение при извлечении смарт-карты».

На этом с настройками все, теперь можно генерировать клиентский сертификат и проверять аутентификацию по токену.
Залогинемся на компьютере под учетной записью «Enrollment Agent» и откроем браузер, перейдя по ссылке http://Имя_сервера_MS_CA/certsrv

Выбираем пункт Запрос сертификата -> Расширенный запрос сертификата -> Создать и выдать запрос к этому ЦС
Если возникнет ошибка вида «Чтобы завершить подачу заявки на сертификат, следует настроить веб-узел для ЦС на использование проверки подлинности по протоколу HTTPS», то нужно на сервере IIS, на котором установлен MS CA, сделать привязку сайта к протоколу https.

Продолжим получение сертификата, для этого на открывшейся странице выберем шаблон: «Агент регистрации» и нажмем кнопку выдать и установить сертификат.

Теперь пользователь Enrollment Agent может выписывать сертификаты для других пользователей. К примеру запросим сертификат для пользователя test. Для этого откроем консоль управления сертификатами certmgr.msc, т.к. через web интерфейс не получится записать сертификат на usb токен.
В этой консоли на папке личное сделаем запрос от имени другого пользователя

В качестве подписи выбираем единственный сертификат «Enrollment Agent» и переходим к следующему шагу, на котором выбираем пункт «Вход со смарт-картой» и нажимаем подробности для выбора криптопровайдера.
В моем случае я использую токены JaCarta, поэтому вместе с драйверами был установлен криптопровайдер «Athena…»:

На следующем шаге выбираем доменного пользователя, для которого выписываем сертификат и нажимаем на кнопку «Заявка».

Вставляем токен, вводим пин код и начинается процесс генерации. В итоге мы должны увидеть диалоговое окно с надписью «Успешно».
Если процесс окончился неудачно, возможно дело в шаблоне получения сертификата, в моем случае его надо было немного подправить.

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

P.s.
1) Если не работает автоматическая блокировка компьютера или выход из системы, после вытаскивания токена, смотрите запущена ли служба «Политика удаления смарт-карт»
2) На токен можно записать (сгенерировать сертификат) только локально, через RDP не получится.
3) Если не получается запустить процесс генерации сертификата по стандартному шаблону «Вход с смарт-картой», создайте его копию с такими параметрами.

На этом все, если будут вопросы, задавайте, постараюсь помочь.

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

1. Введение

2. Состав продуктовой линейки JaCarta

3. Токены и смарт-карты JaCarta PKI

4. Токены и смарт-карты JaCarta PKI/BIO

5. Токены и смарт-карты JaCarta ГОСТ и JaCarta² ГОСТ

6. Токены JaCarta WebPass

7. Токены JaCarta U2F

8. Система управления JaCarta Management System

9. Сервер аутентификации JaCarta Authentication Server

10. Решение JC-WebClient

11. Решение JC-Mobile

12. Решение «Антифрод-терминал»

13. Решение для двухфакторной аутентификации JaCarta SecurLogon

14. Выводы

Введение

На сегодняшний день без надежной системы аутентификации пользователей не обходится ни одна уважающая себя компания. Специалисты по информационной безопасности (ИБ) рекомендуют использовать многофакторную аутентификацию, основанную не только на знании секрета (пароля), но и на владении специальным устройством (токеном). Нередко в качестве третьего фактора выступает одна или несколько биометрических характеристик пользователя. В этом случае возникает проблема учета и регистрации всех аппаратных и программных средств аутентификации и хранения ключевой информации, используемых сотрудниками в масштабах предприятия.

Еще одна тенденция в сфере ИБ связана с ростом числа мобильных устройств, с которых сотрудники компаний работают с конфиденциальной корпоративной информацией. Все чаще применяется модель BYOD (Bring Your Own Device), позволяющая сотруднику для выполнения своих профессиональных обязанностей использовать личные мобильные устройства. При этом появляется необходимость в механизме многофакторной аутентификации в отношении владельцев смартфонов или планшетов.

Изменение законодательства в области защиты персональных данных, принятие требований по сертификации средств защиты информации, развитие дистанционного банковского обслуживания (ДБО) и интернет-банкинга требует от участников рынка внедрения отечественных систем аутентификации и электронной подписи (ЭП).

Для эффективного решения поставленных задач российская компания «Аладдин Р. Д.» разработала платформу JaCarta — семейство аппаратных и программных продуктов, позволяющих осуществлять аутентификацию пользователей, генерировать ЭП и безопасно хранить криптографические ключи и цифровые сертификаты, а также централизованно управлять ключевыми носителями на протяжении их жизненного цикла.

Состав продуктовой линейки JaCarta

В состав платформы JaCarta входят:

• токены JaCarta PKI, предназначенные для строгой двухфакторной аутентификации пользователей в корпоративных (включая интеграцию с продуктами Microsoft, Citrix, VMware, Wyse и др.) и государственных системах, а также безопасного хранения ключей и ключевых контейнеров программных средств криптографической защиты информации (СКЗИ);
• токены JaCarta PKI/BIO, предназначенные для строгой двух- или трехфакторной аутентификации с применением биометрической идентификации;
• токены JaCarta ГОСТ и JaCarta² ГОСТ, предназначенные для обеспечения юридической значимости действий пользователей с помощью ЭП и передачи зашифрованных данных между клиентом и сервером при работе с web-порталами и облачными сервисами;
• токены JaCarta WebPass, предназначенные для генерации одноразовых паролей, безопасного хранения сложного многоразового пароля и его подстановки в экранные формы по нажатию кнопки на токене, а также запуска браузера и автоматического перехода по сохраненному адресу сайта;
• токены JaCarta U2F, предназначенные для использования в качестве второго фактора при парольной аутентификации конечных пользователей онлайн-сервисов по стандарту FIDO U2F;
• система управления JaCarta Management System, автоматизирующая типовые операции при работе с токенами и предоставляющая централизованное управление доступом к корпоративным системам;
• автономный сервер аутентификации JaCarta Authentication Server, позволяющий организовать усиленную аутентификацию по одноразовым паролям (OTP);
• решение JC-WebClient для реализации функций строгой двухфакторной аутентификации и работы с ЭП с использованием токенов JaCarta на web-порталах и в облачных сервисах;
• решение JC-Mobile для реализации функций строгой двухфакторной аутентификации и работы с ЭП с использованием токенов JaCarta в мобильных приложениях на Google Android и Apple iOS;
• TrustScreen-устройство «Антифрод-терминал» для работы с электронной подписью в недоверенной среде;
• программно-аппаратное решение JaCarta SecurLogon, предназначенное для обеспечения двухфакторной аутентификации пользователей ОС Microsoft Windows с применением токенов JaCarta без развертывания PKI-инфраструктуры.

Токены JaCarta выпускаются в нескольких функционально идентичных исполнениях (форм-факторах): смарт-карта, USB-токен в корпусе Nano и XL, MicroUSB-токен, USB-токен с кнопкой (для JaCarta WebPass и JaCarta U2F). Большинство форм-факторов позволяют совмещать в одном устройстве несколько функций, что дает возможность сократить число ключевых носителей пользователя, реализуя необходимые функции в одном токене (например, двухфакторную аутентификацию и ЭП).

Рисунок 1. Смарт-карта, USB- и MicroUSB-токены JaCarta

MicroUSB-токены и смарт-карты JaCarta позволяют организовать строгую двух- и трехфакторную аутентификацию и усиленную квалифицированную ЭП на мобильных устройствах, обеспечивая защиту транзакций в условиях недоверенной среды. Для подключения смарт-карт JaCarta к мобильным устройствам можно использовать проводные или Bluetooth-считывателя смарт-карт. MicroUSB-токены JaCarta можно подключить напрямую (если есть порт MicroUSB) или через переходник MicroUSB-to-USB.

На основе смарт-карт JaCarta выпускается решение Электронное удостоверение JaCarta, объединяющее функциональные возможности бесконтактного пропуска (за счет включения RFID-метки и интеграции со СКУД), средства доступа в информационную систему, средства ЭП, защищенного хранилища пользовательских данных, банковской карты и обычного удостоверения сотрудника.

Компоненты платформы JaCarta имеют следующие сертификаты соответствия:

• сертификаты ФСТЭК России № 2799 и 3449, подтверждающие, что токены семейства JaCarta являются средством аутентификации и безопасного хранения пользовательских данных, соответствуют требованиям по 4 уровню контроля отсутствия недекларированных возможностей и могут использоваться в автоматизированных системах, обрабатывающих конфиденциальную информацию до класса защищенности 1Г включительно, а также в информационных системах персональных данных (ИСПДн) до 1 класса включительно;
• сертификат ФСТЭК России № 3355, выданный на программное обеспечение JaCarta Management System, подтверждающий соответствие 4 уровню контроля отсутствия недекларированных возможностей и требованиям Технических условий;
• сертификат ФСТЭК России № 3575, подтверждающий, что JaCarta SecurLogon является программно-техническим средством защиты от несанкционированного доступа к информации и соответствует требованиям по 4 уровню контроля отсутствия недекларированных возможностей;
• сертификат ФСБ России № СФ/111-2750, подтверждающий что персональное средство ЭП «Криптотокен ЭП» в составе JaCarta ГОСТ соответствует требованиям к средствам ЭП классов КС1 и КС2 и может использоваться для реализации функций ЭП в соответствии с 63-ФЗ «Об электронной подписи»;
• сертификаты соответствия ФСБ России № СФ/124-2963 и № СФ/124-2964, подтверждающие, что СКЗИ «Криптотокен 2» в составе JaCarta ГОСТ соответствует требованиям ФСБ к СКЗИ по классам защиты КС1 и КС2 и может использоваться для криптографической защиты информации, не содержащей сведений, составляющих государственную тайну;
• Common Criteria EAL 4+ — международный сер­тификат на используемые в устройствах JaCarta микроконтроллер (чип) и операционную систему на соответствие профилю безопасно­сти Smart Card Security User Group — Smart Card Protection Profile;
• Common Criteria EAL 5+ — международный сер­тификат на используемые в устройствах JaCarta микроконтроллер (чип) и операционную систему на соответствие профилю защиты Security IC Platform Protection Profile, версия 1.0. Оценка соответствия выполнена по методике Common Criteria (версия 3.1, ревизия 3). Достигнутый уровень доверия — EAL 5+ (усиленный).

Токены и смарт-карты JaCarta PKI

Токены и смарт-карты JaCarta PKI/BIO

Токены и смарт-карты JaCarta ГОСТ и JaCarta² ГОСТ

И в JaCarta ГОСТ, и в JaCarta² ГОСТ криптоалгоритмы реализованы на уровне микропроцессора, а схема работы с неизвлекаемым закрытым ключом подписи исключает возможность хищения закрытого ключа подписи, при этом формирование ЭП с его использованием выполняется внутри устройства.

Устройства предназначены для обеспечения юридической значимости действий пользователей при использовании различных электронных сервисов:

• ДБО;
• электронные торговые площадки;
• сдача электронной отчетности;
• электронное декларирование грузов, перемещаемых через границу;
• публичные или корпоративные web-порталы и облачные сервисы, (например, Портал государственных услуг);
• системы корпоративного/ведомственного электронного документооборота.

Смарт-карты JaCarta ГОСТ могут применяться как с обычными считывателями, так и с «Антифрод-терминалом» — снабженным дисплеем и клавиатурой устройством, предназначенным для формирования с помощью JaCarta ГОСТ ЭП в недоверенной среде.

Подробная информация о линейке продуктов JaCarta ГОСТ и JaCarta² ГОСТ представлена на сайте производителя.

Токены JaCarta WebPass

Токены JaCarta U2F

В отличие от PKI-токенов JaCarta U2F поддерживают самостоятельную регистрацию пользователей — при регистрации токена JaCarta U2F на конкретном web-ресурсе не требуется участия администратора. В процессе регистрации пользователем своего U2F-токена на web-ресурсе происходит генерация ключевой пары (открытый и закрытый ключ) без сертификата открытого ключа. Сгенерированная ключевая пара используется для дальнейшей аутентификации. В связи с этим один токен может использоваться для доступа к множеству различных web-ресурсов.

Токены JaCarta U2F обеспечивают защиту от фишинговых атак, поскольку закрытый ключ, хранящийся в памяти токена, соответствует URL-адресу определенного web-ресурса.

Основные компоненты типового решения с поддержкой U2F-аутентификации на базе токена JaCarta U2F представлены ниже.

Рисунок 2. Архитектура типового решения с поддержкой U2F-аутентификации на базе токена JaCarta U2F

В состав типового решения с поддержкой U2F-аутентификации на базе токена JaCarta U2F входят следующие компоненты:

• Web-сервер, на котором установлено одно или несколько web-приложений и U2F-сервер — приложение, реализующее серверную часть протокола U2F и обеспечивающее хранение информации, полученной в процессе регистрации и аутентификации. Web-приложение при получении запросов на регистрацию и аутентификацию пользователей обращается к U2F-серверу для проверки и сохранения полученных от пользователя данных.
• U2F-клиент — приложение, посредством которого пользователь взаимодействует с web-сервисом (например, web-браузер или мобильное приложение). U2F-клиент реализует клиентскую часть протокола U2F, взаимодействует с web-сервером по протоколу HTTPS и U2F-токеном по протоколу USB HID.
• Токен JaCarta U2F — устройство, используемое в качестве второго фактора аутентификации при доступе к web-ресурсам и реализующее интерфейс USB HID.

Один токен JaCarta U2F можно применять для ПК, ноутбуков и мобильных устройств (при наличии USB-разъема или MicroUSB-разъема). При этом поддержка U2F обеспечивается из соответствующего приложения (например, Google Chrome).

Подробная информация о JaCarta U2F и описание принципов работы доступны на сайте производителя.

Таблица 1. Сравнение моделей токенов JaCarta

USB — USB-токены в корпусе Nano или XL

MUSB — MicroUSB-токены

SC — токены в форма-факторе смарт-карта

● — Базовая функциональность

○ — Дополнительная функциональность (доступна под заказ)

◊ — Функциональность, реализуемая в рамках согласованного c компанией «Аладдин Р.Д.» проекта

Система управления JaCarta Management System

JaCarta Management System (JMS) — корпоративная система управления жизненным циклом токенов JaCarta, eToken и Рутокен. JMS автоматизирует типовые операции при работе с токенами (регистрация, выпуск, назначение, временное отключение, разблокировка, замена), позволяет централизованно управлять доступом к корпоративным системам и получать информацию обо всех действиях в отношении средств аутентификации и ЭП. JMS дополнительно обеспечивает соблюдение требований российского законодательства в части учета СКЗИ.

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

Возможности JMS позволяют:

• автоматизировать учет всех токенов, в том числе сертифицированных СКЗИ. Учитываются владелец, номер, модель и срок службы токенов, а также объекты на токене и рабочие станции, использующие токены;
• управлять всем жизненным циклом средств аутентификации и ЭП, включая выдачу, перевыпуск и отзыв токенов и всех связанных с ними объектов (сертификатов, ключей, меток модулей доверенной загрузки и др.);
• централизованно управлять политиками ИБ в отношении средств аутентификации и ЭП;
• проводить аудит действий пользователей и администраторов с помощью служебных журналов;
• предоставлять сервис самообслуживания для пользователей, позволяя сотруднику самостоятельно совершать операции с токенами, осуществляя их выпуск, отключение, синхронизацию, блокирование, разблокирование и замену без обращения в ИТ- или ИБ-отделы;
• формировать и выводить на печать заявки на выдачу, токенов и сертификатов, что позволяет автоматизировать документооборот, связанный с жизненным циклом токенов;
• отслеживать изменения во внешних системах и обновлять свою базу данных в соответствии с ними;
• отслеживать перемещение токенов между филиалами и распределять права по администрированию серверов JMS между штаб-квартирой и филиалами;
• осуществлять резервное копирование, сохранять копии выпущенных объектов, общих настроек системы и профилей выпуска объектов, что позволяет гарантировать их сохранность, а также перевыпускать токены со старыми сертификатами;
• создавать отчеты по токенам, пользователям, СКЗИ, рабочим станциям, в том числе и по отдельным филиам.

Благодаря возможностям JMS доступно многократное сокращение времени выполнения ряда стандартных типовых операций:

• поддержка многофункциональных токенов;
• пакетная регистрация токенов JaCarta;
• «взятие под управление» имеющихся токенов и объектов на них;
• сохранение перевыпускаемых сертификатов;
• автоматическая синхронизация токенов;
• работа нескольких серверов JMS в автономном режиме;
• разделение полномочий администраторов в филиальной сети;
• создание кастомизированных запросов к удостоверяющим центрам;
• автоматический учет СКЗИ в соответствии с требованиями ФСБ России;
• плавная миграция с SafeNet Authentication Manager (SAM) / Token Management System (TMS).

Сертифицированная версия JMS обеспечивает выполнение требований российского законодательства в области защиты персональных данных и конфиденциальной информации и может использоваться для защиты информации в ИСПДн до 1 уровня включительно и при создании автоматизированных информационных систем до класса защищенности 1Г включительно.

JMS зарегистрирована в Едином реестре российских программ для электронных вычислительных машин и баз данных под номером 311 (Минкомсвязь России).

Рисунок 3. Архитектура JaСаrta Management System

В состав JMS входят следующие компоненты:

• Сервер JMS — ядро JMS, обеспечивающее централизованное управление учетными записями пользователей, токенами, политиками и т. д. Возможен вариант установки нескольких серверов в кластере. Поддерживается виртуализация и резервное копирование закрытых ключей, баз данных и настроек системы.
• Консоль управления JMS — консоль администратора, позволяющая регистрировать пользователей, выполнять операции с токенами пользователей, настраивать профили выпуска, создавать и редактировать глобальные группы JMS, выполнять планы обслуживания. Доступные объекты и операции в консоли соответствуют роли и полномочиям конкретного администратора.
• Клиент JMS — клиентский агент JMS на стороне пользователя, который выполняет функцию синхронизации содержимого токена с данными на сервере, а также позволяет пользователю выполнять ряд операций с токеном в рамках сервиса самообслуживания (выпуск, разблокировка, замена).
• База JMS — обеспечивает централизованное хранение информации об учетных записях пользователей JMS, токенах, объектах, выпущенных на токены, политиках, настройках JMS и т. д. Значимая информация хранится в криптохранилище.
• Криптохранилище — виртуальный объект (область базы данных), где хранятся защищенные данные (закрытые ключи, PIN-коды и т. д.). Криптохранилище создается в процессе первоначальной настройки конфигурации JMS. Доступ к монтированию криптохранилища имеет только авторизованный оператор по предъявлению токена с сертификатом.
• JMSServerAPI— открытый API для разработки коннекторов к удостоверяющим центрам и ресурсным системам, собственного клиентского ПО, а также для интеграции с другими ИТ- и ИБ-системами предприятия.

Подробная информация о JMS доступна на сайте разработчика.

Сервер аутентификации JaCarta Authentication Server

JaCarta Authenticaton Server (JAS) — автономный высокопроизводительный сервер для усиленной аутентификации по одноразовым паролям (OTP) при доступе к корпоративным системам (CRM, порталы, почта и т. д.), в том числе Microsoft SharePoint и Microsoft Outlook Web App, web-сайтам и облачным сервисам, системам ДБО, а также удаленным рабочим столам (VMware Horizon View и Citrix XenApp/XenDesktop).

Применение JAS позволяет обеспечить надежную защиту доступа к ресурсам и сервисам организации, в том числе с планшетов и смартфонов (поддерживаются Google Authenticator и отправка пароля по SMS), а также повысить лояльность и удовлетворенность пользователей, так как процесс аутентификации заметно упрощается.

Преимуществами JAS являются автономность (для работы не требуется приобретать дополнительное ПО), высокая производительность (более 1000 аутентификаций в секунду на одном сервере), надежность (с помощью Microsoft Failover Cluster и репликации базы данных средствами Microsoft SQL Server) и масштабируемость.

JAS совместим с токенами JaCarta WebPass, eToken PASS, eToken NG-OTP (Java), Google Authenticator и поддерживает генерацию OTP по событию. Для интеграции с прикладным ПО реализована поддержка протоколов RADIUS, REST, WCF и WS-Federation, для интеграции с SMS-шлюзами — протоколы HTTP и SMPP.

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

JAS зарегистрирован в Едином реестре российских программ для электронных вычислительных машин и баз данных под номером 2128 (Минкомсвязь России).

Рисунок 4. Архитектура JaСаrta Authentication Server

В состав сервера JAS входят следующие компоненты:

• Сервер аутентификации: реализован в виде сервиса Microsoft Windows — Aladdin JAS Engine Service
• OTP-кэш: информация о токенах считывается в оперативную память из базы данных при старте сервиса, что обеспечивает высокую производительность.
• Текущие значения счетчиков: обновляются при выполнении служебных операций через Консоль управления.
• Консоль управления JAS (Агент JAS)
• Управление токенами и пользователями.
• Может быть установлена на отдельный компьютер.
• Хранилище учетных записей: 
• Microsoft SQL Server.
• Microsoft Active Directory / Microsoft Security Account Manager.
• База данных 
• Хранение информации о токенах и пользователях.
• Достаточно установить только один компонент — Microsoft SQL Server Database Engine.
• База данных создается автоматически в процессе настройки сервера JAS.
• Доступные режимы аутентификации пользователя базы данных:
• средствами Microsoft Windows;
• средствами Microsoft SQL Server.

Решение JC-WebClient

• JC-WebClient — решение для работы с токенами JaCarta в web-приложениях и облачных сервисах, реализованное на базе единой технологии локального web-сервера. Применение JC-WebClient позволяет легко реализовать в web-приложениях:
• строгую двухфакторную взаимную аутентификацию пользователя и web-сервера;
• формирование и проверку усиленной квалифицированной ЭП;
• шифрование данных, передаваемых между клиентским ПК и web-сервером.

Одной из главных особенностей JC-WebClient является поддержка всех популярных браузеров на платформах Microsoft Windows, Apple macOS и Linux, в том числе браузера Microsoft Edge в Microsoft Windows 10.

JC-WebClient предоставляется бесплатно, при его использовании не требуется приобретать программное СКЗИ, а использование единой технологии для всех популярных браузеров исключает расходы на адаптацию web-приложения под различные версии браузеров.

Для встраивания решения предоставляется комплект разработчика JC-WebClient SDK, который включает в себя подроб­ное руководство по встраиванию и исчерпывающий перечень примеров с исходными кодами.

Рисунок 5. Архитектура JaСаrta JC-WebClient

Состав JC-WebClient:

Приложение JC-WebClient — реализует технологию локального web-сервера.

• Обеспечивает взаимодействие между web-страницей и токеном по протоколу HTTPS.
• Предоставляет web-страницам JavaScript API для доступа к функциям токена через клиентский скрипт JCWebClient.js, который загружается на web-страницу от локального web-сервера.
• Работает в фоновом режиме, не предоставляя никаких элементов управления пользователю.

Сервис мониторинга — запускает приложение JC-WebClient при загрузке операционной системы (ОС).

• Контролирует целостность приложения и перезапускает его при возникновении нештатных ситуаций в ОС.
• Обеспечивает надежность и отказоустойчивость решения.

USB-токен или смарт-карта JaCarta ГОСТ (eToken ГОСТ)

• Является персональным средством строгой двухфакторной аутентификации и усиленной квалифицированной ЭП с неизвлекаемым закрытым ключом и реализует российские криптоалгоритмы.
• Могут использоваться токены JaCarta ГОСТ (eToken ГОСТ), уже находящиеся в эксплуатации.

Опция «Антифрод-терминал» — Trust Screen-устройство для работы с ЭП в недоверенной среде.

• Обеспечивает усиленную защиту от атак на ЭП при работе пользователя в недоверенной среде.
• Поддерживает режимы работы со смарт-картой и с USB-токеном.

Решение JC-Mobile

JC-Mobile — решение, позволяющее организовать безопасный доступ сотрудников, партнеров и клиентов к сервисам организации с мобильных устройств, обеспечить юридическую значимость подписываемых электронных документов и производимых операций, а также гарантировать безопасное хранение ключей и цифровых сертификатов на отчуждаемом модуле безопасности (смарт-карте или MicroUSB-токене JaCarta ГОСТ или JaCarta PKI).

JС-Mobile поддерживает мобильные устройства на базе Apple iOS и Google Android. Кроме этого, токены JaCarta в составе решения можно подключать к компьютерам и ноутбукам на базе Microsoft Windows, Apple macOS или Linux через специальные адапте­ры или смарт-карт ридеры.

Apple iOS

Для применения JaCarta с мобильными устройствами на базе Apple iOS необходимо провести работы по интеграции токенов в мобильное приложение с использованием библиотек из состава решения JC-Mobile и приобрести специализированный смарт-карт ридер с разъемом 30-pin или Lightning (Jailbreak не нужен!) или беспрово­дной смарт-картридер.

Google Android

JaCarta, выполненная в виде MicroUSB-токена, делает возможным аутентификацию и ЭП на мобильных платформах на базе Google Android (если они имеют MicroUSB-разъем). Для этой цели также можно использовать смарт-карты JaCarta (с помощью беспроводного смарт-картридера с подключением по Bluetooth-интерфейсу).

Рисунок 6. Архитектура JaСаrta JC-Mobile

Решение «Антифрод-терминал»

«Антифрод-терминал» представляет собой TrustScreen-устройство для работы с ЭП в недоверенной среде. Основными областями применения «Антифрод-терминала» являются защита систем ДБО от атак, направленных на кражу денежных средств со счетов клиентов банка, а также защита систем электронного документооборота и электронных сервисов от атак, направленных на подписание поддельных документов на ключах ЭП легального пользователя и последующее навязывание этих поддельных документов системе или сервису.

Если в качестве средства ЭП используется смарт-карта, она может быть подключена непосредственно к «Антифрод-терминалу». Если в качестве средства ЭП используется USB-токен, он подключается к одному USB-порту компьютера, а «Антифрод-терминал» — к другому.

«Антифрод-терминал» позволяет осуществлять безопасную аутентификацию, визуализировать ключевые данные документа перед его подписью, фиксировать в журнале проводимые операции для их последующего анализа, а также осуществлять групповые операции с документами с использованием белых списков.

Для работы «Антифрод-терминала» требуется интеграция защищаемых сервисов с решением JC-WebClient.

Рисунок 7. Схема работы «Антифрод-терминала»

Решение для двухфакторной аутентификации JaCarta SecurLogon

JaCarta SecurLogon — программно-аппаратное решение, позволяющее осуществить простой и быстрый переход от обычных паролей к двухфакторной аутентификации при входе в ОС Microsoft или доступе к сетевым ресурсам за счет использования USB-токенов и смарт-карт JaCarta и eToken. Вместо сертификатов JaCarta SecurLogon генерирует сложные пароли (до 63-х символов), которые неизвестны пользователям и записываются на токен, поэтому для его работы не требуется разворачивать Active Directory или создавать собственный удостоверяющий центр.

Для начала эксплуатации JaCarta SecurLogon достаточно сделать три простых шага: приобрести токены JaCarta и лицензии JaCarta SecurLogon, уста­новить на рабочие места приложение Единый Клиент JaCarta и активировать в нем функциональность JaCarta SecurLogon. При начальной настройке системы пользователь может выбрать предпочтительный сценарий входа: по PIN-коду или отпечатку пальца (если приобретены токены JaCarta PKI/BIO). Так как пользователь не знает настоящий пароль, он не может записать и скомпрометировать его.

Основные преимущества использования JaCarta SecurLogon:

• сокращение затрат — применение JaCarta SecurLogon не требу­ет настройки Active Directory, развертывания PKI-инфраструктуры и закупки дорогостоящего серверного оборудования и ПО;
• сложность подбора пароля — на подбор пароля в 40-60 символов у злоумышленника уйдут годы, а пользователь не знает и не может увидеть свой пароль, сохраненный на токене;
• простота использования — для доступа в систему необходимо ввести PIN-код токена или предоставить биометрическую информацию, что избавляет от необходимости запоминать сложные пароли;
• автоматические генерация и изменение паролей согласно настройкам (например, раз в неделю);
• упрощенная установка и поддержка — JaCarta SecurLogon является расширением функциональности бесплатного Единого Клиента JaCarta и становится доступным сразу после того, как будет приобретена и установлена соответствующая лицензия;
• плавный переход на PKI-инфраструктуру —если в памяти токена имеется сертификат пользователя и соответствующий закрытый ключ, JaCarta SecurLogon позволяет использовать их для входа в домен Microsoft Windows или сетевой ресурс вместо логина и пароля. В результате можно обеспечить плавный переход от парольной аутентификации к строгой двухфакторной аутентификации с использованием цифровых сертификатов;
• сертификат ФСТЭК России по 4 уровню контроля недекларированных возможностей (сертификат № 3575), позволяющий использовать его для защиты информации в ИСПДн до 1 уровня включительно и при создании автоматизированных ИС до класса защищенности 1Г включительно.

Подробная информация о JaCarta SecurLogon доступна на сайте разработчика.

Выводы

Одной из основных тенденций российской ИТ-отрасли является встраивание отечественных СКЗИ в информационные системы и программные средства, разработанные за рубежом. Усиление государственного регулирования в сфере ИБ способствует развитию отечественного рынка средств защиты информации. Платформа JaCarta — семейство продуктов и решений от российской компании «Аладдин Р. Д.», в которых учтены требования законодательства России и отечественных регуляторов. Они подойдут как средним и крупным коммерческим организациям, так и государственным учреждениям и предприятиям.

Токены JaCarta выпускаются в различных исполнениях, которые имеют одинаковую функциональность. Они идеально подходят для использования в системах ДБО, на мобильных платформах, при проведении электронных торгов и осуществлении юридически значимого электронного документооборота.

Дополнительные системы, призванные облегчить работу с токенами JaCarta, такие как JaCarta Management System и JaCarta Authentication Server, позволяют значительно сократить временные и финансовые затраты на поддержание инфраструктуры токенов, одновременно обеспечив более высокий уровень ИБ и удобство пользователей.

Бесплатные решения JC-WebClient и JC-Mobile позволяют быстро реализовать функции аутентификации и обеспечить юридическую значимость осуществляемых операций при работе с сайтами, Web-приложениями, облачными сервисами, а также в мобильных приложениях.

Наличие сертификатов ФСТЭК России и ФСБ России позволяет применять токены JaCarta и решения на их основе в государственных системах и ИСПДн.

В этой статье мы покажем, как внедрить двухфакторную аутентификацию пользователей в домене Windows с помощью open source продукта multiOTP. MultiOTP эта набор php скриптов и утилит, который реализует протокол OATH для HOTP/TOTP (Time-based One Time Password). Возможно использовать как в Windows, так и через RADIUS для реализации 2FA практически в чем угодно.

После внедрения multiOTP для входа пользователя Windows будет запрашивать дополнительный одноразовый пароль (OTP – one time password), который пользователь должен получить со своего мобильного устройства (приложение Microsoft или Google Authenticator, или другого генератора OTP). Вы можете настроить двухфакторную аутенфтикацию для входа на рабочие станции Windows, или для удаленного RDP доступа к хостам RDS на Windows Server.

Основные преимущества multiOTP — ему не нужен доступ в интернет, и можно использовать для внедрения двухфакторной аутентификации пользователей в изолированных сетях. Большинство аналогов платные или требуют прямого доступа к интернету.

Установка и настройка MultiOTP в домене Active Directory

В этом разделе мы покажем, как установить MultiOTP в Windows Server 2019 и настроить синхронизацию пользователей из Active Directory.

Также вы можете развернуть MultiOTP с помощью готового образа OVA для VMware, виртуальной машины Hyper-V или Docker контейнера.

Начнем с настройки сервера MultiOTP, который будет получать пользователей из Active Directory, генерировать уникальные QR коды для пользователей и проверять правильность второго фактора.

Создадим в Active Directory отдельную группу и добавим в нее пользователей, для которых мы будет требовать проверку второго фактора при входе в Windows. Создадим группу с помощью PowerShell:

New-ADGroup 2FAVPNUsers -path 'OU=Groups,OU=Moscow,dc=winitpro,DC=ru' -GroupScope Global -PassThru –Verbose

Добавьте пользователей в группу:

Add-AdGroupMember -Identity 2FAVPNUsers -Members kbuldogov, user1, user2

Создайте в AD нового пользователя multiotp_srv, который будет использоваться multiotp для доступа к AD (с минимальными привилегиями).

$passwd = ConvertTo-SecureString -String "[email protected]!" -AsPlainText -Force
New-ADUser -Name "multiotp_srv" -SamAccountName "multiotp_srv" -UserPrincipalName "[email protected]" -Path "OU=ServiceAccounts,OU=Moscow,DC=winitpro,DC=ru" –AccountPassword $passwd -Enabled $true

Скачайте архив с файлами MultiOTP с сайта разработчиков https://download.multiotp.net/.

Откройте архив multiotp_5.8.2.9.zip и извлеките из него каталог windows в папку на локальном диске (C:MultiOTP).

Откройте командную строку и перейдите в каталог с утилитой multiotp.exe:

CD C:MultiOTPwindows

Следующими командами мы настроим MultiOTP для получения пользователей из LDAP каталога Active Directory.

multiotp -config default-request-prefix-pin=0
multiotp -config default-request-ldap-pwd=0
multiotp -config ldap-server-type=1
multiotp -config ldap-cn-identifier="sAMAccountName"
multiotp -config ldap-group-cn-identifier="sAMAccountName"
multiotp -config ldap-group-attribute="memberOf"
multiotp -config ldap-ssl=0
multiotp -config ldap-port=389

REM Адрес контроллера домена

multiotp -config ldap-domain-controllers=msk-dc03.winitpro.ru,ldap://192.168.13.10:389
multiotp -config ldap-base-dn="DC=winitpro,DC=ru"

REM Учетная запись для аутентификации multiotp в AD:

multiotp -config ldap-bind-dn="CN=multiotp_srv,OU=ServiceAccounts,OU=Moscow,DC=winitpro,DC=ru"
multiotp -config ldap-server-password="[email protected]!"

REM группа пользователей, для которых нужно включить OTP

multiotp -config ldap-in-group="2FAVPNUsers"
multiotp -config ldap-network-timeout=10
multiotp -config ldap-time-limit=30
multiotp -config ldap-activated=1

REM ключ для доступа к MultiOTP серверу

multiotp -config server-secret=secretOTP

Ранее мы создали группу 2FAVPNUsers и добавили в нее 3 пользователей. Выполните синхронизацию пользователей AD в MultiOTP.

multiotp -debug -display-log -ldap-users-sync

OG 2022-01-17 14:36:44 info LDAP Info: 3 users created, based on 3 LDAP entries (processed in 00:00:00)
LOG 2022-01-17 14:36:44 debug System Info: *File created: c:MultiOTPwindows.usersa.ivanov.db

В данном случае MultiOTP обнаружила трех пользователей и синхронизировала их.

Запустите с правами администратора файл webservice_install.cmd. Это установит веб интерфейс управления MultiOTP.

Зайдите на веб-интерфейс
http://127.0.0.1:8112/
под учётной запись admin с паролем 1234 (желательно сменить при входе).

Настройка двухфакторной аутентификации MultiOTP для пользователя домена

В разделе List of users будет доступен список пользователей домена, которые были синхронизированы ранее (источник AD/LDAP).

Выберите пользователя и нажмите Print. Перед вами появится QR код пользователя, который нужно добавить в приложение-аутентфикатор.

Установите на смартфон пользователя приложение Microsoft Authenticator (или Google Authenticator) из Google Play или App Store. Запустите его и отсканируйте QR код пользователя.

В результате в приложении появится учетная запись пользователя, в которой каждые 30 секунд генерируется новый шестизначный цифровой пароль (тот самый второй фактор).

Из командной строки можно проверить, что MultiOTP позволяет аутентифицировать данного пользователя с помощью OTP:

multiotp.exe -display-log kbuldogov 719854

где
719854
– одноразовый пароль, полученный из приложения.

LOG 2022-01-17 15:13:11 notice (user kbuldogov) User OK: User kbuldogov successfully logged in with TOTP token
Filter-Id += "2FAVPNUsers"

Также можно проверить корректность работы OTP из веб-интерфейса. Перейдите в раздел Check a user, введите имя пользователя и одноразовый пароль.

Установка multiOTP CredentialProvider в Windows

Следующий этап – установка multiOTP-CredentialProvider на компьютеры Windows, на которых вы хотите внедрить двухфакторную аутентификацию пользователей с помощью MultiOTP. CredentialProvider можно установить на все версии Windows 7/8/8.1/10/11 и Windows Server 2012(R2)/2016/2019/2022.

В это примере мы настроим двухфакторную аутентификацию для RDP входа пользователей на RDSH сервер на Windows Server 2019.

Скачайте и установите multiOTP CredentialProvider с GitHub https://github.com/multiOTP/multiOTPCredentialProvider/releases. На момент написания статьи эта версия
5.8.4.0
.

Запустите установку:

1. Укажите IP сервера, на котором был установлен multiOTP
2. В нижнее поле укажите секретное слово из конфигурации multiOTP (

   в нашем конфиге);

3. Выберите тип входа в Windows, для которых нужно применять аутентфикацию через OTP. В нашем примере мы ограничимся 2FA только для RDP входов (OTP authentication mandatory for remote desktop only).

Можно включить использование OTP аутенфтикации как для RDP так и для локальных входов.

MultiOTP CredentialProvider хранит настройки в реестре HKEY_CLASSES_ROOTCLSID{FCEFDFAB-B0A1-4C4D-8B2B-4FF4E0A3D978}. Если нужно, вы здесь можете изменить настройки CredentialProvider без переустановки.

Перезагрузите Windows Server RDS и попробуйте через RDP подключиться к нему. Теперь после отправки имени и пароля пользователя появляется дополнительное окно one-time password. Здесь пользователь должен ввести одноразовый пароль из приложения Authenticator на своем смартфоне.

На севере MultiOTP можно включить ведение логов, это полезно при отладке:

multiotp -config debug=1
multiotp -config display-log=1

Your script is running from C:MultiOTPwindows
2022-01-17 15:21:07 debug CredentialProviderRequest Info: *Value for IsCredentialProviderRequest: 1 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *CheckUserToken server request. 0 SPB-SRV01
2022-01-17 15:21:07 notice kbuldogov User OK: User kbuldogov successfully logged in (using Credential Provider) with TOTP token 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *Cache level is set to 1 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *Server secret used for command CheckUserToken with error code result 0: secretOTP 0 SPB-SRV01

Не забудьте убедиться, что ваш домен синхронизирует время с тайм-серверами в интернете и время на клиентах не разбегается. Эти критично для работы OTP.

В любом случае перед массовым внедрением 2FA на базе MultiOTP в вашей сети рекомендуем в течении пары недель протестировать все режимы работы и нештатные ситуации (недоступность сервера MultiOTP, DC, ошибки в CredentialProvider и т.д.). Если возникли существенные проблемы со входом через MultiOTP, вы можете удалить CredentialProvider в безопасном режиме.

На этом настройка двухфакторной аутентификации в Windows Server с помощью MultiOTP закончена. Доступны сценарии использования MultiOTP с RADIUS сервером, для аутентификации практически любых типов клиентов через OTP. Также вы можете использовать OTP для дополнительной зашиты RDP серверов в интернете от брутфорса в дополнении к https://winitpro.ru/index.php/2019/10/02/blokirovka-rdp-atak-firewall-powershell/.

 СТАНИСЛАВ ШПАК, более десяти лет занимается сопровождением Active Directory и Windows-серверов

Внедряем смарт-карты в домене

Смарт-карты – это не только усиление безопасности, но и лишняя статья расходов в бюджете ИТ-отдела, а также дополнительная работа для системного администратора. Но если вы все-таки решили начать использовать смарт-карты в вашем домене или его части, то давайте посмотрим, как это сделать и как избежать некоторых проблем и ошибок

Ранее в «Системном администраторе» я рассматривал процесс развертывания системы PKI в домене [1-3]. Опираясь на эту структуру, сейчас рассмотрим процесс внедрения смарт-карт в домене.

Основной целью будет являться переход на двухфакторную проверку подлинности пользователя при входе в домен, хотя возможности смарт-карты этим не ограничиваются. Двухфакторная аутентификация подразумевает наличие двух компонентов: что-то, что вы знаете, и что-то, что вы имеете. Классическая аутентификация обычно ограничивается только первым компонентом, в качестве которого применяется пароль, который пользователь предъявляет при входе в систему. Смарт-карта в этом процессе представляет собой второй компонент, при этом первый – это PIN-код, который пользователь должен ввести после помещения карты вкарт-ридер (см. рис. 1).

Рисунок 1. Диалог входа в Windows при использовании смарт-карты

Существуют две категории смарт-карт: карты памяти и микропроцессорные карты. Первая категория содержит только энергонезависимую память, вторая – еще и микропроцессор. Любой крупный производитель смарт-карт выпускает карты обоих типов, поэтому обращайте внимание на спецификацию. Микропроцессорные карты, кроме хранения информации, могут еще производить различные вычислительные операции. Нас интересует подмножество микропроцессорных карт – криптографические карты (микропроцессорные карты, производящие криптографические операции). Они существенно повышают безопасность системы, так какв этом случае закрытый ключ (private key) не покидает пределы смарт-карты.

Обычная смарт-карта по форм-фактору представляет собой аналог банковской пластиковой карточки. Считывание данных с такой смарт-карты производится специальным устройством – «смарт-карт-ридером», в который помещается смарт-карта. В настоящее время все шире используется другой вариант исполнения смарт-карты – USB-токен. Внешне он очень похож на обычный USB-флеш-накопитель: совмещает в себе смарт-карту плюс карт-ридер и вставляется непосредственно в USB-разъем компьютера без каких-то дополнительных устройств. USB-токен кажется удобнее, однако на обычную смарт-карту можно нанести информацию осотруднике и использовать еще и как удостоверение личности. Какой вариант лучше – решать вам, каждый имеет свои плюсы и минусы, причем в зависимости от условий применения. Например, в случае использования USB-токенов нет необходимости оборудовать рабочие места смарт-карт-ридерами, и это может быть как плюсом, так и минусом. Все, о чем будет говориться далее в статье, одинаково применимо как к обычным «пластиковым» смарт-картам, так и к USB-токенам.

Приложения в Windows работают со смарт-картами по следующей цепочке [4]: «Приложение → Поставщик служб для смарт-карты (Smart Card Service Provider) → Менеджер ресурсов смарт-карты (Smart Card Resource Manager (Win32API)) → Драйвер карт-ридера → Карт-ридер → Смарт-карта».

В этой цепочке между приложением и менеджером ресурсов (который представляет собой Windows-компонент) располагаются поставщик служб смарт-карты и, в частности, его подмножество: «поставщик служб криптографии» (CSP – Cryptography Service Provider). Это программный компонент, который должен быть написан производителем смарт-карты с помощью программного интерфейса Microsoft CryptoAPI. В стандартную комплектацию Windows XP и 2003 входит поддержка CSP только для шести моделей смарт-карт от трех производителей (Gemplus, Infineon и Schlumberger). Таким образом, мы приходим к тому, что в среде Windows поддерживаются только смарт-карты, CSP которых был разработан с использованием MS CryptoAPI и установлен в системе.

Поскольку вряд ли вам удастся приобрести смарт-карты вышеназванных моделей, то важный вывод, который мы сделаем здесь и к которому еще вернемся позже: кроме смарт-карты, потребуется еще и CPS для нее, иначе Windows не сможет с ней работать. В этом случае вы получите ошибку: «The card supplied requires drivers that are not present on this system. Please try another card». (Имеющаяся плата требует наличия драйверов, отсутствующих в системе. Попробуйте использовать другую плату.)

Опустим особенности перевода слова «card» как «плата», из-за которого смысл ошибки на русском языке несколько искажается. Кроме того, смарт-карту перед использованием надо инициализировать – штатных средств для этого в Windows также не предусмотрено, поэтому вопрос сопутствующего программного обеспечения надо оговаривать с поставщиком смарт-карт заранее.

Перейдем от теории к практике. Для того чтобы в нашем домене можно было входить в систему с использованием смарт-карт, нам потребуются следующие компоненты:

• Active Directory;
• микропроцессорная смарт-карта (плюс смарт-карт ридер) или USB-токен;
• драйверы карт-ридера и программное обеспечение смарт-карты;
• развернутая в домене инфраструктура открытого ключа (подразумевает наличие хотя бы одного центра сертификации уровня предприятия (enterprise CA);
• наличие сертификатов типа enrollment agent (агент подачи заявок), позволяющих выпускать сертификаты от имени других пользователей.

Теперь рассмотрим подробно все вышеперечисленные пункты, кроме, разве что, Active Directory.

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

Выбор смарт-карты и подготовка компьютера

Для начала нам надо определиться, какой тип смарт-карты мы хотим использовать. Будут ли это обычные пластиковые смарт-карты, либо USB-токен, и какой объем памяти должен быть на смарт-карте.

Имейте в виду, что около 16 Кб будет занимать операционная система смарт-карты, а место, занимаемое пользовательским сертификатом, будет зависеть от длины ключа. Конечно, даже на смарт-карте с 32 Кб памяти хватит места для размещения сертификата пользователя, однако не надо забывать, что на ней можно хранить и дополнительные данные.

Для пробы я решил воспользоваться обоими видами смарт-карт и приобрел 64 Кб смарт-карту Siemens и USB-карт-ридер для нее, а также 64 Кб USB-токен Charismatic. В комплектацию поставки пластиковой смарт-карты входила только сама карта, а к токену еще прилагался комплект ПО. Карт-ридер также поставлялся без драйверов, однако на сайте продавца были все необходимые ссылки на сайт производителя, где без труда удалось раздобыть драйвер для Windows XP.

Здесь будет весьма уместно вспомнить о том, что для смарт-карты потребуется еще и CSP. Поскольку к смарт-карте никакого ПО не прилагалось, то Windows отказалась записывать на смарт-карту данные, поскольку карта была не инициализирована и CSP для нее не был установлен в системе.

Исследование Интернета на предмет нужного ПО показало, что таковое имеется, но является платным – например, комплект нужного ПО для Siemens CardOS стоил чуть меньше 20$ с лицензией на 1 ПК.

Не будучи уверенным, что все понял правильно, я связался с поставщиком смарт-карт, где меня заверили, что так оно и есть, но они предоставляют ПО от Charismatic, которое работает не только с одноименными токенами, но и с некоторыми смарт-картами. Действительно, так и оказалось, однако скачать это ПО с сайта производителя было нельзя и пришлось получать его от поставщика смарт-карт. Имейте это в виду.

Итак, действия, которые нужно выполнить на этом шаге: подключить и установить драйверы карт-ридера либо USB-токена (для него тоже могут понадобиться драйверы), установить прилагаемое ПО, которое как минимум должно включать в себя СSP (обычно один или несколько dll-файлов) и пользовательский интерфейс для инициализации и работы со смарт-картой/токеном. Инициализировать смарт-карту или токен – требуемые действия тут могут отличаться в зависимости от используемого ПО. На рис. 2 представлен пример инициализации токена с помощью программы Charismatic Smart Security Interface Manager.

Рисунок 2. Инициализация смарт-карты

Настройка доменного окружения

Теперь перейдем к настройке доменного окружения. В качестве PKI в домене будем опираться на структуру, которая рассматривалась в [1-3]. Напомню, что речь шла о цепочке из трех серверов сертификации, первые два из которых были изолированные корневой и подчиненный центры сертификации (Certificate Authority – СА), а третий – подчиненный СА уровня предприятия с именем EntCA. Все настройки, связанные с внедрением смарт-карт, будут выполняться именно на этом СА.

Смарт-карта для пользователя выпускается следующим образом: сотрудник со специальным сертификатом, пользуясь специально подготовленной рабочей станцией, через веб-страницу запрашивает с центра сертификации предприятия сертификат для пользователя. Этот сертификат помещается на заранее инициализированную смарт-карту, которая и вручается пользователю.

Сертификаты, позволяющие запрашивать пользовательские сертификаты для смарт-карты, – это Enrollment Agent (агент подачи заявок) и Enrollment Agent (Computer) (агент подачи заявок (компьютер)). Первый устанавливается в локальное хранилище сертификатов пользователя, второй – в локальное хранилище сертификатов компьютера, с которого будет производиться запрос сертификатов для смарт-карты. Чтобы выпустить сертификаты типа Enrollment Agent, надо подготовить их шаблоны. Процедура аналогична описанной в [3]. Скажу лишь, что ввиду высокой важности рекомендуется права на выпуск этого типа сертификатов дать лишь одному пользователю и одному компьютеру – тому, который и будет заниматься выпуском смарт-карт.

Кроме того, надо подготовить шаблоны сертификатов пользователя для смарт-карты. Существует два таких шаблона: Smartcard Logon (вход со смарт-картой) и Smartcard User (пользователь со смарт-картой). Первый используется только для входа в систему по смарт-карте, второй – для входа в систему и шифрования. Проверьте, что для выбранного вами шаблона имеются права Enroll (выпуск) для доменной группы EnrollmentAgent.

Выпуск смарт-карты

Для выпуска смарт-карты на рабочую станцию, у которой есть право Enroll для шаблона Enrollment Agent (Computer), в систему должен войти пользователь, имеющий право Enroll для шаблона Enrollment Agent. Далее через веб-интерфейс нужно обратиться к центру сертификации (в нашем случае это адрес http://EntCA/certsrv, где EntCA – имя сервера). Имеет смысл предварительно добавить этот адрес в список доверенных узлов в настройке безопасности браузера, иначе потом можно столкнуться с блокированием ActiveX-компонента.

На открывшейся странице из списка предложенных вариантов надо выбрать Request a certificate (запрос сертификата), тем самым перейдя на страницу с тремя пунктами, последний из которых Request a certificate for a smart card on behalf of another user by using the smart card certificate enrollment station (запросить сертификат для смарт-карты от имени другого пользователя, используя станцию подачи заявок смарт-карт). Остановимся в этом месте подробнее (см. рис. 3).

Рисунок 3. Страница выбора вариантов для запроса сертификата

Я очень много времени провел в поисках причины того, почему на этой странице в моем случае были только первые два пункта и отсутствовал третий. Причем в тестовом домене он был, а в рабочем – нет. Не найдя ничего связного в Интернете, пришлось обратиться к файлам, формирующим веб-страницу СА. Оказалось, что проблема кроется в файле certrqad.asp, который находится в %SYSTEMROOT%system32certsrv. При сравнении этого файла между тестовым и корпоративным СА оказалось, что в рабочем отсутствует следующий раздел:

<% If bNewThanNT4 And "Enterprise"=sServerType Then %>
<TR>
	<TD><Img Src="certspc.gif" Alt="" Height=10 Width=1></TD>
</TR>
<TR>
	<TD><A Href="certsces.asp"><LocID ID=locLblSmartcard>
	Request a certificate for a smart card on behalf of another user
	by using the smart card certificate enrollment station.</LocID></A>
	<LocID ID=locAdminWarn><Font Size=-1><BR>
	Note: You must have an enrollment agent certificate to submit a
	request on behalf of another user.</Font></LocID>
	</TD>
</TR>
<%End If%>

В статье [3] я писал о том, что СА под управлением Windows Server 2003 не совместим с Windows Vista, и говорил о необходимости установки обновления KB922706 для Windows 2003. Однако, как оказалось, именно после установки этого обновления с веб-страницы СА пропадает пункт запроса сертификата для смарт-карты.

Решение проблемы заключается в том, чтобы вручную добавить эту часть в файл certrqad.asp или же восстановить его из соответствующей папки резервной копии, которая создается автоматически в %Systemroot% при установке каждого обновления. После этого, возможно, потребуются перезапуск служб IIS на сервере и очистка кэша браузера на клиенте.

Итак, с этой проблемой мы разобрались, выбираем третий пункт и попадаем на страницу Smart Card Certificate Enrollment Station (станция подачи заявок смарт-карт) (см. рис. 4). Здесь надо выбрать, какой шаблон использовать (Smartсard User или Smartсard Logon), указать выпускающий СА и выбрать поставщика служб криптографии. В выпадающем списке CSP надо выбрать именно тот CSP, который устанавливался для вашего типа смарт-карты, иначе процесс записи сертификата на смарт-карту окончится неудачей. Если на компьютере установлен более чем один сертификат типа Certificate Request Agent, то в поле Administrator Signing Certificate (сертификат подписи администратора) можно выбрать сертификат нужного администратора.

Рисунок 4. Запрос сертификата для смарт-карты

Ну и самое главное – в разделе User to enroll (заявляемый пользователь) надо выбрать пользователя, чей сертификат будет помещен на смарт-карту. Когда это будет сделано, справа внизу страницы появится кнопка Enroll (подать заявку), после нажатия на которую система попросит вас вставить смарт-карту, ввести PIN-код (устанавливаемый при инициализации) и произведет на нее запись всех нужных данных.

Замечание: в среде Windows не существует штатных средств по смене PIN-кода смарт-карты, эти средства обычно поставляются в составе ПО смарт-карты.

Использование смарт-карты

Теперь мы имеем рабочую смарт-карту с сертификатом пользователя. Для того чтобы начать ее использовать, не требуется никаких особых настроек на компьютере пользователя, кроме установки драйверов для смарт-карт-ридера и ПО смарт-карты. После этого достаточно вставить смарт-карту в карт-ридер (или токен в USB-разъем), как стандартное окно запроса пароля при входе в систему сменится на запрос PIN-кода (см. рис. 5).

Рисунок 5. Вход в систему с использованием смарт-карты

Сменить PIN-код пользователь может с помощью ПО смарт-карты. В случае если PIN-код забыт, администратор с помощью административного пароля может установить новый PIN-код, а если утерян и административный PIN-код, можно повторно инициализировать смарт-карту с помощью системного PIN-кода. В этом случае все данные, содержащиеся на смарт-карте, будут уничтожены. Если утерян и системный PIN-код, смарт-карту можно смело выбрасывать.

На одну смарт-карту можно поместить несколько сертификатов, однако для входа в систему Windows XP/2003 будет использоваться только один – так называемый «контейнер по умолчанию». Его можно определить с помощью ПО смарт-карты. Для Windows Vista этого ограничения уже нет – в этой ОС можно указать, какой сертификат из имеющихся на карте нужно использовать для входа – по крайней мере это заявлено в документации.

Смарт-картой можно пользоваться и при входе на удаленные компьютеры по RDP-протоколу. Для этого в свойствах RDP-подключения надо на вкладке Local Resources (локальные ресурсы) нажать кнопку More (еще) и установить опцию Smart Card (смарт-карта) – однако и тут надо помнить о том, что на удаленном компьютере должно стоять все необходимое для работы смарт-карты ПО, иначе вы получите ошибку, о которой говорилось ранее в разделе «Общие сведения».

Что касается пользовательских настроек Active Directory, то для работы со смарт-картами предусмотрены две опции. Обе доступны в ветке: Local Computer Policy → Computer Configuration → Windows Settings → Security Settings → Local policies → Security Options («Локальная политика компьютера → Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Локальные политики → Параметры безопасности»).

Первая опция Interactive logon: Require smart card (вход в систему: требуется смарт-карта) может принимать состояние Enable (включено) или Disable (выключено) и при включении означает безусловную необходимость в смарт-карте при входе в систему. В этом случае без смарт-карты пользователь не сможет осуществить вход. Это надо иметь в виду, так как может возникнуть ситуация, когда пользователь забыл или потерял смарт-карту, или же требуется войти в домен через компьютер, на котором не установлены драйвер карт-ридера или ПО смарт-карты.

Вторая опция: Interactive logon: Smart card removal behavior (вход в систему: поведение при извлечении смарт-карты) означает поведение рабочей станции при изъятии смарт-карты из карт-ридера. Допустимыми состояниями являются No action (бездействие), Lock workstation (блокировка рабочей станции) и Force Logoff (выход из системы). Эта опция работает только при включенной первой опции.

Как я уже говорил, применение смарт-карты не ограничивается только входом в систему. В настоящее время многие приложения умеют хранить сертификаты на смарт-карте, например Mozilla Firefox, OpenVPN, TrueCrypt и др. Как использовать смарт-карту – это уже решать вам, но надеюсь, что эта статья поможет вам в самом начале процесса внедрения смарт-карт в домене.

1. Шпак С. Установка цепочки серверов сертификации как часть внедрения PKI в домене. Часть 1. //«Системный администратор», № 8, 2008 г. – С. 54-58. URL: http://samag.ru/archive/article/1764.
2. Шпак С. Установка цепочки серверов сертификации как часть внедрения PKI в домене. Часть 2. //«Системный администратор», № 10, 2008 г. – С. 60-64. URL: http://samag.ru/archive/article/1852.
3. Шпак С. Установка цепочки серверов сертификации как часть внедрения PKI в домене. Часть 3. //«Системный администратор», № 11, 2008 г. – С. 66-69. URL: http://samag.ru/archive/article/1874.
4. Smart Cards – http://technet.microsoft.com/en-us/library/dd277362.aspx.
5. Deploying Smart Cards – http://technet.microsoft.com/ru-ru/library/dd277383(en-us).aspx.
6. Blog about Smart Card infrastructure in Windows – http://blogs.msdn.com/shivaram.

Ключевые слова: smart cards, PKI, смарт-карта, домен.

Как в ОС Windows реализовать двухфакторную аутентификацию? Вот пришли мы как-то к такому вопросу и решено было проанализировать несколько разных типов решений. Из более интересных сразу были выделены нативное на базе Windows Hello сервиса + облачная 2FA для администраторов, а так же решение от RCDevs которое поддерживает вроде как целую кучу плюшек, но на деле все оказалось не так радостно, об этом как раз ниже.

Двухфакторная аутентификация с помощью Windows Hello

Плюсы решения Windows hello:

1. Более простая и удобная установка и настройка (по сути все уже есть, надо лишь это включить через политики)
2. Возможность интеграции с EMS Intune
3. Не требуется узобретать велосипеды

Из минусов хочу отметить такие моменты как:

1. Если не брать в расчет смарт карты, то оставался вариант с пин кодом, а пин в свою очередь не самое надежное решение в отличии от OTP кодов (OTP — One Time Password)
2. Не подходит для интеграции с Linux системами (хотя, там было еще одно интересное решение для линуксов, на базе open source проекта, с гитхаба)
3. Если речь заходила об аутентификации аля биометрической с помощью пальцев или камеры — работало через раз (ну это грубо говоря)

По вот тому набору пунтиков выше было решено отказаться от релазиации с Windows Hello. К тому же, там была отдельная аутентификация для администраторов в облаке Office 365, но это не самая большая проблема. С большего не понравилось решение с пин кодом, потому как он постоянно один и тот же и особого отличия от обычного пароля по факту не было бы.

Настройка двухфакторной аутентификации с RCDevs решением

А вот теперь давайте поговорим о более интересном, установке и настройке решения по 2FA от компании RCDevs. У них решение довольно универсальное и подходит не только для Windows ПК или серверов, но так же и под линукс платформы, есть возможность интеграции с веб-сайтами (имеется ввиду CMS), некоторыми облачными сервисами и еще какие-то там плюшки. Кроме того, до 50 юзеров в комплекте шли бесплатно!

Пробовал развернуть их приложение с нуля, как то не особо получилось, возможно из-за кучи заморочек с настройкой LDAP конфигов и разных «тонкостей» данной настройки введенной данным вендором, по этому после первого провала в «ручной» установке с нуля, было принято решение просто развернуть их виртуальный аплаинс (с их сайта можно скачать образ для импорта в VMWare или VirtualBox), поверьте — так будет гораздо проще, особенно если недо протестировать, ну и под это дело можно провести сверку конфигов, выявить ошибки, сделать по более живому примеру.

Еще одной проблемой считаю, отсутствие актуальной документации в нужных объемах. Вообще доков вроде бы хватает, они простые, но не все актуальные и подходят под последнии версии данной приблуды, а по некоторым вопросам доков и вовсе нет. Конечно же, еще есть видео на youtube которое тоже в какой-то степени что-то объясняет, но так, по мелочи.

Чтож, после того как скачали и развернули виртуальный инстанс пришла пора все это дело настраивать. Заходим в приложение, первый вход осуществляется с соблюдением всей структуры AD в LDAP (указываем контейнер, группу и юзера), попадаем в веб-морду.

Далее если вы устанавливали сами с нуля, то требуется докачивать, доставлять и включать все требующиеся модули по очереди, в случае если все же пошли по пути наименьшего сопротивления, то требуется лишь выполнить пару кликов в админке чтобы активировать нужные модули.

На главной страничке после логина там где указано «Not registered» регистрируем и включаем:

1. MFA Authentication Server
2. Single Sign-On Server
3. SSH Public Key Server
4. QR Login & Signing Server

Включал не все, т.к. для тестирования с большего интересовала лишь аутентификация по QR коду.

Далее заходим в Admin -> Local Domains и указываем путь к нужному контейнеру, где у нас будут все юзеры у которых хотели бы видеть двухфакторную аутентификацию. Можно конечно и не группами работать, а выдавать данную «привилегию» в индивидуальном порядке через настройки пользователя.

Выбираем юзера и далее заходим в MFA Authentication Servers, там выбираем Register / Unregister OTP Token, забиваем все данные, фоткаем QR Code через Google Authenticator и идем дальше.

Нам нужно будет выбрать метод логина пользователя: LDAP, OTP или кримеру LDAPOTP — это когда сразу вводишь доменные креды, а после еще добавочный одноразовый код который сгенерирует приложения гугла.

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

Выглядит это как-то так:

Довольно странно, правда? Но это можно зафиксить конечно же. В настройках безопасности в AD требуется просто отключить функцию показа истории залогиненых юзеров и оно должно прокатить. Я честно говоря самостоятельно не тестировал, ответа на вопрос «как это поправить» на официальном сайте разработчиков сие чуда так же нет, но попробовать как минимум стоит.

Сам же логин с двухфакторкой выглядит так:

Логотипчик можно менять, загрузить к примеру лого своей компании, с этим проблем нет даже при использовании бесплатной лицензии, выглядеть будет достойно. Сразу после ввода доменного пароля система у нас попросит ввести еще и временный код.

А вот при реализации данного подхода по RDP возникли трудности и пришлось немного еще поколупаться, потому как я не Windows администратор и сходу решить все не получилось. В случае если вам нужно использовать данную фичу по RDP то потребуется включить службу RDS и поднять RDWeb (который в свою очередь требует дополнительные лицензии мелкомягких), по этому от данного солюшена было решено отказаться, слишком топорно и много хлопот.

Для поднятия RDS и RDWeb Access я выполнял следующие манипуляции из гайдов и других блогов, но удобнее всего оказалось простенькое и полезное видео с ютубчика в котором по шагам все четно и понятно показывается. Конечно же, хардкорчик никто не отменял и можно пойти другим путем, к примеру воспользовавшись этим и/или этим гайдами.

Тонкости пересказывать не буду, там и так все будет понятно. Если кратко то суть в том, чтобы на сервере поднять сервис удаленного рабочего стола, настроить разделение сессий и работу через RDWeb в который можно добавлять как приложения по отдельности, так и линк на RDP сессию. Вот такие танцы с бубном, чтобы у нас RDP работало через 2FA.

По итогу оно и не завелось сразу, после некоторых костылей получилось вроде бы, но сути это не меняет — данное решение топорное. Хотя я не отрицаю, что для других примеров использования оно подойдет идеально — к примеру защитить ваш веб-сайт или приложение двухфакторкой, ведь поддерживается такая CMS как WordPress ну и до кучи всего остального, лучше список глянуть на сайте вендора.

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

Может быть интересно:

JaCarta известна не только своими защищёнными носителями, но и многофункциональным программным обеспечением. JaCarta SecurLogon входит в состав Единого клиента JaCarta, который является центром взаимодействия со всеми продуктами компании-разработчика «Аладдин Р.Д.».

В этой статье мы сделаем обзор этой программы, расскажем о её функциях и преимуществах, а также покажем примеры применения.

Функции SecurLogon

JaCarta SecurLogon — это программно-аппаратное решение по переходу от однофакторной аутентификации к двухфакторной. Простыми словами: вместо использования пары логин-пароль используется дополнительное средство безопасности USB-токены или смарт-карты с электронной подписью.

Встроенное решение помогает повысить уровень защиты при работе с сетевыми (и не только) ресурсами. JaCarta SecurLogon генерирует сложные пароли, которые могут включать в себя до 63 символов, а затем записывает их в токен или смарт-карту. Пользователям запоминать такой пароль, конечно, не нужно, а для работы достаточно помнить короткий пин-код.

Переход к двухфакторной аутентификации осуществляется без PKI и Active Directory, что значительно его облегчает. Чтобы пользоваться функциями SecurLogon, достаточно иметь токен или смарт-карту с электронной подписью, приобрести лицензию и активировать встроенное решение в едином клиенте.

Применение JaCarta SecurLogon

Приведём примеры использования JaCarta SecurLogon:

1. Вход в Windows можно осуществлять не с помощью обычного пароля (однофакторная аутентификация), а используя токен или смарт-карту (двухфакторная аутентификация).
2. Плавный переход на PKI (инфраструктуру открытых ключей), которая определяет политику выпуска цифровых сертификатов, их выдачу и аннулирование, а также хранение информации, необходимой для последующей проверки правильности сертификатов.
3. Автоматизация выполнения требований информационной безопасности в организации. Каждый сотрудник будет нести полную ответственность за использование данных, так как у него не смогут украсть пароль.

Преимущества JaCarta SecurLogon

Простая установка

JaCarta SecurLogon легко установить и легко использовать. Для установки нужно выполнить всего три действия:

1. Скачать дистрибутив «Единый клиент JaCarta» с официального сайта → «Центр загрузки».
2. Установить «Единый клиент JaCarta», следуя подсказкам установщика.
3. Купить лицензию на использование SecurLogon, а затем использовать встроенное решение в едином клиенте.

Быстрый доступ и удобство использования

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

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

Высокий уровень безопасности

По сравнению с однофакторной аутентификацией пары логин-пароль, JaCarta SecurLogon даёт очевидные преимущества:

• пароль не могут похитить или взломать;
• пользователь может использовать сервис с помощью пин-код или отпечатка пальца;
• пароль хранится на защищённом носителе — токене или смарт-карте;
• и без того сложный пароль (его не нужно запоминать пользователю) меняется каждый день.

Недавно мы рассказывали, как настроить 2FA аутентификацию на основе PKI-инфраструктуры и x509 сертификатов в виртуальной среде Citrix, используя электронные ключи JaCarta PKI. Сегодня речь пойдет о ближайшем «друге» Citrix XenDesktop в области доставки виртуальных рабочих столов и приложений – VMware Horizon View.

Как это работает?

Говоря простым языком, можно представить вот такую схему.

Двухфакторная аутентификация в VDI-сессию с использованием JaCarta PKI состоит из следующих шагов:

1. пользователь предъявляет токен (первый фактор — обладание устройством) и вводит PIN-код (второй фактор — знание PIN-кода);
2. на сервере происходит проверка учётных данных пользователя;
3. пользователь получает десктопприложение либо отказ в обслуживании.

Причины «подружить» VMware Horizon View с электронными ключами, впрочем, как и любое внедрение 2FA, имеют ряд плюсов по сравнению с классической аутентификацией по паролям. В первую очередь, это общее повышение уровня безопасности, которое происходит за счёт отказа от паролей и перехода к строгой аутентификации с использованием второго фактора аутентификации. Подробно на этом останавливаться не будем, есть достаточно статей, да и целых книг по теме. Во вторых, раз уж аутентификация по токенам или смарт-картам внедрена, ими можно и нужно пользоваться уже внутри VDI-сессии. Например, для электронной подписи в различных сценариях и программах, для доступа к различным web-приложениям, для систем электронного документооборота и систем дистанционного банковского обслуживания. Есть возможность использования как западных крипто алгоритмов, так и отечественный ГОСТ. Также к дополнительным преимуществам можно отнести то, что одна и та же карта может использоваться для аутентификации, подписи и доступа в помещение (при наличии RFID-метки). При этом предусмотрены варианты кастомизации — нанесение лого и фирменного стиля. А в рамках спец. проектов существует возможность реализации на этих же картах платежных приложений («Мир», MasterCard, Visa).

Вводные

Предполагается, что инфраструктура открытых ключей уже развернута в рамках Windows Server (версия не важна) с ролью Active Directory Certificate Services. VDI развернут в рамках VMware Horizon View 7 (работаем и с 6.x и c 5.x) и настроен на простую парольную аутентификацию. Еще одно условие — у пользователей имеются электронные ключи JaCarta с выпущенными на них цифровыми сертификатами от MSCA.

В качестве клиента используется любой ПК, тонкий клиент, ноутбук с установленным VMware Horizon Client.

Настройка

Вся настройка сводится к настройке сертификатов и включению опции аутентификации по сертификатам на сервере horizon view.

Экспорт корневого сертификата

Откройте оснастку Certification Authority на корневом ЦС, выполнив команду certsrv.msc

Откройте окно Certification Authority -> CA Name -> Properties

На вкладке General выберите корневой сертификат и нажмите кнопку View Certificate.

Перейдите на вкладку Details и нажмите кнопку Copy to File.

На странице выбора формата файла выберите Base-64 encoded X.509 (.CER)

Укажите путь экспорта файла, например, C:tempRootCA.cer

Создание файла-контейнера ключей JKS

На сервере VMware Horizon View откройте командную строку и перейдите в каталог с утилитой keytool.exe (C:Program FilesVMwareVMware ViewServerjrebin).

Импортируйте корневой сертификат в файл-хранилище с помощью команды keytool -import -alias alias -file root_certificate -keystore truststorefile.key, где alias – псевдоним (любое значение), root_certificate – полный путь к файлу сертификата, truststorefile.key – имя файла-хранилища.

В процессе импорта необходимо будет ввести парольную фразу для защиты хранилища и подтвердить доверие сертификату.

Файл-хранилище truststorefile.key необходимо скопировать в директорию SSL Gateway:
install_directoryVMwareVMware ViewServersslgatewayconftruststorefile.key

В директории SSL Gateway (install_directoryVMwareVMware ViewServersslgatewayconflocked.properties) необходимо создать файл c именем locked.properties и отредактировать его (например, в блокноте) до следующего содержимого:

 trustKeyfile= truststorefile.key
trustStoretype=JKS
useCertAuth=true 

Сохраните файл и перезагрузите службу View Connection Server.

Настройка входа по сертификату

Зайдите в веб-консоль VMware Horizon View.

Перейдите в свойства сервера: Inventory → View Configuration → Servers → Connections Servers → Edit.

Перейдите на вкладку Authentication и выберите предпочтительный режим аутентификации.

Аутентификация в административную консоль по смарт-карте настраивается из выпадающего списка Smart card authentication for administrators:

• Not Allowed – не использовать смарт-карту;
• Optional – смешанная аутентификация – или по паролю, или по смарт-карте;
• Required – обязательное использование смарт-карты.

Аутентификация пользователя в VDI по смарт-карте настраивается из выпадающего списка Smart card authentication for users:

• Not Allowed – не использовать смарт-карту;
• Optional – смешанная аутентификация – или по паролю или по смарт-карте;
• Required – обязательное использование смарт-карты.

Опция Disconnect user sessions on smart card removal определяет политику при отключении смарт-карты. Установите галочку, если необходимо производить отключение сессии при изъятии смарт-карты.

Нажмите кнопку ОК.

Настройка проброса смарт-карты пользователя

Проброс смарт-карты пользователя позволяет производить прозрачную аутентификацию в виртуальную машину с вводом PIN-кода один раз.

При использовании тонких клиентов Teradici настройка, как правило, не требуется.

При использовании программных клиентов Windows, MacOS, Linux необходимо выполнить установку VMware View Agent с активацией опции Smartcard Redirection.

Проверка

Для проверки выполним вход в консоль администрирования Horizon View и на виртуальный рабочий стол

Вход в консоль администрирования

Вставьте смарт-карту и перейдите в консоль администрирования.

В появившемся окне формы входа выберите сертификат администратора и нажмите кнопку OK.

Отобразится запрос на ввод PIN-кода. После успешной проверки PIN, будет произведена аутентификация в веб-интерфейс.

Вход на виртуальный рабочий стол

На клиентском устройстве запустите VMware Horizon Client и выберите необходимое подключение.

Отобразится запрос на ввод PIN-кода.

После успешной аутентификации отобразятся доступные ресурсы.

Ну и убедимся, что смарт-карта пробросилась на доставленный десктоп.

На этом всё.