Форум проекта Pro-LDAP.ru
Интеграция => Учётные записи в *nix системах => Тема начата: Вереск от 22 Май 2013, 21:40:04
-
Кто-нибудь заморачивался сбором информации о способах идентификации? Я вот представляю, что можно через sssd, можно через PAM, а можно через libnss-ldap. Ну это не считая прикручивания LDAP к Kerberos или самописное скриптование. А есть информация толком со сравнением и подробностями?
-
Здравствуйте! Абсолютное большинство людей используют ту систему идентификации/аутентификации, которую предлагает по умолчанию их дистрибутив. Второй вариант -- настройка системы идентификации/аутентификации согласно наиболее понравившемуся/первому попавшемуся howto. Так что не думаю, что где-то можно найти добротный обзор-сравнение таких систем. Я могу немного рассказать о трёх известных мне системах с реализацией привязки к каталогу LDAP: нативные библиотеки nss_ldap и pam_ldap от PADL.com (http://www.padl.com/Contents/OpenSourceSoftware.html), систему nss-pam-ldapd (http://arthurdejong.org/nss-pam-ldapd/) и SSSD от fedora project (http://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/chap-SSSD_User_Guide-Introduction.html).
Надо начать с того, что практически все системы идентификации в Linux и некоторых других ОС используют вызовы NSS, а системы аутентификации почти всех приложений -- систему PAM, поэтому говорить это через PAM, а это -- через sssd, не совсем корректно.
Библиотеки nss_ldap и pam_ldap от PADL.com -- старый и надёжный способ обращения к каталогу, документированный в тысячах howto, оптимизированный под разные движки служб каталогов, словом -- отличная система. Главный недостаток -- при каждой надобности в идентификации любого приложения, при каждом обращении к файловой системе и т.п. происходит запрос в каталог, то есть фактически таких запросов выполняется очень много. Но, во-первых, LDAP-каталоги оптимизированы на чтение, так что для них это не совсем проблема, а во вторых кэширующий демон nscd способен значительно сократить количество таких запросов (правда, порой такое кэширование создаёт курьёзные ситуации, когда при смене пароля пользователь не может сразу аутентифицироваться с новым паролем, но это решается перезапуском nscd).
Система nss-pam-ldapd -- попытка оптимизировать нативные PADL-библиотеки. Фактически, отработка вызовов от систем NSS и PAM была выделена в библиотеки, а обращение к каталогу выполняется отдельным демоном nslcd, который заодно занимается и кэшированием. Плюсов два -- за счёт использования отдельного демона количество соединений, устанавливаемых с каталогом и, соответсвенно, операций подсоединения, сводится к минимуму, ну и за счёт кэширования ряд запросов просто не выполняется, а сразу отдаётся ответ. Кроме того, вместо собственного демона nslcd можно использовать и альтернативные, например наложение OpenLDAP nssov или pynslcd. Подробнее здесь (http://arthurdejong.org/nss-pam-ldapd/README).
Наконец, SSSD -- новомодное решение от RedHat/Fedora, задействующее их концепцию доменов. Тут зашли с другой стороны -- любую идентификацию/аутентификацию (LDAP, Kerberos и др.) выполняют через библиотеки (libpam_sss, libnss_sss) +демон sssd, а к какой подсистеме идентификации обращаться решается уже на уровне настроек демона (sssd.conf). С точки зрения LDAP можно аутентифицироваться из разных каталогов (в предыдущих случаях -- только из одного), кроме того опять же кэширование и даже offline аутентификация (при отсутствии доступа к каталогу по результатам предыдущих попыток аутентификации). Есть возможность настроить прокси-аутентификацию/идентификацию через те же стандартные nss_ldap и pam_ldap. Подробнее здесь (http://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/sect-SSSD_User_Guide-Introduction-SSSD_Features.html). В общем, довльно интересное решение, но будет ли это работать за пределами мира RedHat -- не знаю.
Егор
-
Спасибо! Утащу себе в памятки, чтоб не потерялось.
А в Debian есть и стандартные библиотеки, и редхатовский sssd водится. Значит, должно работать.