以下を実現する最も明白な方法は何ですか: サイトには稼働中の AD インフラストラクチャがあり、インフラストラクチャの特定の部分は緊密に結合された GNU/Linux マシンです。AD OU のユーザーは、ou=linux-users,dc=example,dc=comLinux マシンの PAM スタックの DC を使用せずに、AD 資格情報を使用してインフラストラクチャの Linux 部分にログオンできる必要があります。つまり、AD から slapd への POSIX 属性 (uid、gid、homedir、password) による何らかの同期と拡張が必要です。Linux マシンの slapd は OpenLDAP であり、AD のスキーマは POSIX 属性のない Windows 2003 からのものです。
答え1
Ldap 同期コネクタ (LSC)必要に応じて生成された追加属性を追加しながら、AD から OpenLDAP サーバーへの継続的な同期を設定するために使用できます。
ただし、OpenLDAP を設定して BIND 要求を AD サーバーに転送しない限り、AD の資格情報を直接使用することはできません。ただし、その場合は AD インフラストラクチャが利用可能であることが条件となります。
ADの資格情報に頼るのは困難です。資格情報を別の場所に平文で保存するか、バインドにADを使用するか、パスワード同期を設定する必要があるからです。Active Directory パスワード同期オプション。
そのページに記載されていないオプションの 1 つは、ハッシュされたパスワードのリストを AD サーバーからエクスポートすることですが、これは 1 回限りの操作であり、継続的な同期ではありません。
答え2
PAM スタックに AD サーバーを置きたくない特別な理由がありますか? この場合の最善の解決策は、POSIX/RFC2307 属性を AD ユーザーに追加し、pam_ldap/nss_ldap (または nss_ldapd) を AD サーバーに向けることです。
ネットワーク セキュリティや負荷に関する懸念があり、AD を直接クエリできない場合は、OpenLDAP のプロキシ/キャッシュ機能を使用するか、制限付きの AD スレーブを展開して Linux ホストにサービスを提供することができます。
「拡張」アカウントを持つことはお勧めしません。これは、かなり汚いハッキングによって実行できますが、私の経験では、実稼働環境で信頼するにはあまりにも脆弱です。また、これは「1 つの信頼できるソース」パラダイムを破ります。AD が信頼できるアカウント ストアである場合は、POSIX 属性をそこに追加して管理する必要があります。