У нас есть 50 машин RH-5 и 70 машин RH-6. Я хочу решить, что нам следует использовать для LDAP:
SSSD доступен в обеих версиях (RHEL5 - sssd 1.5 и RHEL6 - sssd 1.9+)
Последний вариант означает, что машины RHEL5 будут запускать sssd 1.5.
Я бы предпочел среду с тем же программным обеспечением и конфигурацией, насколько это возможно, если только люди не скажут, что sssd действительно лучше для RH-6, а nscd / nslcd действительно лучше для RH-5.
Какой вариант лучше?
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 и множественной аутентификации.