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の機能に完全に取って代わるものではありません。
Sssdに対するnslcdの主な(状況上の)利点は、パラメーター置換を使用してカスタム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ドキュメントをチェックしたとき(過去6か月以内)、まだこの機能に代わるものはありませんでした。したがって、この機能が、sssdの統合ソリューションの利点を脇に置くのに十分重要であるかどうかに大きく依存します。
SssdはRH-6に対して本当に優れており、nscd/nslcdはRH-5に対して本当に優れていると人々が言っていない限り、私は可能な限り同じソフトウェアと設定の環境を好みます。
SSSDは未来であり、たとえばLDAPサーバーであれば、Kerberos認証とADとの互換性が向上します。
それ以外の場合、nslcdを使用しない理由はありません。ネストされたグループをサポートする十分に新しいバージョンを使用していることを前提として、私の環境では正常に機能します。「nss_nested_groups」オプションを参照してください(使用している場合は、結構です)。
SSSDは未来であり、nslcdよりもはるかに強力です。
SSSDはオフラインマシンでのSSOなどの追加機能を提供できるため、たとえば、ノートブックワークステーションでSSSDを使用すると、ユーザーは認証サーバーに接続していなくても、シングルSigo-Onデーモンを介してログインできます。
ゲームでnslcdとnslcdがsssdで必要とするすべての依存関係を実装する理由はありません。
そして最後に、SSSDはFedoraがホストするプロジェクトです。したがって、RHELでうまく機能するはずです。
追加情報はウェブサイトにあります: http://fedoraproject.org/wiki/Features/SSSD
Webには、AD、LDAP、および複数の認証バックエンドのハウツーがたくさんあります。