職場のアクセスサーバーとソースコードを管理するための可能なツールとしてLDAPにアクセスします。ユーザーとマシンをエンティティとして表す、属性を作成する、どの属性を定義するかなどの基本的な概念を理解することができました。適用されたobjectClassesに基づいてエンティティに適用しますが、それでも私には意味をなさないエラーがいくつかあります。誰かがそれらの動作を説明するのを手伝ってくれることを願っています。
ou
(組織単位)が何であるかを理解でき、人々をその中に入れ、groupOfNamesクラスを使用してメンバーのコンテナーとして機能することを理解できます。 zytraxからのこのLDIFスニペットのように) :
# create FIRST Level groups branch
dn: ou=groups,dc=example,dc=com
objectclass:organizationalunit
ou: groups
description: generic groups branch
# create the itpeople entry under groups
dn: cn=itpeople,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: itpeople
description: IT security group
member: cn=William Smith,ou=people,dc=example,dc=com
# create the hrpeople entry under groups
dn: cn=hrpeople,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: hrpeople
description: Human Resources group
member: cn=Robert Smith,ou=people,dc=example,dc=com
私が求めているのは、次のような擬似コードです。
ou='Projects' /
description: This top level group has a few people in it that can create new groups, and control who's in them
member: cn=Robert Smith,ou=people,dc=example,dc=com
-- somethingsomethingAbitrarilyNestedGroup='project-name'
member: cn=Robert Smith,ou=people,dc=example,dc=com
-- groupOfNames = 'project-name development'
member: cn=Robert Smith,ou=people,dc=example,dc=com
member: cn=Jane Doe,ou=people,dc=example,dc=com
member: cn=server1$,ou=servers,dc=example,dc=com
-- groupOfNames = 'project-name staging'
member: cn=Jane Doe,ou=people,dc=example,dc=com
member: cn=server2$,ou=servers,dc=example,dc=com
高価なクローズドソースツールを使用せずに、利用可能な通常のクラスの中で、ここで任意のグループのネストを行う簡単な方法はわかりませんが、それほど複雑であってはならないように感じます。
これは通常、OpenLDAPなどのツールを使用してどのように行われ、他のLDAPクライアントが正しい権限を持つユーザーとして認証されると、グループメンバーシップを制御できるようになりますか? ?
あなたの質問は少し混乱しています-最初のいくつかの段落の文脈で、「今このグループへのアクセスを許可するための最良の方法は何ですか」という意味がわかりません。
ネストされたグループは非常に単純です。 groupOfNames objectClassを使用している場合は、親グループに別のmember
属性を追加するだけで、値は子グループのDNになります。
擬似コードから:
# Assuming your "groups" OU already exists...
# First create the child groups
dn: cn=project-name development,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: project-name development
member: cn=Robert Smith,ou=people,dc=example,dc=com
member: cn=Jane Doe,ou=people,dc=example,dc=com
member: cn=server1$,ou=servers,dc=example,dc=com
dn: cn=project-name staging,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: project-name development
member: cn=Jane Doe,ou=people,dc=example,dc=com
member: cn=server2$,ou=servers,dc=example,dc=com
# Now create the parent group
dn: 'project-name,ou=groups,dc=example,dc=com'
objectclass: groupofnames
member: cn=Robert Smith,ou=people,dc=example,dc=com
member: cn=project-name staging,ou=groups,dc=example,dc=com
member: cn=project-name development,ou=groups,dc=example,dc=com
OU内の階層は、実際には、組織の構造に基づいてLDAPツリーを「論理」セグメントに分割することだけです。したがって、たとえば、「開発部門」を管理するためにすべてのグループを独自のOUに固定することができます。これにより、グループが何に関係するかが明確になります。オブジェクトは、適切な属性(この場合はmember
)を使用して相互に参照することにより、相互に参照し、非常に幸せにネストできます。
ユーザーオブジェクトを参照するときは、uid=
ではなくcn=
を使用する必要があると思います。
ネストされたグループで私が抱えている問題は、グループを参照できる多くのアプリケーションが、ネストされたグループでメンバーオブジェクトを検索する方法に精通していないことです。