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

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

На компьютере, который используется для подготовки ключевых носителей, и на компьютерах, на которых ключевые носители будут использоваться (клиентские компьютеры), независимо от типа используемого домена должны быть установлены:

1. Интерфейсные пакеты производителей используемых токенов (подробнее см. статью Ключевые носители (токены) PKCS в Astra Linux ).
2. Пакеты из репозиториев Astra Linux:
   • Только на компьютере для подготовки токенов:
     • opensc.
   • Только на клиентских компьютерах:
     • csp-monitor;
     • libnss3-tools;
     • krb5-pkinit — только на клиентских компьютерах, где требуется получение билетов Kerberos по сертификату. 

Подготовка токенов

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

Пример сохранения значений в переменных окружения:

• для токенов Аладдин:

  so_pin="00000000"
  pin="1234567890"
  module="/usr/lib/libjcPKCS11-2.so"

• для токенов Рутокен:

  so_pin="87654321"
  pin="12345678"
  module="/usr/lib/librtpkcs11ecp.so"

1. Подготовка токена:
   1. Подключить токен.

   2. Инициализировать токен.

      pkcs11-tool --module "$module" --init-token --so-pin "$so_pin" --label 'AstraLinux'

   3. Создать на токене раздел пользовательских данных:

      pkcs11-tool --module "$module" --init-pin --so-pin "$so_pin" --pin "$pin"

2. Создание пользовательского сертификата:

   1. Создать на токене ключевую пару:

      pkcs11-tool --module "$module" --pin "$pin" --keypairgen --key-type rsa:2048 --id 33 --label '2fa_test1_key'

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

      openssl << EOT
      engine dynamic -pre SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:$module
      req -engine pkcs11 -new -keyform engine -out client.req -subj "/C=RU/ST=Moscow/L=Moscow/O=<Kerberos_realm>/OU=dev/CN=$user/emailAddress=$user@<имя_домена>" -passin pass:$pin -key "<закрытый_ключ>"
      EOT
      Где закрытый ключ может быть задан:

      • С использованием URL:

        "pkcs11:serial=<серийный_номер_токена>;id=%33"

      • С использованием номера записи:
        

        "131071:33"

   3. Получить билет Kerberos администратора домена, если он не был получен ранее.

   4. При использовании удостоверяющего центра (УЦ) DogTag отправить запрос на получение сертификата:

      ipa cert-request client.req --add --principal=$user@$realm --certificate-out=$user.pem
      Выпущенный сертификат будет сохранен в файле $user.pem (где вместо $user будет подставлено сохраненное в переменной окружения имя пользователя). Сертификат пользователя также будет автоматически сохранен в записи этого пользователя в службе каталогов домена.

   5. Конвертировать сертификат в формат DER:

      openssl x509 -in $user.pem -out $user.cer -inform PEM -outform DER

   6. Записать сертификат на токен:

      pkcs11-tool --module $module --pin "$pin" -a "2fa_test_user_cert" -y cert -w $user.cer --id 33

Настройка клиентского компьютера

Настройка службы pcscd

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

1. Выполнить команду:

   sudo systemctl edit pcscd.service

2. Ввести текст:

   [Service]
   ExecStart=
   ExecStart=/usr/sbin/pcscd --foreground

3. Сохранить изменения.

4. Перезапустить службу pcscd.service:

   sudo systemctl restart pcscd.service

Настройка службы sssd на работу с сертификатами

Далее предполагается, что:

• компьютер введен в домен с использованием sssd;
• установлены все необходимые пакеты;
• получены файлы с сертификатами УЦ домена. Для их получения обратиться к администратору домена.

Порядок настройки:

1. В конфигурационном файле /etc/sssd/sssd.conf службы sssd:

   1. В секции параметров домена изменить значение параметра krb5_ccname_template (добавить параметр если его нет):

      krb5_ccname_template = KEYRING:persistent:%{uid}

      Значение параметра default_ccache_name в файле /etc/krb5.conf следует установить такое же.

   2. В секцию [pam] добавить:

      1. Параметр pam_cert_auth = True, включающий аутентификацию по сертификатам.

      2. Параметр responder_idle_timeout = 0, помогающий избежать двойного ввода PIN-кода после блокировки АРМ по истечении времени.
         Команда для добавления параметров:

         sudo sed -i -e "/\[pam\]/a pam_cert_auth = True\nresponder_idle_timeout = 0" /etc/sssd/sssd.conf

      3. (Опционально) Включить отладочный режим, указав необходимые уровни в значениях параметров  debug_level и pam_verbosity :

         debug_level = 0x7660
         pam_verbosity = 3

         Подробнее про уровни отладки см.:
         

         man sssd.conf

   3. Добавить секцию [certmap/<имя_домена>/rule] с правилами отображения сертификатов, например:

      [certmap/<имя_домена>/rule]
      matchrule = <ISSUER>CN=<имя_УЦ>
      maprule = (userCertificate;binary={cert!bin})

      где:

      1. Вместо <имя_домена> — подставить имя домена.

      2. Текст matchrule = <ISSUER>CN= — оставить без изменений;

      3. Вместо <имя_УЦ> — подставить CN (Common Name) удостоверяющего центра сертификата. CN можно получить:

         1. Из сертификата клиента, например, из сертификата на ключевом носителе:

            pkcs11-tool --module <модуль> -r --type cert --id <идентификатор_сертификата> | openssl x509 -noout -text -inform der  -in - | grep Issuer:
            

            ---

            Using slot 0 with a present token (0x1ffff)
                    Issuer: DC = ru, DC = windom2016, CN = windom2016-WIN2016-CA

         2. Из сертификата УЦ, которым был подписан сертификат клиента:

            openssl x509 -noout -text -in <имя_фала> | grep Subject:
            

            ---

                    Subject: DC = ru, DC = windom2016, CN = windom2016-WIN2016-CA

         3. Текст  maprule = (userCertificate;binary={cert!bin}) — оставить без изменений. Например, для домена windom2016.ru и УЦ windom2016-WIN2016-CA:
            

            [certmap/windom2016.ru/rule]
            matchrule = <ISSUER>CN=windom2016-WIN2016-CA
            maprule = (userCertificate;binary={cert!bin})

   4. Создать каталог /etc/sssd/pki/:

      sudo mkdir /etc/sssd/pki/

   5. В файле /etc/sssd/pki/sssd_auth_ca_db.pem разместить сертификат (цепочку сертификатов) УЦ. Сертификаты должны быть представлены в формате PEM. Для размещения цепочки сертификатов сертификаты записываются в файл последовательно, и в соответствии со стандартом очередность записи сертификатов значения не имеет. При этом:
      • при работе в домене FreeIPA сертификат УЦ FreeIPA доступен на контроллере домене в файле /etc/ipa/ca.crt;
      • при работе в домене Windows AD сертификат УЦ можно получить у администратора домена или загрузить по ссылке, представленной в пользовательском сертификате (и, далее, загрузить цепочку сертификатов используя ссылку в предыдущем загруженном сертификате УЦ). 
        
        
2. Зарегистрировать интерфейсные модули производителей для использования службой sssd как модули p11-kit:

   1. Создать каталог /etc/pkcs11/modules:

      sudo mkdir -p /etc/pkcs11/modules

   2. Зарегистрировать интерфейсные модули токенов, создав файлы с описаниями.
      

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

      • /etc/pkcs11/modules/
      • /usr/share/p11-kit/modules/

      Для ускорения работы можно удалить описания неиспользуемых модулей.

      Например, создать файлы с описаниями:

      • для модулей Аладдин (интерфейсная библиотека /usr/lib/libjcPKCS11-2.so):
        

        echo -e "module: /usr/lib/libjcPKCS11-2.so" | sudo tee /etc/pkcs11/modules/a-aladdin.module

      • для модулей Рутокен (интерфейсная библиотека /usr/lib/librtpkcs11ecp.so):

        echo -e "module: /usr/lib/librtpkcs11ecp.so" | sudo tee /etc/pkcs11/modules/a-rutoken.module
        Важно: имена файлов с описанием модулей должны начинаться с буквы "a", что обеспечит их приоритетное применение.

   3. Проверить состав зарегистрированных модулей:

      p11-kit list-modules
      При правильной настройке в выведенном списке модулей будут присутствовать добавленные модули, например:
       Развернуть исходный код

      ...
      a-rutoken: /usr/lib/librtpkcs11ecp.so
          library-description: Rutoken ECP PKCS #11 library
          library-manufacturer: Aktiv Co.
          library-version: 2.11
          token: Rutoken ECP
              manufacturer: Aktiv Co.
              model: Rutoken ECP
              serial-number: 413a49ed
              hardware-version: 60.1
              firmware-version: 30.2
              flags:
                     rng
                     login-required
                     user-pin-initialized
                     token-initialized
                     user-pin-count-low
                     user-pin-to-be-changed
                     so-pin-to-be-changed
      ...

3. Для того, чтобы служба sssd использовала для аутентификации ключевые носители, в ОС должен присутствовать файл /var/lib/sss/pubconf/pam_preauth_available. В актуальных обновлениях Astra Linux это файл создается автоматически. Если используется Astra Linux без актуальных обновлений, то для функционирования 2ФА может понадобиться создавать этот файл, для чего можно использовать любые удобные инструменты.

Настройка PAM-стека

1. Начиная с оперативного обновления БЮЛЛЕТЕНЬ № 2024-0830SE17 (оперативное обновление 1.7.6) для для настройки PAM-стека следует использовать предопределенные профили, включенные в пакеты astra-freeipa-server, astra-freeipa-client, astra-ad-sssd-client. Перечень профилей:
   • astra-sss-2fa — возможность входа как по паролю (при отключенном ключевом носителе), так и по PIN-коду (при подключенном ключевом носителе);
   • astra-sss-2fa-try — вход только по PIN-коду при подключенном ключевом носителе;
   • astra-sss-2fa-require — вход только по PIN-коду с запросом подключения ключевого носителя, если он не подключен.

   Информация о 2ФА-профилях доступна в справочных страницах  man  пакетов, использующих профили:

   man astra-ad-sssd-client
man astra-freeipa-server
man astra-freeipa-client

   Для выбора нужного профиля:

   1. Удалить все установленные ранее профили авторизации:

      sudo pam-auth-update --remove astra-sss-2fa astra-sss-2fa-try astra-sss-2fa-require sss sss-smart-card-optional sss-smart-card-required

   2. Установить нужный PAM-профиль 2ФА:
      

      sudo pam-auth-update --enable <имя_профиля>

      Предупреждение о несовместимости при установке игнорировать. Чтобы игнорировать предупреждение автоматически при выполнении сценариев необходимо внести в сценарий строку:
      

      sudo DEBIAN_FRONTEND=noninteractive pam-auth-update --enable <имя_профиля>

2. В более ранних обновлениях настройка выполняется вручную:

   Нажмите здесь для раскрытия...

   В файле /etc/pam.d/common-auth строки:

   auth   [success=2 default=ignore]      pam_unix.so nullok_secure try_first_pass
   auth   [success=1 default=ignore]      pam_sss.so use_first_pass

   заменить на :

   auth	[success=1 default=ignore]		pam_localuser.so
   auth    [success=2 default=ignore]      pam_sss.so forward_pass <опция>
   auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass

   где <опция> может иметь следующие значения:

   1. не указано — при отключенном ключевом носителе запрашивается пароль, при подключенном ключевом носителе запрашивается PIN-код для 2ФА;
   2. try_cert_auth — при подключенном ключевом носителе запрашивается PIN-код для 2ФА, при отсутствии ключевого носителя отказ аутентификации;
   3. require_cert_auth — при подключенном ключевом носителе запрашивается PIN-код для 2ФА, при отсутствии ключевого носителя запрашивается подключение носителя;

3. Перезапустить службу sssd:

   sudo systemctl restart sssd

Подключение по SSH с аутентификацией по сертификату

1. Проверка доступности сертификатов для аутентификации SSH:

   sss_ssh_autorizedkeys <имя_пользователя>
   При этом должен выводиться SSH-сертификат указанного пользователя. Пустой вывод обозначает, что сертификаты не найдены, при этом код завершения команды всегда 0.
   
   

2. Подключение по SSH с аутентификацией по сертификату на токене:

   ssh -I <интерфейсная_библиотека> -l <имя_пользователя> <сервер>

   где:

   • <интерфейсная_библиотека> — библиотека, используемая для работы с токеном;
     

   • <имя_пользователя> — имя доменного пользователя, от которого выполняется подключение;
     

   • <сервер> — имя сервера, к которому выполняется подключение.

Двухфакторная аутентификация клиента Astra Linux (sssd) в домене Windows AD

Предполагается, что ввод клиента в домен Windows AD выполнен с использованием службы sssd (см. Быстрый ввод Astra Linux в AD Windows ).

Для включения двухфакторной аутентификации клиента Astra Linux в домене Windows AD:

1. Установить интерфейсные библиотеки для используемых токенов.
2. Установить пакет opensc.
3. Выполнить настройку в соответствии с разделом Настройка службы sssd на работу с сертификатами.

Рабочие инструменты и отладка

1. Журналы (для доступа к журналам требуются привилегии суперпользователя):
   1. /var/log/sssd/p11_child.log — журнал доступа к ключевым носителям;
   2. /var/log/sssd/sssd_pam.log — журнал подсистемы аутентификации пользователей службы sssd;
   3. /var/log/auth.log — общий системный журнал аутентификации.

2. Прочитать сертификат из подключенного токена и сохранить в формате PEM в файл user.pem:

   pkcs11-tool --module <интерфейсная_библиотека> -r -y cert -a <метка_сертификата> | openssl x509 -in - -inform der -outform pem -out user.pem

3. Загрузить сертификат по ссылке и сохранить в формате PEM в файл root_ca.pem:

   wget '<URL_сертификата>' -O - | openssl x509 -in - -inform der -outform pem -out root_ca.pem

Далее предполагается, что:

• Сертификаты загружены в файлы:
  
  • root_ca.pem — сертификат корневого УЦ, которым подписан сертификат промежуточного УЦ. Этот сертификат считается доверенным.
  • sub_ca.pem — сертификат промежуточного УЦ, которым подписан пользовательский сертификат.
  • user.pen — пользовательский сертификат.
• Известен адрес службы проверки сертификатов домена Windows AD. Этот адрес доступен в самих сертификатах, например, http://ca.domain.ru/ocsp.

1. Для просмотра сертификатов:

   • При работе в графическом режиме можно использовать инструмент gcr-viewer.

   • При работе в командной строке можно использовать инструмент openssl:

     openssl x509 -noout -text -inform pem -in user.pem
     подробнее см. документацию openssl.

2. Проверка валидности цепочки сертификатов:
   

   1. Проверка валидности пользовательского сертификата:

      openssl verify -no-CAfile -no-CApath -partial_chain -trusted sub_ca.pem user.pem

   2. Проверка валидности промежуточного сертификата:

      openssl verify -no-CAfile -no-CApath -partial_chain -trusted root_ca.pem sub_ca.pem

3. Проверка работы подсистемы p11_child службы sssd может быть выполнена непосредственным вызовом этой службы (при этом должен быть подключен токен с сертификатом).:

   1. Без проверки сертификата по протоколу OCSP:

      1. В Astra Linux Special Editin 1.8 исполняемый файл располагается в каталоге /usr/libexec/sssd/p11:

         sudo /usr/libexec/sssd/p11 --pre -d 0x7660 --debug-fd=2 --ca_db=/etc/sssd/pki/sssd_auth_ca_db.pem --verify=no_ocsp

      2. В более ранних обновлениях исполняемый файл располагается в каталоге /usr/lib/x86_64-linux-gnu/sssd/p11_child:

         sudo /usr/lib/x86_64-linux-gnu/sssd/p11_child --pre -d 0x7660 --debug-fd=2 --ca_db=/etc/sssd/pki/sssd_auth_ca_db.pem --verify=no_ocsp
         Далее примеры приводятся для Astra Linux Special Edition 1.8.

   2. С проверкой сертификата по протоколу OCSP:

      sudo /usr/libexec/sssd/p11 --pre -d 0x7660 --debug-fd=2 --ca_db=/etc/sssd/pki/sssd_auth_ca_db.pem
      Если при проверке сертификата по протоколу OCSP возникает ошибка Error: unauthorized (6), то, вероятно, служба OCSP Windows AD не поддерживает расширение запросов nonce. Убедиться в этом можно с помощью openssl:

      1. Проверка работы службы OCSP с помощью openssl б ез использования расширения nonce :

         openssl ocsp -issuer /etc/sssd/pki/sssd_auth_ca_db.pem -cert user.pem -text -url http://ca.domain.ru/ocsp

      2. Проверка работы службы OCSP с помощью openssl с использованием расширения nonce:

         openssl ocsp -issuer /etc/sssd/pki/sssd_auth_ca_db.pem -cert user.pem -text -url http://ca.domain.ru/ocsp -no_nonce

4. Если служба OCSP Windows AD не поддерживает расширение запросов nonce, то следует выполнить одно из следующих действий:

• • на контроллере Windows AD — включить поддержку расширения nonce;

  • на клиенте — отключить использование OCSP в конфигурации sssd, указав в секции [sssd] параметр:

    certificate_verification = no_ocsp

Двухфакторная аутентификация для получения билетов Kerberos

1. Установить пакет krb5-pkinit:

   sudo apt install krb5-pkinit

2. В файл /etc/krb5.conf в секцию [libdefaults] или в группу параметров домена в секции [realms] добавить:

   1. Строки с указанием интерфейсных модулей (указанные модули будут применяться последовательно в порядке их указания):
      

      pkinit_identities = PKCS11:/usr/lib/librtpkcs11ecp.so
      pkinit_identities = PKCS11:/usr/lib/libjcPKCS11-2.so

   2. Строку с указанием расположения сертификатов доверенных УЦ в формате PEM. В домене FreeIPA такая строка добавляется автоматически при вводе в домен. Для указания цепочек сертификации опция может быть добавлена несколько раз.  Пример строки:
      

      pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-top-bundle.pem
      pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-sub-bundle.pem

       

   3. В секцию [libdefaults] добавить параметр:
      

      default_ccache_name = KEYRING:persistent:%{uid}

      Значение этого параметра следует выбирать совпадающим со со значением параметра krb5_ccname_template  в /etc/sssd/sssd.conf.

После выполнения этих действий при выполнении команды получения билетов Kerberos (kinit) будет выполняться:

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

Более сложный пример файла /etc/krb5 .conf для использования сертификатов, выпущенных без учета требований Kerberos для аутентификации в домене Windows AD:

[libdefaults]
# Под обозначением <domain> далее понимается имя домена, <REALM> далее понимается имя домена заглавными буквами.
        default_realm = <REALM>
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        pkinit_identities = PKCS11:/usr/lib/librtpkcs11ecp.so
# Цепочка сертификатов для проверки пользовательского сертификатов. Они могут быть расположены в любом месте, для примера выбран каталог /etc/krb5/
        pkinit_anchors = FILE:/etc/krb5/root_ca.pem
        pkinit_anchors = FILE:/etc/krb5/sub_ca.pem
# Опция проверки пользовательского сертификата: принимать сертификаты с опцией id-kp-serverAuth
# (см. man krb5.conf и http://tools.ietf.org/html/rfc4556.html).
        pkinit_eku_checking = kpServerAuth
# Опция проверки пользовательского сертификата: принимать сертификаты с опцией dNSName SAN (Subject Alternative Name) вместо опции id-pkinit-san
# (см. man krb5.conf и http://tools.ietf.org/html/rfc4556.html)
        pkinit_kdc_hostname = <REALM>
# Автоматически преобразовывать имя домена в имя REALM.
        canonicalize = yes

[plugins]
        localauth = {
                module=sssd:/usr/lib/x86_64-linux-gnu/sssd/modules/sssd_krb5_localauth_plugin.so
                enable_only = sssd
        }

[realms]
        <REALM> = {
                kdc = <REALM>
                default_domain = <REALM>
        }

[domain_realm]
     .<domain> = <REALM>
     <domain> = <REALM>

Для отладки получения билетов Kerberos можно использовать переменную окружения KRB5_TRACE, например, включить вывод подробной отладочной информации в терминал:

• после запуска команды при запросе PIN-кода нажать Ctrl+C, после чего будет запрошен пароль;

• при запуске команды использовать опцию -X 509_user_identity=false:

  kinit -X 509_user_identity=false <имя_пользователя>

Получение UID пользователя по сертификату в домене Windows AD

При наличии настроенной службы SSSD числовой идентификатор пользователя (UID) можно получить через шину D-Bus:

Управление графической пользовательской сессией при использовании ключевых носителей

Механизм управления

Для управления пользовательской сессией в зависимости от подключенных ключевых носителей используется служба csp-monitor. Эта служба:

• Принимает по шине DBus сообщения о входе и выходе пользователей с использованием ключевого носителя, регистрируя активные пользовательские сессии и информацию об использованных для входа ключевых носителях. Сообщения о входе могут передаваться PAM-модулями службы sssd.
• Осуществляет мониторинг подключений и отключений USB-устройств, обрабатывая события, связанные с ключевыми носителями:
  
  • При наличии подключенных ключевых носителей в окне приветствия для графического входа в сессию запрос пароля заменяется запросом ПИН-кода.
  • При отключении ключевого носителя блокирует сессии, для входа в которые был использован этот носитель. Для разблокировки такой сессии пользователь должен подключить ключевой носитель и ввести PIN-код, точно так же, как если бы он сам заблокировал сессию ("Пуск" — "Завершение работы" — "Блокировка") или как если бы сессия была заблокирована по отсутствию активности пользователя.
  • При подключении и отключении ключевых носителей выполняется поиск на подключенных ключевых носителях аутентификационных записей пользователей. В ранних версиях контролируются только токены. Начиная с csp_monitor версии 1.0.8+ci1 контролируется также подключение и отключение смарт-карт. Поиск выполняется в записях, используемых модулем pam-csp, и в сертификатах. В качестве имени пользователя используется значение CN (commonName) поля subj сертификата. Сертификаты, помеченные как сертификаты удостоверяющих центров (basicConstraints = CA:TRUE) игнорируются. Соответствие находящихся в ключевом носителе ключей и сертификатов не проверяется. Имена, которым не соответствуют данные в базе passwd, игнорируются. Обнаруженные имена пользователей сохраняются в файле /etc/X11/fly-dm/token. Далее этот файл может использоваться модулем входа (fly-dmgreet) для отображения списка возможных имен для входа. 

Установка пакетов

Служба csp-monitor представлена пакетом csp-monitor. Установить пакет можно командой:

Настройка службы

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

1. Установить предоставляемый производителем ключевых носителей интерфейсный модуль.

2. Указать используемый интерфейсный модуль в файле /etc/security/pam_csp.conf в секции [global] (если файл не существует,  то создать его). Например, для токенов Аладдин:
   

   [global]
   pkcs11_module = libjcPKCS11-2.so

    

3. Перезапустить службу:
   

   sudo systemctl restart csp-monitor