На следующем сайте обсуждается, как настроить FreeRADIUS для аутентификации в бэкэнде LDAP (в нем рассказывается, как раскрыть хешированные пароли NT в FreeIPA, чтобы FreeRADIUS мог их прочитать).
https://firstyear.id.au/blog/html/2016/01/13/FreeRADIUS:_Using_mschapv2_with_freeipa.html
Он также не рекомендует использовать вкладки ключей Kerberos для подключения FreeRADIUS к IPA, поскольку при использовании, например, аутентификации PAP,
"FreeRADIUS can either read the NTHash and do a comparison (as above),
or it can directly bind to the LDAP server. This means in the direct
bind case, that the transport may not be encrypted due to the keytab."
С другой стороны, различные руководства FreeRADIUS не рекомендуют использовать LDAP (например, см. Комментарии к сайту с внутренним туннелем по умолчанию, в котором говорится:
# We do NOT recommend using this. LDAP servers are databases.
# They are NOT authentication servers. FreeRADIUS is an
# authentication server, and knows what to do with authentication.
# LDAP servers do not.
Какое обоснование вышеупомянутого утверждения, кроме общего отказа от ответственности?
Может ли кто-нибудь объяснить с точки зрения безопасности плюсы и минусы одного подхода по сравнению с другим?
Я успешно настроил серверную часть LDAP (без KRB) и использую PEAP для аутентификации WiFi. Я хотел бы лучше понять компромиссы безопасности для этого сценария.
Для FreeRADIUS
Комментарий здесь как общий отказ от ответственности и для устранения недостатков FreeRADIUS.
В большинстве случаев вы не знаете, какой DN пользователя должен выполнять привязку. Итак, сначала вам нужно выполнить привязку как анонимный пользователь или с набором привилегированных учетных данных, чтобы выполнить этот поиск и найти DN.
FreeRADIUS не поддерживает отдельные пулы соединений для разных целей, поэтому соединение должно быть восстановлено как аутентифицирующий пользователь.
Это означает, что для аутентификации пользователя в LDAP вы должны выполнить три операции:
Если задержка между LDAP-сервером и RADIUS-сервером велика, это может серьезно ограничить пропускную способность (с точки зрения auth / s), поскольку FreeRADIUS в версиях <= v3.0.x реализует синхронный ввод-вывод.
Нет абсолютно никаких веских причин не использовать операции привязки для аутентификации пользователей, особенно если сервер LDAP использует специализированный внутренний плагин аутентификации для выполнения аутентификации. Неважно, какой был LDAP разработан для. Протокол RADIUS определенно не разработан для международных конфедераций роуминга и туннелирования TLS в многоуровневых схемах аутентификации, но он достаточно хорошо выполняет эти роли.
Для IPA
Связанный вами документ сбивает с толку. Похоже, речь идет об использовании учетной записи службы для привязки через Kerberos (GSSAPI) к серверу LDAP, и из-за недостатков в 389DS GSSAPI не может быть объединен с StartTLS или LDAPS, что означает, когда учетные данные пользователя будут отправлены в clear во время этой второй операции привязки.
Или можно сказать, что, поскольку вы не можете использовать GSSAPI с StartTLS или LDAPS с 389DS, учетные данные будут отправлены в открытом виде, если вы использовали Kerberos для выполнения операции привязки пользователя.
В любом случае я почти уверен, что это ограничение только для 389DS, и что большинство других серверов LDAP будут поддерживать GSSAPI через зашифрованные TLS-соединения LDAP.
В любом случае вам следует НИКОГДА отправить или получить учетные данные в каталог LDAP без использования StartTLS или LDAPS, как говорится в статье:
Сегодня единственный безопасный и гарантированный способ защитить ваши учетные записи - это TLS. Вы должны использовать LDAPS, и это гарантирует, что все коммуникации будут безопасными. Это проще, быстрее и лучше.
Если связь с сервером каталогов является открытой, злоумышленник может легко отследить либо пароль в виде открытого текста, отправляемый на сервер каталогов, либо возвращаемый NTPassword. NTPassword - это всего лишь 16-битная кодировка пароля с прямым порядком байтов, хешированная с помощью MD4, она почти так же хороша, как и открытый текст.
Комментарий:
# We do NOT recommend using this. LDAP servers are databases.
# They are NOT authentication servers. FreeRADIUS is an
# authentication server, and knows what to do with authentication.
# LDAP servers do not.
находится в контексте, где сервер LDAP будет использоваться для аутентификации, а не в качестве базы данных. Это в основном означает, что сервер RADIUS будет пытаться аутентифицироваться на сервере LDAP, используя предоставленные учетные данные. И они справедливо предупреждают вас, что это не та цель, для которой был разработан LDAP.
Теперь, если вы используете LDAP в качестве базы данных, что имеет место в других местах, с этим нет проблем.