sssd vs nslcd для RHEL-5/6

sssd - это, пожалуй, более "дальновидный" вариант. В этом смысле другие ответы верны. Тем не менее, sssd не полностью заменяет функции nslcd, вопреки распространенному мнению.

Основное (ситуативное) преимущество nslcd перед sssd заключается в том, что вы можете написать собственный запрос authz с подстановкой параметров:

   pam_authz_search FILTER
          This option allows flexible fine tuning of the authorisation check that should be performed. The search filter specified is executed and if  any  entries
          match, access is granted, otherwise access is denied.

          The  search  filter can contain the following variable references: $username, $service, $ruser, $rhost, $tty, $hostname, $dn, and $uid.  These references
          are substituted in the search filter using the same syntax as described in the section on attribute mapping expressions below.

          For example, to check that the user has a proper  authorizedService  value  if  the  attribute  is  present:  (&(objectClass=posixAccount)(uid=$username)
          (|(authorizedService=$service)(!(authorizedService=*))))

          The default behaviour is not to do this extra search and always grant access.

В последний раз, когда я проверял документацию sssd (в течение последних шести месяцев), этой возможности все еще не было замены. Таким образом, это действительно зависит от того, является ли эта функция достаточно важной, чтобы отложить в сторону преимущества консолидированного решения sssd.

Я бы предпочел среду с тем же программным обеспечением и конфигурацией, насколько это возможно, если только люди не скажут, что sssd действительно лучше для RH-6, а nscd/nslcd действительно лучше для RH-5.

SSSD - это будущее, и вы получите аутентификацию Kerberos и лучшую совместимость с AD, если это, например, ваш сервер LDAP.

В противном случае я не вижу причин не использовать nslcd, он отлично работает в моей среде, если вы используете достаточно новую версию, которая поддерживает вложенные группы - см. Опцию "nss_nested_groups" (если вы используете их, в противном случае вы должны отлично).

SSSD - это будущее и гораздо более мощное, чем nslcd.

SSSD может предоставлять дополнительные функции, такие как SSO на автономных компьютерах, поэтому вы можете, например, использовать SSSD на рабочих станциях ноутбуков, и пользователи смогут войти в систему с помощью Single Sigo-On Daemon даже без подключения к серверу аутентификации.

Нет никакой причины для реализации nslcd и всех зависимостей, которые требуются nslcd с sssd в игре.

И, наконец, SSSD - это хостинг-проект Fedora. Так что должно хорошо играть с RHEL.

Дополнительную информацию можно найти на сайте: http://fedoraproject.org/wiki/Features/SSSD

В Интернете есть множество AD, LDAP и несколько бэкэндов для аутентификации.