Двухфакторная авторизация в MIT Kerberos требовала несколько шагов:

• поддержка FAST для клиента и KDC (1.8)
• поддержка PKINIT с FAST на клиентской стороне (1.10)
• реализация FAST с OTP на клиентской стороне (1.11)
• реализация OTP преаутентификации на стороне KDC (1.11)

Преаутентификация OTP использует проксирование запросов к серверу RADIUS:

[otp]
    <name> = {
        server = <host:port или путь к файлу> ($KDCDIR/<name>.socket)
        secret = <путь к файлу>
        timeout = <число> (5 [секунд])
        retries = <число> (3)
        strip_realm = <true|false> (по умолчанию: true)
    }

SSSD отвечает за идентификацию, аутентификацию и авторизацию пользователей на клиентских машинах в Fedora и Red Hat Enterprise Linux. SSSD также присутствует в Debian GNU/Linux, Ubuntu, openSUSE и других дистрибутивах GNU/Linux.

• SSSD создает канальный ключ на основе TGT указанного в настройках идентификатора Kerberos
• Канал FAST с этим ключем затем используется для обмена дополнительной информацией так, как этого требует KDC
• Запросы, передаваемые KDC, транслируются в запросы диалога PAM и ответы отправляются назад по зашифрованному каналу FAST
• В случае успешной предаутентификации запрашивается TGT для идентификатора пользователя, он заменяет канальный ключ в ccache пользователя
• Поддерживаются все приложения, использующие PAM

• Поддержка FAST доступна в SSSD 1.5.1 (декабрь 2010) и позднее, но она не работает с OTP
• Поддержка OTP требовала специальный механизм в libkrb5 (responder callback), появившийся в MIT Kerberos 1.11 и используемый в SSSD с весны 2013 года
• Обнаружив необходимость OTP, krb5_child в SSSD послыает сообщение о статусе OTP. Это сообщение обрабатывается неправильно в SSSD (ошибка #2186)

Чтобы включить поддержку FAST, необходимо добавить опции в /etc/sssd/sssd.conf:

[domain/<name>]
        krb5_use_fast = try (по умолчанию не используется)
        krb5_fast_principal = host/<hostname>

Управление токенами:

• создание, удаление, ресинхронизация
• распространение пользователям на их устройства (soft-токены) или выдача аппаратных модулей
• KDC и SSSD: “Это не наша проблема”
• KDC делегирует обработку токенов внешнему процессу (RADIUS-сервер)
• Двухфакторная авторизация предполагает, что токен не присутствует на клиентской машине, это принципально для обеспечения безопасности

Управление токенами:

• FreeIPA интегрирует LDAP, Kerberos, DNS, Samba в единое решение с точки зрения администратора
• Токены хранятся в LDAP, выдаются администратором и приписываются пользователям
• FreeIPA предоставляет интегрированный демон проверки OTP, работающий вместе с MIT KDC
• Предварительная версия была интегрирована в Fedora 19, требовала ручную настройку, как описано в Fedora Test Day: 2FA
• Финальная версия будет доступна в FreeIPA 3.4 (Fedora 21)

Демонстрация текущего состояния (Fedora 20 плюс патчи):

• ipa otptoken-{add,del,mod,show}
• веб-интерфейс
• SSH
• sudo/su - <user>
• ldapsearch

Мобильный клиент для софт-токена:

• Google Authenticator
  • Android, iOS 5+, Blackberry
  • Превращен в проприетарный проект с версии 2.22
  • Код последней доступной версии (2.21) лицензирован под Apache License 2.0
• OTP Authenticator
  • Android, недоступен в Google Play
  • Основан на версии 2.21 Google Authenticator
• FreeOTP
  • Android, iOS 5+
  • Основан на версии 2.21 Google Authenticator
  • Активно развивается командой FreeIPA
• ... иные совместимые с Google Authenticator приложения

Интеграция с другими приложениями:

• PAM (pam_sss)
• аутентификация посредством LDAP
• Kerberos FAST
• SAML 2.0 (в процессе разработки)

Объем несделанного для Fedora 21:

• Если разрешено использование и пароля, и OTP, pam_sss не дает войти по паролю (LDAP bind работает)
• Показ QR кода существующего токена пользователю в режиме самообслуживания
• Права доступа в режиме самообслуживания должны разрешать создание новых токенов
• Настройка anonymous PKINIT для OTP "из коробки", чтобы работало получение билетов Kerberos через kinit для обычных пользователей
• Обновление политик SELinux
• Поддержка SAML 2.0