FreeRADIUS с LDAP против Kerberos
На следующем сайте обсуждается, как настроить 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 вы в конечном итоге выполняете три операции:
- Связывание как привилегированный / анонимный пользователь.
- Поиск DN пользователя.
- Связывание как пользователь.
Если задержка между LDAP-сервером и RADIUS-сервером велика, это может серьезно ограничить пропускную способность (с точки зрения аутентификации / с), поскольку FreeRADIUS в версиях <= v3.0.x реализует синхронный ввод-вывод.
Нет абсолютно никаких веских причин не использовать операции связывания для аутентификации пользователей, особенно если сервер LDAP использует специализированный внутренний плагин аутентификации для выполнения аутентификации. Не имеет значения, для чего был разработан LDAP. Протокол RADIUS определенно не был разработан для международных конфедераций роуминга и туннелирования TLS в многоуровневых схемах аутентификации, но он достаточно хорошо выполняет эти роли.
Для IPA
Документ, на который вы ссылаетесь, сбивает с толку . Похоже, речь идет об использовании учетной записи службы для привязки через Kerberos (GSSAPI) к серверу LDAP, и из-за недостатков в 389DS GSSAPI нельзя комбинировать с StartTLS или LDAPS, что означает, когда учетные данные пользователя будут отправлены в ясно во время этой второй операции привязки.
Или можно сказать, что, поскольку вы не можете использовать 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 в качестве базы данных, а это случай в других местах, с этим нет проблем.