Локальная авторизация с исользованием pam_p11_opensc работает. Но это не то, что нужно.

Получать тикеты kerberos с использованием рутокен тоже получается.

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

/etc/sssd/sssd.conf

[domain/int.vlant.ru]

id_provider = ipa
dns_discovery_domain = int.vlant.ru
ipa_server = _srv_, ipa-backup.int.vlant.ru
ipa_domain = int.vlant.ru
ipa_hostname = arashi.vlant.ru
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
krb5_store_password_if_offline = True
krb5_auth_timeout = 60

[sssd]
services = nss, pam, ssh, sudo

domains = int.vlant.ru
[nss]
homedir_substring = /home

[pam]
pam_cert_auth = True
pam_cert_db_path = /etc/ipa/ca.crt
p11_child_timeout = 60
pam_p11_allowed_services = +xdg-screensaver, +xscreensaver, +lightdm, +lightdm-greeter, +lightdm-autologin, +kde, +kscreensaver, +sddm, +sddm-greeter, +sddm-autologin
[sudo]

[autofs]

[ssh]

[pac]

[ifp]

[session_recording]

/etc/krb5.conf

#File modified by ipa-client-install

includedir /etc/krb5.conf.d/
[libdefaults]
  pkinit_identities = PKCS11:librtpkcs11ecp.so
  default_realm = INT.VLANT.RU
  dns_lookup_realm = true
  rdns = false
  dns_canonicalize_hostname = false
  dns_lookup_kdc = true
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}
  

[realms]
  INT.VLANT.RU = {
    pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
    pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
    pkinit_identities = PKCS11:librtpkcs11ecp.so
    pkinit_cert_match = <ISSUER>O=INT.VLANT.RU,CN=Certificate Authority
  }


[domain_realm]
  .int.vlant.ru = INT.VLANT.RU
  int.vlant.ru = INT.VLANT.RU
  arashi.vlant.ru = INT.VLANT.RU
  .vlant.ru = INT.VLANT.RU
  vlant.ru = INT.VLANT.RU

Требуется доказать третьей стороне, что ключевая пара была создана на устройстве Рутокен ЭЦП x.x.

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

Как вариант, Рутокеном для локально созданных ключевых пар генерируется ссылка на xxx.rutoken.ru, при переходе по которой отображается открытый ключ (решение отдаленно напоминает функцию некоторых NFC-меток).

Интересна ли эта идея для реализации?

Нашлась статья "Attacking RDP from Inside..." и ссылка на CVE-2022-24533 на один из вариантов простого использования уязвимости (Attack Complexity: Low, Privileges Required: Low). В статье так же есть видео с демонстрацией эксплуатации уязвимости "Video 3: Smart Card Redirection".

В отличие от RDP, при использовании SSH экспортируется не низкоуровневый, а прикладной интерфейс аутентификации в форме "SSH Agent", что выглядит намного безопаснее для сценария подключения к скомпрометированному серверу. Конечное обслуживание запросов производится на клиентской машине, которая предполагается доверенной, а не на удаленном сервере. В утилите "ssh-add" есть ключ "-с" для инициации интерактивного запроса на использование ключа (Indicates that added identities should be subject to confirmation before being used for authentication). А для Putty есть, как минимум, pagent из состава Putty CAC с опцией запроса использования ключа.

В связи с этим вопрос.

Есть ли сейчас варианты (или планируется ли) повышения дуракоустойчивасти использования Рутокена в сценарии подключения к скомпрометированному серверу (в первую очередь, к Windows)?

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

Одной из идей была возможность назначить разные PIN-коды на разные ключи (возможно, тема "Локальные PIN" относится к этому). Т.е. что бы утечка PIN-кода не раскрывала всех секретов.

Так же был продукт Рутокен Touch, требующий физического подтверждения операции. Но, как я понял, он снят с производства.

Хотелось бы услышать мнение специалистов на этот счет.

Пробуем использовать Рутокен ЭЦП 2.0 для 2-х факторной авторизации в домене AD.
По ходу столкнулись с тем, что на сервера, на которых мы хотим авторизоваться через RDP подключение, необходимо ставить весь пакет драйверов Рутокен, хотя в инструкции написано, что достаточно минидрайвера и  Рутокен поддерживает MS Base Smart Card CSP.

Без установленного пакета драйверов, на сервере не появляется устройство Smart Card.
В процессе установки пакета драйверов принудительно устанавливаются устройства Smart Card Reader и тогда уже становится видна сама смарткарта.

Подскажите, возможна ли работа Рутокен ЭЦП 2.0 с одним лишь минидрайвером на сервере, как этого добиться и что я делаю не так?

P.S. Используемые ОС: Win7 - 10, Server 2012 R2 - 2019.

Заголовок команды: 00 a4 04 00

Устройство чтения смарт-карт "Microsoft UICC ISO Reader 14bfefc6 0" отклонило IOCTL TRANSMIT: Параметр задан неверно.. Если ошибка повторяется, возможно, смарт-карта или устройство чтения смарт-карт работает неправильно.

Заголовок команды: 00 ca 7f 68
---cut here---

Где что может быть не донастроено!?

Дрова: 4.7.0.0
Спасибо

Уже перепробовал все варианты переустановок восстановлений и т.д., как заставить Win Serv 2016 отображать этого поставщика?

Дано: на MS Windows 2008r2 AD, развернут Центр сертификации,
в gpo включена политика входа по смарт-карте(рутокен), с машин windows 7 вход по токену проходит без проблем

Задача: 
Осуществить вход по токену в ОС Astralinux Orel 2.12

Вопрос:
Сталкивались вы с такой задачой?
у вас есть мануалы?
Как подружить Астру(она уже в домене) с УЦ MS 2008r2 ?