[RU-NGI] ldap for users on cluster

[Eygene Ryabinkin]

Wed, May 07, 2014 at 03:59:33PM +0400, Victor Kotlyar wrote:
> Хотим перейти на кластере на связку ldap+kerberos для пользователей 
> кластера.
> 
> Вот пришла мысль поинтересоваться, кто-нибудь использует такое (или 
> просто ldap).

Использовали просто LDAP.  Без nscd на узлах не взлетает (вернее,
взлетает, но летит крайне недалеко, ну или нужен охрененный кластер
из LDAP).  По моему мнению в поддержке и эксплуатации легче сделать
заход пользователей на UI по SSH-ключам и синхронизатор учётных записей,
который работает с локальными базами (passwd/group), а не с LDAP.
Это надежнее в смысле значительного снижения влияния центрального сервера,
нагрузки на него и его доступности на работу с клиентами.  А если есть
централизованная файловая система, на которой может лежать базовая
информация о пользователях, то такой синхронизатор становится ещё проще.

YMMV, естественно.


Говорят, что sssd,
  https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Introduction.html
вообще работает хорошо и у него нет некоторых глюков nss_ldap, хотя
мы все пойманные у нас глюки давно починили и засунули в upstream.
Насчёт отсутствия глюков с кешированием (как с nscd, см. ниже -- ничего
не слышал).  Сам не пробовал, поэтому информация -- не 100%.

> Каких бяк следует опасаться при применении этого на Грид кластере, на 
> что обратить внимание? Как стабильно работает? Не глючат ли nfs, afs, 
> dCache, torque pbs...

У нас dCache и AFS не было, остальное работало нормально (и даже
Lustre).  Иногда, правда, виснет nscd с 100% загрузкой CPU на рабочих
узлах, но это легко отлавливается скриптами и простого перезапуска
nscd всегда хватает.  Репликация на кластер из LDAP-серверов в
OpenLDAP работает стабильно (OpenLDAP 2.4, FreeBSD).  Можно использовать
LDAP + SSL и для клиентов, но надо следить за протуханием сертификатов.
Если используются хешированные пароли (SSHA или типа этого) для самого
LDAP, то без SSL я бы не пробовал работать, ибо challenge-response
для них не придумано.


А LDAP + Kerberos зачем?  Простого Kerberos не хватает?

Кстати, если у тебя Kerberos будет использовать LDAP как субстрат для
аутентификации, а дальше будут билетики пробиваться, то всё, что я
говорил выше -- фигня, ибо для аутентификации и авторизации у тебя
будет Kerberos и вся его инфраструктура несимметричной криптографии,
а LDAP -- так, начальная точка входа.

Но если у тебя такая конфигурация будет, то она, в-общем, достаточно
сильно подрывает принцип Kerberos, что пароль никогда не уходит с
клиентской машины и второй его экземпляр существует только на
мега-доверенной машине, выдающей TGT.  С LDAP у тебя может появиться
ещё одна машина, которая будет, фактически, такой же доверенной, как
и AS, а пароль либо передаётся по сети, либо хранится на LDAP в открытом
виде.
-- 
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"

Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.