組織図の設計とグループ整合性の点検

目標

組織構造(OU)とロールグループを自分で設計・ロードし、人事異動を反映し、切れたグループメンバーシップをスクリプトで検出して整理できるようになります。

なぜ重要なのか

LDAPグループのmemberは、ただのDN文字列です。そのDNが実際に存在するかどうかを、サーバーは検査してくれません。そのため、ユーザーを削除しても、グループにはその人のDNがそのまま残ります。この切れたメンバーシップは静かに溜まり、権限監査のときに「このグループのメンバーは12人なのに、実際の在籍者は9人」という指摘として返ってきます。もう1つ、組織図をそのままツリーに移すと、人事異動のたびにDNが変わり、DNを連携キーに使っていた連携システムがすべて壊れます。何をツリーにして何を属性にするかが、このラボの本当のテーマです。

ステップ

準備: slapdを1389で起動し、00-base、10-people、20-groups、そして/opt/lab/fixtures/auth/ldif/30-legacy.ldifまでロードしておきます。
/root/ldap/org.csvを作成してください。1行目はou_name,parent_ou,manager_uidです。 ou=Orgの下に置く組織を6個以上書いてください。 parent_ouがOrgではない行(2階層目の組織)が最低2つ必要で、manager_uidは、ディレクトリに実際に存在するuidである必要があります。
設計表どおりに/root/ldap/org.ldifを作成してください。まずou=Org,dc=labhub,dc=co,dc=krを作り、その下に組織を置きます。各エントリはobjectClass: organizationalUnitである必要があります。
org.ldifをロードしてください。ou=Orgの配下に、organizationalUnitが設計表の行数と同じ数ある必要があります。
ou=Groupsの下に、ロールグループを3つ作成してください。 cn=role-admin、cn=role-approver、cn=role-viewerです。各グループはmemberを2人以上持つ必要があり、すべてのmemberのDNは、実際に存在するユーザーである必要があります。
cn=role-adminのmemberに、cn=role-approverのDNを追加してください(ネストしたグループ)。
uid=kimをou=Peopleから、ou=Orgの下にある組織のいずれかに移動させてください。移動後は、元の場所では照会されない必要があります。そして、そのユーザーをmemberとして持っていたグループのmemberも、新しいDNに一緒に修正してください。サーバーはグループを追って修正してくれません。そのままにすると、kimの古いDNが切れたメンバーシップとして残り、ステップ7で2件出てきて、そのステップを通過できません。
/root/ldap/orgcheck.shを作成してください。すべてのgroupOfNamesのmemberのDNのうち、実際に存在しないDNを探して1行に1つずつ出力し、1つでもあれば0以外の終了コードで終了します。実行結果として見つかったDNを、/root/ldap/dangling.txtに保存してください。 (30-legacy.ldifがロードしたグループに、1つ隠れています。)
ステップ7で見つけた切れたmemberを該当グループから削除し、orgcheck.shを再実行したときに終了コード0が出るようにしてください。グループのエントリ自体は残っている必要があります。

参考

エントリの存在確認: ldapsearch -x -H ... -b "<DN>" -s base -LLL "(objectClass=*)" dn
属性の削除: ldapmodifyにchangetype: modify / delete: member / member: <DN>
親まで変える移動: ldapmodrdn -r -s "<새 상위 DN>" "<기존 DN>" "<새 RDN>"(プレースホルダーは新しい親DN、既存のDN、新しいRDNです)
よくあるミス1: 組織図をそのままDNに入れて、人事異動のたびにDNが変わるようにしてしまうことです。
よくあるミス2: groupOfNamesをmemberなしで作ろうとして、スキーマ違反に遭うことです。
よくあるミス3: 切れたメンバーシップを整理すると言って、グループのエントリをまるごと削除することです。

組織構造の設計表

/root/ldap/org.csvを作成してください。1行目はou_name,parent_ou,manager_uidです。 ou=Orgの下に置く組織を6個以上書いてください。 parent_ouがOrgではない行(2階層目の組織)が最低2つ必要で、manager_uidは、ディレクトリに実際に存在するuidである必要があります。

組織図は、会社の組織表をそのまま移すことではありません。人事異動の多い軸をDNに入れると、DNが変わり続けます。何をツリーにして、何を属性/グループにするかが設計です。

OU LDIFの作成

設計表どおりに/root/ldap/org.ldifを作成してください。まずou=Org,dc=labhub,dc=co,dc=krを作り、その下に組織を置きます。各エントリはobjectClass: organizationalUnitである必要があります。

LDIFはdnの行で始まり、空行で区切られます。organizationalUnitはou属性が必須です。親が先に出てくる必要があります。

組織のロード

org.ldifをロードしてください。ou=Orgの配下に、organizationalUnitが設計表の行数と同じ数ある必要があります。

ロードの失敗は、たいてい親のエントリがないか、スキーマ違反です。エラーメッセージをそのまま読めば、どのDNで止まったかがわかります。

ロールグループの作成

ou=Groupsの下に、ロールグループを3つ作成してください。 cn=role-admin、cn=role-approver、cn=role-viewerです。各グループはmemberを2人以上持つ必要があり、すべてのmemberのDNは、実際に存在するユーザーである必要があります。

部署グループとロールグループは違います。部署は組織再編で変わり、ロールは業務の権限です。両者を混ぜると、組織再編のたびに権限が崩れます。

ネストしたグループ

cn=role-adminのmemberに、cn=role-approverのDNを追加してください(ネストしたグループ)。

グループのmemberに、別のグループのDNを入れられます。ただし、これを解釈するのはクライアントの役割なので、再帰展開をサポートしているかの確認が必要です。

人事異動の反映

uid=kimをou=Peopleから、ou=Orgの下にある組織のいずれかに移動させてください。移動後は、元の場所では照会されない必要があります。そして、そのユーザーをmemberとして持っていたグループのmemberも、新しいDNに一緒に修正してください。サーバーはグループを追って修正してくれません。そのままにすると、kimの古いDNが切れたメンバーシップとして残り、ステップ7で2件出てきて、そのステップを通過できません。

DNが変わる移動は、modrdn系の操作で行います。親が変わる場合は、新しい親DNも一緒に指定する必要があります。

切れたメンバーシップの検出

/root/ldap/orgcheck.shを作成してください。すべてのgroupOfNamesのmemberのDNのうち、実際に存在しないDNを探して1行に1つずつ出力し、1つでもあれば0以外の終了コードで終了します。実行結果として見つかったDNを、/root/ldap/dangling.txtに保存してください。 (30-legacy.ldifがロードしたグループに、1つ隠れています。)

グループのmemberにはDN文字列が入っているだけで、そのDNが実際に存在するかどうかをサーバーは強制しません。各memberのDNをbaseとして照会してみればわかります。

整理と再検証

ステップ7で見つけた切れたmemberを該当グループから削除し、orgcheck.shを再実行したときに終了コード0が出るようにしてください。グループのエントリ自体は残っている必要があります。

属性1つだけを削除するには、ldapmodifyのdelete操作を使います。エントリ全体を削除してはいけません。