Подробный гайд: Диагностика SSSD, если он не видит сертификаты на РуТокен ЭЦП 3.0 NFC - Часть 3
11. Проверка PAM-сервисов
У вас:
pam_p11_allowed_services = +cinnamon-screensaver, +mate-screensaver, +lightdm
Я бы написал без пробелов после запятых:
pam_p11_allowed_services = +cinnamon-screensaver,+mate-screensaver,+lightdm
Если вы входите через fly-dm, добавьте и его:
pam_p11_allowed_services = +cinnamon-screensaver,+mate-screensaver,+lightdm,+fly-dm
Если тестируете через консоль, добавьте, например:
pam_p11_allowed_services = +cinnamon-screensaver,+mate-screensaver,+lightdm,+fly-dm,+login,+sshd
Точное имя сервиса смотрите в каталоге:
ls /etc/pam.d/
Если сервиса нет в разрешённых, SSSD может не предлагать сертификатную аутентификацию именно для него.
12. Маппинг сертификата на пользователя AD
Если токен виден, сертификат виден, но вход не происходит, возможно, SSSD не понимает, какому пользователю соответствует сертификат.
У вас закомментировано:
#[certmap/test.blue.white.red/nt_principal]
#maprule = (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name}))
Если в сертификате есть SAN вида user@TEST.BLUE.WHITE.RED, то можно использовать маппинг через userPrincipalName.
Например:
[certmap/test.blue.white.red/nt_principal]
maprule = (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name}))
Но это нужно включать только если вы понимаете, что именно находится в сертификате.
Проверить SAN можно так:
openssl x509 -in /tmp/token-cert.pem -noout -text | grep -A2 'Subject Alternative Name'
Там должно быть что-то вроде:
X509v3 Subject Alternative Name:
othername: UPN::user@test.blue.white.red
или:
email: user@test.blue.white.red
Если SAN/UPN нет, нужен другой способ маппинга:
- по
subject; - по
issuer + serial; - по загруженному сертификату в атрибуте пользователя в AD;
- по
altSecurityIdentities, в зависимости от схемы.
Но это уже следующий этап, когда сертификат точно найден.
13. Итоговый рекомендуемый порядок диагностики
Шаг 1. Временно уберите p11_uri
[pam]
pam_cert_auth = True
p11_child_timeout = 240
pam_cert_db_path = /etc/ssl/certs/ca-certificates.crt
pam_p11_allowed_services = +cinnamon-screensaver,+mate-screensaver,+lightdm,+fly-dm
#p11_uri = PKCS11:model=Rutoken%20ECP%20NFC;serial=424a928f
debug_level=10
Перезапустите:
sssctl config-check
systemctl restart sssd
Если 3.0 заработал — причина была в фильтре.
Шаг 2. Узнайте реальный p11_uri для 3.0
p11tool --list-tokens
Используйте строку URL: из вывода.
Пример:
p11_uri = pkcs11:model=Rutoken%20ECP%203.0%20NFC
или:
p11_uri = pkcs11:serial=XXXXXXXX;model=Rutoken%20ECP%203.0%20NFC
Шаг 3. Проверьте видимость сертификата и ключа
MOD=/usr/lib/x86_64-linux-gnu/librtpkcs11ecp.so
pkcs11-tool --module "$MOD" --list-objects --type cert
pkcs11-tool --module "$MOD" --login --pin 'PIN' --list-objects --type cert
pkcs11-tool --module "$MOD" --login --pin 'PIN' --list-objects --type privkey
У сертификата и ключа должен совпадать ID.
Шаг 4. Проверьте алгоритм сертификата
pkcs11-tool --module "$MOD" --login --pin 'PIN' \
--read-object --type cert --id 01 --output-file /tmp/token-cert.der
openssl x509 -inform DER -in /tmp/token-cert.der -out /tmp/token-cert.pem
openssl x509 -in /tmp/token-cert.pem -noout -text
Если сертификат ГОСТ, проверьте вход с RSA/EC-сертификатом. Если с RSA/EC работает, а с ГОСТ нет — причина в поддержке ГОСТ в SSSD/OpenSSL/Kerberos/AD.
Шаг 5. Проверьте цепочку
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /tmp/token-cert.pem
Если не проходит — добавляйте CA.
Шаг 6. Смотрите логи
grep -R "p11_child\|certificate\|PKCS#11" /var/log/sssd/
Именно там будет окончательный ответ: токен не найден, сертификат не найден, цепочка не проверена, ключ недоступен и т.д.
14. Пример более аккуратного блока [pam]
Для диагностики можно использовать так:
[pam]
pam_cert_auth = True
p11_child_timeout = 240
pam_cert_db_path = /etc/ssl/certs/ca-certificates.crt
pam_p11_allowed_services = +cinnamon-screensaver,+mate-screensaver,+lightdm,+fly-dm
# На время диагностики убрать:
# p11_uri = PKCS11:model=Rutoken%20ECP%20NFC;serial=424a928f
# После диагностики можно указать точный токен, например:
# p11_uri = pkcs11:model=Rutoken%20ECP%203.0%20NFC
# или:
# p11_uri = pkcs11:serial=XXXXXXXX
debug_level = 10
15. Краткий вывод
С вероятностью около 80–90% у вас одна из двух причин:
Причина №1: некорректный p11_uri
Вы указали:
p11_uri = PKCS11:model=Rutoken%20ECP%20NFC;serial=424a928f
РуТокен ЭЦП 3.0 NFC может представляться иначе: другая модель, другой серийный номер, другой token label. SSSD просто не считает его целевым токеном.
Решение:
#p11_uri = ...
или корректный p11_uri, полученный из:
p11tool --list-tokens
Причина №2: на 3.0 записан ГОСТ-сертификат или недоступная пара сертификат/ключ
Если на 2.0 был RSA/EC-сертификат, а на 3.0 — ГОСТ, либо сертификат записан без приватного ключа, либо ключ недоступен пользователю, либо не совпадает CKA_ID, SSSD не сможет использовать такой сертификат.
Решение:
- проверить объекты через
pkcs11-tool; - убедиться, что сертификат и ключ доступны под пользовательским PIN;
- убедиться, что
IDсовпадают; - проверить алгоритм сертификата;
- для проверки использовать RSA/EC-сертификат.
Если после удаления p11_uri РуТокен ЭЦП 3.0 всё равно не появляется, самый быстрый способ понять причину — взять вывод:
p11tool --list-tokens
pkcs11-tool --module /usr/lib/x86_64-linux-gnu/librtpkcs11ecp.so --login --pin PIN --list-objects --type cert
pkcs11-tool --module /usr/lib/x86_64-linux-gnu/librtpkcs11ecp.so --login --pin PIN --list-objects --type privkey
openssl x509 -in /tmp/token-cert.pem -noout -text | egrep 'Signature Algorithm|Public Key Algorithm|Subject Alternative Name|Extended Key Usage'
grep -R "p11_child\|certificate" /var/log/sssd/
Эти данные почти всегда дают точный ответ, на каком этапе теряется сертификат.
Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.