web-dev-qa-db-ja.com

Active DirectoryとOpenLDAPの同期

ADとOpenLDAPの間でユーザーデータベースを同期する最良の方法を見つけるために、Googleに穴を掘っています。私が達成したいのは、ADにユーザーデータベースを用意し、これらのユーザーをOpenLDAPに伝達して、これらのユーザーが私のすべてのアプリケーション（電子メール、vpn、ファイルサーバー、プリントサーバー、ほぼすべてのオープンソースアプリ）にアクセスできるようにすることです。シングルサインオンデータベースを作成して、すべてのユーザーがWindowsおよびLinuxベースのアプリに同じパスワードを設定できるようにしたいと考えています。また、パスワードが双方向で更新されることも確認したいと思います。これをどのように行うことができるかについての彼の経験を誰かが共有できれば幸いです。ありがとうございました！！

linuxubuntuactive-directoryopenldap
6
linuxcraft

私はプロジェクトのためにこれを一度行いました-頑張ってください！ ADサーバーへの管理アクセス権がありますか？あなたはそれが必要かもしれません。 AD管理者と友達になる:-)

あなたのプロジェクトについてもっと詳しく教えてもらえますか？

問題は、ユーザー/アプリケーションがActiveDirectoryまたはLDAPに対して認証する必要があるだけなのか、それともアプリケーションがActiveDirectoryに格納されているデータにアクセスし、おそらくエントリを拡張または変更する必要があるのか​​です。

認証だけが必要な場合は、Justinが指摘したように、匿名またはパスワードで保護された（あまり価値のないIMHO）バインドアカウントをActiveDirectoryサーバーにインストールするだけです。 ActiveDirectory管理者に相談してください。

ActiveDirectoryのコンテンツを独自のユーザーレコードの基礎として使用し、データを追加または変更する場合は、独自のLDAPサーバーをセットアップする必要がある場合があります（IT部門は、 「彼らの」レコードを変更...）

ActiveDirectoryはLDAPのように見え、似ていますが、主にスキーマに違いがあります。

いくつかの問題が発生します。

  • ADスキーマと属性はLDAP標準とはかなり異なります
  • 特に、私が理解していることから、すべてのMicro $ oftアプリケーションは特定のスキーマを必要とするため、ADスキーマは多少事前定義され、修正されています...
  • lDAPの場合と同様に、ADにはデフォルトで匿名アクセスが設定されていない可能性があります（これにより、コマンドラインでLDAPクエリを実行してテストすることは困難になります）AD管理者に設定を依頼することができます。あなたのために
  • ADにアクセスする認証済みユーザーには、すべてのADレコードやスキーマを表示する権限がない可能性があります

  • ADで一貫性のないレコードが大量に見つかったことを覚えています。間違った組織構造、人々の記録は機械、デバイス、ソフトウェアの記録と混ざり合っている-ぐ!!!!スキーマ全体に散らばっている人のレコード（LDAPスキーマで予想されるように、1つのサブツリーにすべての人のレコードがあるわけではありません）

  • ...完成する...

人やアプリケーションがディレクトリに対して認証するだけでよい場合は、このすべての手間を省く価値はないかもしれません。バインドアカウントを介してADを直接使用する方が良いでしょう。

Openldapコマンドラインツールを使用して、UNIXコマンドラインでActiveDirectoryに対する認証を試みます。これは、プロセスと返されるデータの感覚をつかむのに役立ちます。

古いプロジェクトのメモを見てみましょう。これを更新します

これがお役に立てば幸いです

openLDAPに対して認証するには、組織の「識別名」（dn）、「組織単位」（ou）、認証する人の「共通名」（cn）などの値を知っている必要があります。ここで完全なイントロを与えることはできません...

ここでOpenLDAPのドキュメントを読むのが最善です： http://www.openldap.org/doc/admin24/

コマンドラインで「ldapsearch」を実行して、LDAPをバインド/アクセスできることを確認することをお勧めします。 http://www.openldap.org/software/man.cgi?query=ldapsearch&apropos=0&sektion=0&manpath=OpenLDAP+2.0-Release&format=html

またはIBMサイト： http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahy%2Frzahyunderdn.htm

3
Tilo

調査する価値のあるオプションは、認証にActive Directoryを使用し、承認に既存のOpenLDAPを使用することです。

http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication

上記のドキュメントで述べたように、ユーザー名/パスワードの検証をKerberosに委任できます。実際、与えられた例（14.5.2を参照）は、ADドメインに対して認証するようにこれを設定する方法を示しています。 LDAPクエリを実行するには、DCにバインドできるActive Directoryのユーザーアカウントを設定する必要があります。このユーザーアカウントには、Windowsサーバーにアクセスするためのアクセス許可がなく、機密性の高いセキュリティグループに属している。

お役に立てば幸いです。

1
Justin ᚅᚔᚈᚄᚒᚔ

私の会社でも同じ問題を解決する必要がありました。

Linux中心であるため、パスワードは次のものの間で同期する必要がありました。

  • OpenLDAP shadowAccount userPassword（レガシーPAM/LDAP認証）
  • OpenLDAP sambaSamAccount sambaLMPasswordおよびsambaNTPassword（レガシーNTLM/Samba認証）
  • OpenLDAP krbPrincipalAux krbPrincipalKey（実際のPAM/MIT-Kerberos-V認証）
  • Microsoft Active Directory（サテライトWindowsドメイン）

今、あなたが持っている主な問題はそれです：

  • パスワードは暗号化されてハッシュ化されます（間違いです！）。元のクリアテキストパスワードは、OpenLDAPまたはMicrosoft Active Directoryに保存されているものから回復できません
  • 1つのストレージバックエンドから他のバックエンドに同期できないことを意味します（編集：各バックエンドには独自のハッシュ関数があり、他のバックエンドとの互換性はありません）。
  • つまり、ユーザーがパスワードを変更するときに、すべてのバックエンドですべてのパスワードを同期的に変更する必要があります。これは、クリアテキストのパスワードが手元にあるときだけです
  • 各バックエンドには、パスワードの変更に対処するための独自の不測の事態と複雑さがあることを知っている
  • つまり、各バックエンドに「ネイティブに」パスワードの変更を処理させる必要があります。Kerberosに対応するキー（多くの場合、Kerberosレルムがサポートするアルゴリズムによって異なります）を作成させ、Active Directoryに独自の方法でパスワードを変更させます（つまりオープンソースではなく、Microsoftが必要と判断した場合はいつでも不透明に変更されます）など。

だから私はこれを思いつきました： https://github.com/cedric-dufour/upwdchg ;まもなく：

  • 安全でないユーザーがアクセス可能なフロントエンド（クライアント）で、ユーザーにリクエストパスワードの変更を許可する
  • 安全なprocessingバックエンド（サーバー）-適切な管理権限を持ち、独自の「ネイティブ」メソッドを使用してすべてのバックエンドでパスワード変更を実行します

「ネイティブ」メソッドとは、次のことを意味します。

  • ShadowAccount userPasswordのOpenLDAPパスワード変更（RFC 3062）操作
  • SambaSamAccount sambaLMPasswordおよびsambaNTPasswordのOpenLDAP 'smbk5pwd'オーバーレイ（Kerberosは不可、 'smbk5pwd'はHeimdal Kerberosのみをサポート）
  • MIT Kerberos V管理サーバーとその「kadmin」および「password_change」操作
  • Microsoftは、ADの「unicodePwd」を変更する方法を文書化しています http://support.Microsoft.com/kb/263991
1
Cédric Dufour

私は2年前に同様のプロジェクトを実行しましたが、どこから始め、どのように結末を結ぶかがわからず、同じような立場にありました。

ステップ1：達成したいことを理解し、それを書き留めます。ステップ2：要件が現実的で、完全に達成できるかどうかを確認します。そうでない場合は、どのアイテムを犠牲にしてもかまいません。 （これには長い時間がかかります）。ステップ3：LDAPのプラットフォームを選択します。あなたの場合、あなたはすでに既存のものを持っています。 step4：文書化とテスト。ステップ5：カットオーバー計画は、やりたいことをすべて達成するかどうかに関係なく、スムーズな移行を確実にするためにも最も重要です。私の場合、段階的に行う必要がありました。

上記のコメントを読んでみると、すでにOpenldapが本稼働しているようです。要件は次のようになります。

a）ユーザーがADで同じパスワードポリシーを使用できるようにします。

b）LDAPに自動的に伝播するユーザーアカウント。

Answer to a）PAMパススルーモジュールをLDAPにセットアップして、パスワード認証をDC kerberos。このようにすると、2つの場所でパスワードを維持する必要がなくなります。389-DSLDAPで実行したので、ドキュメントのリンクで十分です。ユーザーが認証されると、PAMモジュールはLDAPにユーザーアカウントが存在するかどうかを確認し、もしそうなら、認証のためにkrb5.soを使ってpasswdをPAMスタックに渡します389-DSのドキュメントも確認してください。

bに答える）準備ができたソリューションを使用する方法を見つけるためにすべてのシリンダーを叩きましたが、何も近づきませんでした。これは、アカウントとグループのスキーマをマッサージする必要があるためです。そこで、同僚の助けを借りて、ユーザーとグループをADからLDAPに同期するためのスクリプトをPerlで作成しました。 fコードの抜粋は here です。

0
Prashanth Sundaram