さまざまな理由で、私は職場で事実上のLDAP管理者になりました。私は仕事でそれを約1年前から学んでいます。ですから、私が物事を説明するとき、物事を行うためのより良い方法を自由に提案してください。
従業員情報を保存しているNovelleDirectoryがあります。主な用途は、MoodleやDrupalなどのさまざまなWebサービスを認証することです。しかし、私はそれを新しい従業員ディレクトリのバックエンドとしても使用しています。すでに複製されていた以上に、データを複製する意味はありませんでした。さらに、従業員ディレクトリは、まさにLDAPが作成されたようなもののように聞こえます。
各オフィスのエントリを作成し、各ユーザーに、そのオフィスのオフィスエントリのdnを参照する属性を設定しました。私が今抱えている問題は、各オフィスが独自の電話番号を持っている可能性が高いということです。したがって、複数のオフィスを持つ従業員(たとえば、複数のキャンパスで働く場合)には、複数の電話番号があります。電話番号は従業員の後に続くので、オフィスのエントリに番号を割り当てることはできません。ですから、「この電話番号はこのオフィス用です」と言う方法が必要です。
これがMySQLデータベースの場合は、必要に応じてマップするテーブルを作成するだけです。
LDAPで使用できる同様の構造はありますか?または同等の方法ですか?
私が話していることの詳細な例を示すために、ここに従業員エントリの疑似ldifがあります。
dn: cn=user,ou=staff,dc=college,dc=edu
officedn: cn=DC107,ou=locations,dc=college,dc=edu
officedn: cn=MAIN222,ou=locations,dc=college,dc=edu
phone: 555-555-5555
phone: 111-111-1111
departmentdn: cn=it,ou=departments,ou=groups,dc=college,dc=edu
departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu
title: web systems admin
title: professor of discrete math
だから、私はどのように関係しますか:officedn: cn=DC107,ou=locations,dc=college,dc=edu
からphone: 555-555-5555
?
またはofficedn: cn=MAIN222,ou=locations,dc=college,dc=edu
からphone: 111-111-1111
?
またはdepartmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu
からtitle: professor of discrete math
?
等々...
関連する場合に備えて、いくつかのメモ:
DN構文1.3.6.1.4.1.1466.115.121.1.12を使用して、オフィスおよび部門のdnのカスタム属性を作成しました。
部門エントリには、objectClasses groupOfNames、nestedGroupAux、およびTopがあります。
オフィスにはobjectClassesがあります。親キャンパスエントリへのカスタムdn参照、ndsLoginProperties、organizationalPerson、Person、およびTopを含むカスタムobjectClassです。
ユーザーエントリは、officesにposixAccountを加えたものと同じです。
他に提供すべき情報はありますか?
https://serverfault.com/a/500129/99647 で説明されているように、メタ情報を含む別のエントリを作成する場合、電話番号ごと、および役職ごとにメタエントリを作成する必要があります。
dn: cn=MAIN222,cn=user,ou=staff,dc=college,dc=edu officedn: cn=MAIN222,ou=locations,dc=college,dc=edu phone: 111-111-1111 departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu title: professor of discrete math departmentdn: cn=it,ou=departments,ou=groups,dc=college,dc=edu title: web systems admin
Webシステム管理者が数学に対応していないことをコンピューターが理解する方法がないため、機能しませんが、数学には対応しています。
質問を投稿する前に、私が考えた方法は、すべてのメタデータのouを作成するようなものでした。ou=metadata,dc=college,dc=edu
次に、各ユーザーのou:ou=userid,ou=metadata,dc=college,dc=edu
次に、部門やオフィスにリンクしている役職と電話番号ごとのエントリ:
`` `dn:cn = jobtitle、ou = userid、ou = metadata、dc = college、dc = edu officedn:cn = DC107、ou = location、dc = college、dc = edu phone:555-555-5555
dn:cn = phonenumber、ou = userid、ou = metadata、dc = college、dc = edu officedn:cn = MAIN222、ou = location、dc = college、dc = edu phone:111-111-1111 `` `
自分のやりたいことを達成するために、それよりもクリーンな方法があることを望んでいました。
同じオブジェクトにofficednと関連情報を含む各ポジションのオブジェクトを作成しないのはなぜですか?
そう:
dn: cn=DC107,cn=user,ou=staff,dc=college,dc=edu
officedn: cn=DC107,ou=locations,dc=college,dc=edu
phone: 555-555-5555
departmentdn: cn=it,ou=departments,ou=groups,dc=college,dc=edu
title: web systems admin
dn: cn=MAIN222,cn=user,ou=staff,dc=college,dc=edu
officedn: cn=MAIN222,ou=locations,dc=college,dc=edu
phone: 111-111-1111
departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu
title: professor of discrete math
このようにして、1つのオブジェクト内の単一の位置に関連するすべてのフィールドを保持し、ユーザーのオブジェクトはコンテナーになります。これにより、任意の数の位置の検索と処理が非常に簡単になります。