Вход в windows по сертификату без домена

Задача стоит следующая: организовать штатными средствами Windows вход в систему (ОС: Windows 7 или 8.1) (локальная аутентификация, без AD) по личному сертификату пользователя штатными средствами. В качестве носителя ключевой информации желательно использовать USB флеш диск.
В гугле нашел для смарт карт следующее:

Необходимые требования к сетевой инфраструктуре при внедрении смарт-карт
Перед тем как начать процесс внедрения смарт-карт, обратите внимание на необходимость наличия перечисленных ниже компонентов.
…
Служба каталогов Active Directory®.

Но это для смарт-карт. Возможно по сертификатам все же есть возможность работы без AD и без стороннего ПО?

p.s. Техподдержка Рутокена говорит, что при использовании рутокена в качестве носителя сертификата:

Средствами Windows можно сделать аутентификацию В ДОМЕНЕ! На локальной машине без дополнительного ПО это невозможно.

  Я потратил дня три, пробуя сделать эту авторизацию, после того как настроил авторизацию по смарт карте (rutoken), паролю AD и OTP (тройная проверка) на cisco ASA. Хотелось и вход в Windows (RDP) сделать по смарт карте, т.к. политиками можно настроить блокировку, отключение RDP сеанса или вообще выход из системы при отключении смарт карты.
  Но все попытки приводили к 2 ошибкам, которые можно увидеть в логах системы (с которой подключаешься):

ЦитироватьВ сертификате центра распространения ключей для контроллера домена отсутствует DNS-имя домена im-cloud.site в атрибуте «Дополнительное имя субъекта»: код ошибки 0xc000006d. Для устранения ошибки администратор домена должен получить сертификат центра распространения ключей с DNS-именем домена в атрибуте «Дополнительное имя субъекта». Используйте службы сертификатов Windows Server при создании шаблона проверки подлинности Kerberos.

и

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

Поиск по этим ошибкам в интернете не дал ничего. Один повторяющийся вопрос, причем и на русскоязычных, и на англоязычных, с ответом «У Вас что-то не то с сертификатом».

На сайте рутокена наткнулся на вот такой вариант:
https://dev.rutoken.ru/display/KB/RU1099?ysclid=lmiz9g54g5948645072

Но он не помог, клиентская машина с домашней версией Windows и там нет gpedit.msc (групповых политик)

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

Войдите в ЦС или рабочие станции управления с учетными данными, эквивалентными администратору домена .

1. Откройте центр сертификации консоль управления
2. Щелкните правой кнопкой мыши управление шаблонами сертификатов >
3. В консоли шаблона сертификата щелкните правой кнопкой мыши шаблон Проверки подлинности Kerberos в области сведений и выберите дублировать шаблон.
4. На вкладке Совместимость :

• Снимите флажок Показать последующие
• Выберите Windows Server 2016 в списке Центров сертификации
• Выберите Windows 10 или Windows Server 2016 в списке получателей сертификата.

5. На вкладке Общие

• Пишем «Проверка подлинности контроллера домена (Kerberos)» в отображаемом имени шаблона (или любое понятное Вам имя)
• Настройка срока действия и периода продления в соответствии с потребностями предприятия

6.На вкладке Имя субъекта выполните следующие действия.

• Нажмите кнопку (переключатель) Строится на основании данных Active Directory , если она еще не выбрана.
• Выберите Отсутствует в списке Формат имени субъекта .
• Выберите DNS-имя из списка Включить эту информацию в альтернативное имя субъекта .
• Очистка всех остальных элементов

7. На вкладке Шифрование выполните следующие действия.

• Выберите поставщик хранилища ключей в списке Категория поставщика
• Выберите RSA в списке Имя алгоритма. (подставилось само)
• Введите 2048 в текстовом поле Минимальный размер ключа. (тоже было)
• Выберите SHA256 в списке хэша запроса. (а вот это надо менять, там sha1 по умолчанию)

Предварительный этап выполнен. Но надо указать, какие сертификаты заменяет наш новый шаблон. Для этого, на вкладке «Устаревшие шаблоны» нажмите Добавить.

• В диалоговом окне Добавление устаревшего шаблона выберите шаблон сертификата контроллера домена и нажмите кнопку ОК > Добавить.
• В диалоговом окне Добавление устаревшего шаблона выберите шаблон сертификата проверки подлинности контроллера домена и нажмите кнопку ОК > Добавить.
• В диалоговом окне Добавление устаревшего шаблона выберите шаблон сертификата проверки подлинности Kerberos и нажмите кнопку ОК > Добавить.
• Нажмите кнопку ОК и закройте консоль шаблоны сертификатов

Добавляем сертификат в консоли Центра Сертификации:

• ПКМ на «Шаблоны сертификатов»
• Создать > Выдаваемый шаблон сертификата
• В открывшемся окне выбираем созданный нами шаблон «Проверка подлинности контроллера домена (Kerberos)» созданный нами выше.

Заходим на контроллер домена, mmc, оснастка «сертификаты > учетная запись компьютера > Личное, ПКМ на Сертификаты > Все задачи > Запросить новый сертификат»

Выбираем наш созданный сертификат, он создается…

И тут я «пошел» пробовать вход по Rutoken, а он продолжал выдавать мне те же ошибки.. Еще день я потратил, думая что же не так, пересоздал дважды сертификат Центра сертификации.. хотел уже создать сертификат пользователя не через политику AD.. Потом до мня дошло:
Надо удалить все старые сертификаты контроллера домена!!! кроме сертификата «Компьютер» (а он здесь причем) (у меня 2 DC я сделал на обеих). Перезагрузил их..

И, уже не веря в удачу, попробовал залогинится по сертификату. И какой же был кайф, когда вместо «попытка входа в систему неудачна» мне выдало предупреждение о сертификате RDP!

Спасибо за внимание, надеюсь моя инструкция кому-нибудь пригодится)

Проблема аутентификации доступа к информационным ресурсам является на сегодня весьма актуальной. Защиты с помощью пароля нередко оказывается недостаточно, ее требуется усиливать. Операционная система Microsoft Win-dows 2000 позволяет усовершенствовать процесс аутентификации пользователей с помощью смарт-карт, но при этом требуется наличие устройства чтения — ридера. Есть и другие варианты, и один из них предполагает использование электронных USB-ключей eToken компании «Аладдин», которые являются полнофункциональным аналогом одновременнно смарт-карт и устройств чтения/записи для работы со смарт-картами.

Смарт-карта или eToken

Термин «смарт-карта» используется для обозначения устройств размером с кредитную карточку, обладающих различными возможностями: карты для хранения данных, бесконтактные карты и карты на основе интегральных микросхем (integrated circuit cards, ICC). Все они отличаются друг от друга, а также от традиционных карт с магнитной полосой, обычно используемых для обслуживания банковского счета.

На персональном компьютере и в среде Windows 2000 используются карты на основе интегральных микросхем, так как они могут выполнять сложные криптографические операции. Смарт-карта — это, по существу, миниатюрный компьютер с ограниченной памятью и возможностью обработки данных, заключенный в форму пластиковой кредитной карточки. Обмен данными между смарт-картой и приложением, работающим на компьютере, осуществляется через полудуплексный последовательный интерфейс, управляемый приемным устройством с помощью соответствующего драйвера. Устройства для чтения смарт-карт достаточно разнообразны и могут подсоединяться к компьютеру с помощью интерфейса RS-232, PCMCIA или USB.

eToken — это первый полнофункциональный аналог смарт-карты, выполненный в виде брелка. Он напрямую подключается к компьютеру через порт Universal Serial Bus (USB) и не требует наличия дорогостоящих устройств считывания или других дополнительных устройств. Более подробная информация о моделях eToken приведена во врезках «Познакомимся поближе» и «Преимущества eToken перед смарт-картами».

Смарт-карты являются важнейшим компонентом инфраструктуры открытых ключей (PKI), интегрированной Microsoft в Windows 2000. Смарт-карты расширяют возможности программной аутентификации. Аналогичными функциями обладает и eToken, который обеспечивает:

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

eToken может использоваться для аутентификации пользователя в домене Windows 2000 в трех случаях:

• интерактивный вход в систему (interactive logon), при котором задействуются каталог Active Directory, протокол Kerberos версии 5 и сертификат открытого ключа;
• удаленный вход в систему (remote logon), использующий сертификат открытого ключа, протокол Extensible Authentication Protocol — Transport Layer Security (EAP-TLS) для идентификации удаленного пользователя, учетная запись которого хранится в каталоге Active Directory;
• аутентификация клиента (client authentication) — процесс взаимной идентификации пользователя и домена с помощью сертификата открытого ключа, сопоставленного с хранящейся в каталоге Active Directory учетной записью.

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

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

Интерактивный вход в систему

При подключении eToken к USB-порту Windows 2000 «понимает», что теперь, вместо имени пользователя, имени домена и пароля, необходимо запросить персональный идентификационный номер (Personal Identification Number, PIN), см. Экран 1. Это событие эквивалентно нажатию сочетания клавиш Ctrl-Alt-Del, инициирующему процедуру входа в систему с использованием пароля. Однако PIN, который указывается в диалоговом окне при входе в систему, обеспечивает аутентификацию только по отношению к eToken, но не к домену.

Сертификат открытого ключа, хранящийся в защищенной памяти eToken, используется для аутентификации в домене с применением протокола Kerberos версии 5 и его расширения PKINIT.

Запрос на вход в систему

После того как пользователь вводит в окне регистрации PIN, операционная система определяет, может ли пользователь быть идентифицирован и аутентифицирован на основе предъявленной им удостоверяющей информации (PIN и eToken). При запросе на вход в систему сначала происходит обращение к локальной системе безопасности (LSA), которая передает запрос пакету аутентификации Kerbe-ros, запущенному на клиентском компьютере. Пакет Kerberos посылает запрос службе аутентификации Key Distribution Center (KDC), функционирующей на контроллере домена, для аутентификации и получения билета TGT (билет начального уровня — Ticket Granting Ticket). В состав запроса к службе аутентификации (Authentication Service, AS), в те его поля, которые предшествуют идентификационным, помещается сертификат пользователя, обнаруженный в памяти eToken. Удостоверение, включенное в эти поля, заверяется цифровой подписью с использованием личного ключа пользователя так, чтобы KDC могла проверить запрос, отправленный владельцем сертификата.

Проверка сертификата

Перед тем как удовлетворить запрос, служба AS, прежде всего, должна проверить происхождение сертификата и убедиться в том, что он заслуживает доверия. KDC использует CryptoAPI, чтобы проследить путь от пользовательского сертификата к сертификату корневого центра сертификации (CA). Если KDC по тем или иным причинам (например, корневой сертификат недействителен, невозможно найти родительские сертификаты или определить, не аннулирован ли сертификат) окажется не в состоянии построить допустимую цепочку сертификатов, то она вернет сообщение об ошибке и откажет в удовлетворении запроса.

KDC также должна проверить, уполномочен ли центр сертификации, выдавший сертификат, выдавать сертификаты для аутентификации в домене. В Windows 2000 для аутентификации с помощью eToken источником сертификатов должен быть корпоративный центр сертификации, который опубликован в Active Directory. Это требуется для предотвращения выдачи сертификатов в пространстве имен другого домена ложными центрами сертификации, действительными только в одной из иерархий. Хотя предпринять подобного рода атаку исключительно сложно, так как это зависит от получения ложным центром сертификации прав на издание от законного родительского центра сертификации, решение запрашивать корпоративный CA, опубликованный в Active Directory, было принято во избежание самой возможности вторжения.

Проверка цифровой подписи

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

Поиск учетной записи и билет TGT

Убедившись, что пользователь является тем, за кого себя выдает, и что сертификат может быть использован для аутентификации в домене, служба KDC запрашивает в каталоге домена учетную запись. KDC ищет учетную запись пользователя в Active Directory по основному имени пользователя (User Principal Name, UPN), которое указано в поле альтернативного имени (Subject Alternative Name) в пользовательском сертификате открытого ключа. Учетная запись, которую KDC получает от службы каталога, используется для формирования билета TGT. Билет TGT будет включать идентификатор безопасности пользователя (Security ID, SID), SID всех групп, членом которых пользователь является. Список SID внесен в поля данных авторизации TGT.

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

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

Автономная регистрация в системе (Offline Logon)

Когда пользователь отсоединен от сети или контроллер домена недоступен, пользователь должен сохранить возможность зарегистрироваться на своем компьютере автономно. Такая возможность обеспечивается с помощью паролей путем сравнения хешированного пароля, сохраняемого локальной системой безопасности, с хешем удостоверения, которое пользователь предъявляет Graphical Identification and Authentication (GINA) в процессе автономной регистрации в системе. Если сравниваемые данные совпадают, пользователь получает доступ к локальной машине.

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

Аутентификация клиента

Поскольку поддержка eToken интегрирована в CryptoAPI, протоколам Secure Sockets Layer (SSL) и Transport Layer Security (TLS) не нужно «знать» что-либо об eToken для того, чтобы работать с ним. Роль eToken в процессе аутентификации клиента состоит в том, чтобы подписать часть данных протокола на начальной стадии сеанса обмена данными по протоколу SSL. Поскольку закрытый ключ, соответствующий сертификату открытого ключа, хранится в памяти eToken, подобный метод аутентификации является более строгим, так как применение закрытого ключа требует от владельца eToken подтверждения прав доступа и к eToken, и к домену. Кроме того, операции с закрытым ключом, выполняемые на начальной стадии сеанса обмена данными, реализуются eToken таким образом, что закрытый ключ никогда не передается компьютеру или в локальную сеть.

Взаимная аутентификация

Оба протокола, SSL 3.0 и TLS 1.0, поддерживают взаимную аутентификацию, что для клиента означает возможность проверить подлинность сервера, а для сервера — подлинность клиента.

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

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

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

Авторизация

При аутентификации клиента в Win-dows 2000 с применением открытых ключей используются данные из сертификата клиента для получения информации о его правах доступа в домене.

Когда установлен сеанс SSL или TLS, провайдер безопасного канала (secure channel provider) прежде всего пытается, исходя из UPN сертификата, найти учетную запись пользователя в каталоге домена. UPN включено в сертификат в поле альтернативного имени субъекта (Alternative Subject Name), оно определяет точное имя учетной записи пользователя (префикс) и имя домена, в котором расположена учетная запись (суффикс). Так же как при входе в систему с помощью eToken на основе Kerberos, источник сертификатов должен иметь полномочия на выпуск сертификатов для домена, чтобы им можно было доверять при идентификации и проверке полномочий.

Если нет соответствия UPN или СА не уполномочен издавать сертификаты для аутентификации в домене, провайдер пытается запросить в каталоге поиск учетной записи, у которой атрибут Alternate Security Iden-tities содержит явное указание на соответствие сертификату клиента. Явное указание сертификата в учетной записи пользователя требует дополнительных действий со стороны ад министратора. Соответствие сертификату клиента может быть основано либо на имени источника, либо на источнике и субъекте в сертификате. Учетная запись может иметь один или более связанных с ней сертификатов, что упрощает применение одной учетной записи несколькими пользователями. Сертификат не может соответствовать нескольким учетным записям, хранящимся в каталоге домена. Аутентификация не будет выполнена, если сертификат соответствует более чем одной учетной записи.

Удаленный доступ

Поддержка расширяемой аутентификации для удаленных пользователей в Windows 2000 обеспечивается службой удаленного доступа RAS. Сервер удаленного доступа поддерживает протокол аутентификации EAP и обеспечивает модулям различных производителей возможность поддержки разнообразных методов аутентификации (см. Экран 2).

Windows 2000 содержит встроенный модуль для поддержки eToken, что позволяет обеспечить строгую аутентификацию удаленных пользователей. Замечу, что удаленный доступ к системе фактически означает две аутентификации: на сервере RAS и в сети.

Первая аутентификация завершается подтверждением аутентификации сер-вера RAS клиентом и установлением соединения между клиентом и сервером. В результате клиенту сопоставляются некоторые политики RAS и атрибуты учетной записи. Атрибуты учетной записи применяются индивидуально и включают такие свойства, как права доступа, режимы обратного вызова (callback options), статические маршруты (static routes) и т. д. Политики RAS определяют основные принципы взаимодействия сервера с клиентом. Это позволяет управлять пользователями, обеспечивая соответствие свойств подключения, группового членства, профиля и т. д.

Вторая аутентификация относится к домену и использует TLS в качестве протокола аутентификации вместо Kerberos. Аутентификация в домене с использованием EAP-TLS очень похожа на аутентификацию по протоколу SSL, за исключением того, что сертификат открытого ключа должен содержать UPN, соответствующее учетной записи, хранящейся в доменном каталоге Active Directory.

Политики безопасности

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

Обязательное использование eToken. Windows 2000 поддерживает на уровне отдельного пользователя политику учетных записей, требующую обязательного использования eToken для интерактивной регистрации в системе (см. Экран 3).

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

Режим обязательного использования eToken, обусловленный политикой учетной записи при интерактивной регистрации, должен быть установлен для пользователей, являющихся членами группы Users и применяющих eToken для регистрации в домене Windows 2000.

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

Политика извлечения смарт-карты (или eToken) — это локальная политика, действие которой распространяется на компьютер, а не на учетную запись пользователя.

Решение об установке политики отсоединения eToken зависит от потребностей корпорации и от того, как пользователи работают с компьютерами. В тех ситуациях, когда работа ведется в помещениях, куда могут зайти посторонние, использование такой политики настоятельно рекомендуется (см. Экран 4). Если же у каждого пользователя есть отдельный компьютер, возможно, нет необходимости устанавливать вышеописанную политику, и можно ограничиться применением хранителей экрана и тому подобных мер.

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

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

Можно выдать временный eToken с сертификатом короткого срока действия, например на один день.

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

Персональные идентификационные номера

В то время как пароли обладают очевидными недостатками, в частности создаются пользователями на основе легко запоминаемых ассоциаций, PIN-коды eToken не подчиняются тем же правилам, что и «надежные пароли» (strong passwords), поскольку eToken не подвержены классическим атакам путем подбора слов.

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

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

Благодаря способности eToken противостоять вышеописанным типам атак, часто менять PIN-код не требуется.

Станция регистрации eToken

Станция регистрации смарт-карт (то же относится и к eToken) работает как часть корпоративной службы центра сертификации в Windows 2000 Server и Windows 2000 Advanced Server. Она поддерживает централизованную выдачу eToken. Станция регистрации смарт-карт использует шаблоны сертификатов для определения того, какую информацию включать в тот или иной сертификат.

Для eToken существует два шаблона:

• eToken для регистрации (не может использоваться для защиты электронной почты);
• eToken пользователя.

Чтобы выдавать сертификаты для eToken, на предприятии должна существовать станция регистрации смарт-карт (eToken). Это требование обязательно, поскольку по умолчанию пользователи домена не могут регистрировать сертификаты eToken, выданные корпоративным ЦС Windows 2000.

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

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

Кроме того, желательно отключить выдачу сертификата этого типа в центре сертификации, за исключением особых случаев или когда необходимо автономное (offline) применение CA. По умолчанию, разрешения на доступ к сертификатам регистраторов установлены только для администраторов доменов.

Внедрение eToken

Использование в организации eToken позволяет существенно повысить безопасность сети за счет совершенствования методов аутентификации. К тому же пользователям больше не придется запоминать множество учетных записей (login) и паролей к различным ресурсам сети и приложениям. Нужно запомнить одно-единственное число — PIN-код к своему ключу eToken.

Максим Подлесный — руководитель отдела разработок компании Aladdin Software Security R.D. C ним можно связаться по адресу: it@aladdin.ru.

Познакомимся поближе

eToken имеет до 64 Кбайт защищенной энергонезависимой памяти (EEPROM) и может использоваться как портативный контейнер для хранения секретных данных (ключей шифрования, кодов доступа, сертификатов). eToken имеет уникальный серийный номер (ID) и может использоваться как электронный идентификатор (ключ) для аутентификации пользователя. eToken поддерживает работу и интегрируется со всеми основными системами и приложениями, использующими технологию Public Key Infrastructure (PKI).

eToken R2

eToken R2 имеет аппаратно реализованный алгоритм шифрования DESX со 120-разрядным ключом.

eToken Pro

eToken Pro, в отличие от R2, имеет дополнительный чип смарт-карты, аппаратно реализующий алгоритм шифрования RSA/1024, 3DES (TripleDES), SHA-1 и генератор личных (Private) ключей, никогда не покидающих микросхему.

В eToken Pro используется микросхема SLE66C Infineon, обеспечивающая исключительно высокий уровень безопасности, сертифицированный по ITSEC LE4.

В eToken Pro используется файловая система Siemens CardOS/M4, поддерживающая неограниченную иерархию объектов и файлов.

eToken RIC

В eToken RIC аппаратно реализованы криптографические алгоритмы шифрования ГОСТ 28147-89 (имеет сертификат соответствия ФАПСИ), включая диверсификацию и формирование сессионного ключа, а также DES и Triple DES.

назад

Преимущества eToken перед смарт-картами

Помимо функций смарт-карт eToken обладает дополнительными возможностями:

• не требует дорогостоящего устройства считывания и лишних проводов. Большинство устройств чтения смарт-карт подключается к компьютеру через последовательный порт RS-232, разъем PCMCIA Type II или шину USB. eToken напрямую подключается к компьютеру через USB-порт и не требует наличия дорогостоящих устройств считывания или других дополнительных устройств;
• имеет больше памяти (до 32 Кбайт) и может хранить несколько сертификатов (семь и более). Криптографические смарт-карты имеют ограниченный объем памяти, обычно от 2 до 16 Кбайт. Поскольку память пользуется большим спросом и довольно дорого стоит, производители карт ограничивают объем памяти, доступный одному приложению;
• различные приложения могут использовать один и тот же eToken. eToken поддерживает стандарт PC/SC и эмулирует смарт-карту и устройство считывания, что позволяет легко встраивать его как в существующие приложения, так и в новые. При работе с разными приложениями может использоваться уже имеющийся eToken. Необходимости в покупке дополнительных ключей нет. Потребуется лишь доплатить за лицензию на использование нужной программы;
• возможна одновременная работа с несколькими брелками eToken.

назад

Общая информация

Настоящая инструкция описывает настройку входа в домен по предъявлении токена в операционных системах Windows Server 2022 Rus и Windows Server 2025 Rus. 

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

Программные требования

• ОС Windows Server 2022 Rus или Windows Server 2025 Rus;
• учетная запись с правами администратора системы;
• установленные драйверы Рутокен;
• дистрибутив ОС.

Предварительная настройка

Перед тем, как приступать к работе, убедитесь, что:

• операционная система настроена как Контроллер домена;
• установлены Службы сертификации;
• пользователям выданы сертификаты типа Пользователь со смарт-картой или Вход со смарт-картой.

Если все условия выполнены, можно переходить к настройке входа в домен.

Настройка учетной записи 

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

В этом примере будет настроена учетная запись User — пользователь домена, который  только в группу Пользователи домена.

Для настройки учетной записи пользователя:

1. Откройте меню Пуск.
2. В поисковой строке введите «пользователи и компьютеры» и откройте найденную оснастку Пользователи и компьютеры Active Directory.
3. В левой части окна оснастки выберите  Users.
4. Нажмите правой кнопкой мыши на имя пользователя, которому будет разрешено входить в домен только при наличии устройства Рутокен, и выберите пункт Свойства.
   
   

   Картинка с сайта: dev.rutoken.ru

5. В окне свойств пользователя перейдите на вкладку Учетная запись.
6. В секции Параметры учетной записи установите флажок Для интерактивного входа в сеть нужна смарт-карта. Нажмите ОК.
   
   

   Картинка с сайта: dev.rutoken.ru

Настройка политик безопасности домена

Для настройки политик безопасности:

1. Откройте меню Пуск.
2. В поисковой строке введите «управление групповой политикой» и откройте найденную оснастку
3. В окне Управление групповой политикой нажмите на категорию Объекты групповой политики

4. Нажмите правой кнопкой мыши на объект Default Domain Policy и выберите пункт Изменить…
   

   

   Картинка с сайта: dev.rutoken.ru

   
   

5. В левой части окна Редактор управления групповыми политиками раскройте  
7. В правой части окна нажмите дважды левой кнопкой мыши Интерактивный вход в систему: требовать Windows Hello для бизнеса или смарт- карту.
   
   

   Картинка с сайта: dev.rutoken.ru

8. и установите переключатель в положении Включен.
   
   

   Картинка с сайта: dev.rutoken.ru

9. Нажмите ОК, чтобы сохранить настройку и закрыть окно свойств.
10. В правой части окна нажмите правой кнопкой мыши на политику Интерактивный вход в систему: поведение при извлечении смарт-карты и выберите пункт Свойства.
    
    

    Картинка с сайта: dev.rutoken.ru

11. Установите флажок Определить следующий параметр политики.
12. Из раскрывающегося списка выберите поведение клиентской ОС при отсоединении устройства Рутокен в процессе открытого пользовательского сеанса. В данном примере выбрано поведение ОС — Блокировка рабочей станции.
    
    

    Картинка с сайта: dev.rutoken.ru

13. Нажмите ОК, чтобы сохранить настройку и закрыть окно свойств.
14. Закройте окно Редактор управления групповыми политиками.
15. Перезагрузите компьютер.

Настройка клиентской операционной системы

Компьютеры с установленными клиентскими операционными системами Windows 11/10/8.1/8/7/Vista/XP/2000 необходимо ввести в домен и установить на них драйверы Рутокен. Редакции ОС должны включать возможность присоединения к домену.

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

При извлечении устройства Рутокен в процессе открытого пользовательского сеанса клиентская ОС будет автоматически заблокирована (в ОС Windows 11/10/8.1/8/7/Vista для блокировки рабочего стола при отключении устройства Рутокен необходимо установить автоматический запуск службы Политика удаления смарт-карт/Smart Card Removal Policy).

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.