TT Lab
Get started
Learn Learning paths Courses

Enterprise Authentication Integration

Designing the Org Tree and Checking Group Integrity

Continue in TT Lab

Goal

You design and load the organization structure (OU) and role groups yourself, reflect personnel transfers, and detect and clean up broken group memberships with a script.

Why it matters

The member of an LDAP group is just a DN string. The server does not check whether that DN actually exists. So when you delete a user, the person's DN remains in the group as is. These broken memberships pile up silently and come back at a permission audit as a finding such as "this group has 12 members but only 9 are actually employed." Another thing — if you move the org chart straight into the tree, the DN changes with every personnel transfer, and every integrated system that used the DN as its link key breaks. What to keep in the tree and what to keep as attributes is the real topic of this lab.

Steps

  1. Preparation: start slapd on 1389 and load 00-base, 10-people, 20-groups, and also /opt/lab/fixtures/auth/ldif/30-legacy.ldif.
  2. Create /root/ldap/org.csv. The first line is ou_name,parent_ou,manager_uid. List 6 or more organizations to place under ou=Org. There must be at least 2 rows (second-level organizations) where parent_ou is not Org, and manager_uid must be a uid that actually exists in the directory.
  3. Write /root/ldap/org.ldif according to the design table. First create ou=Org,dc=labhub,dc=co,dc=kr and place the organizations beneath it. Each entry must be objectClass: organizationalUnit.
  4. Load org.ldif. Under ou=Org there must be as many organizationalUnit entries as the number of rows in the design table.
  5. Create three role groups under ou=Groups. cn=role-admin, cn=role-approver, cn=role-viewer. Each group must have 2 or more member values, and every member DN must be a user that actually exists.
  6. To the member of cn=role-admin, add the DN of cn=role-approver (a nested group).
  7. Move uid=kim from ou=People to one of the organizations under ou=Org. After the move, it must no longer be found at its original location. And also fix the member of the groups that had him as a member to the new DN. The server does not update groups for you. If you leave it, kim's old DN remains as a broken membership, step 7 reports 2 items, and you cannot pass that step.
  8. Create /root/ldap/orgcheck.sh. Among all the groupOfNames entries' member DNs, it finds DNs that do not actually exist and prints them one per line, and if there is even one, it ends with a non-zero exit code. Save the DNs found by running it to /root/ldap/dangling.txt. (One is hiding in a group loaded by 30-legacy.ldif.)
  9. Remove the broken member found in step 7 from its group, and make orgcheck.sh return exit code 0 when run again. The group entry itself must remain.

Notes

Organization structure design table

Create /root/ldap/org.csv. The first line is ou_name,parent_ou,manager_uid. List 6 or more organizations to place under ou=Org. There must be at least 2 rows (second-level organizations) where parent_ou is not Org, and manager_uid must be a uid that actually exists in the directory.

An org chart is not a matter of transcribing the company's organization table as is. If you put an axis with frequent personnel transfers into the DN, the DN keeps changing. What goes in the tree and what goes in attributes/groups is the design.

Write the OU LDIF

Write /root/ldap/org.ldif according to the design table. First create ou=Org,dc=labhub,dc=co,dc=kr and place the organizations beneath it. Each entry must be objectClass: organizationalUnit.

LDIF starts with a dn line and entries are separated by blank lines. organizationalUnit requires the ou attribute. The parent must come first.

Load the organizations

Load org.ldif. Under ou=Org there must be as many organizationalUnit entries as the number of rows in the design table.

A load failure is usually a missing parent entry or a schema violation. If you read the error message as is, it tells you at which DN it stopped.

Create role groups

Create three role groups under ou=Groups. cn=role-admin, cn=role-approver, cn=role-viewer. Each group must have 2 or more member values, and every member DN must be a user that actually exists.

Department groups and role groups are different. Departments change with reorganizations, while roles are work permissions. If you mix the two, permissions collapse with every reorganization.

Nested groups

To the member of cn=role-admin, add the DN of cn=role-approver (a nested group).

You can put the DN of another group in a group's member. But interpreting it is up to the client, so you need to check whether it supports recursive expansion.

Reflect a personnel transfer

Move uid=kim from ou=People to one of the organizations under ou=Org. After the move, it must no longer be found at its original location. And also fix the member of the groups that had him as a member to the new DN. The server does not update groups for you. If you leave it, kim's old DN remains as a broken membership, step 7 reports 2 items, and you cannot pass that step.

A move that changes the DN is done with a modrdn-family operation. When the parent changes, you must also specify the new parent DN.

Detect broken memberships

Create /root/ldap/orgcheck.sh. Among all the groupOfNames entries' member DNs, it finds DNs that do not actually exist and prints them one per line, and if there is even one, it ends with a non-zero exit code. Save the DNs found by running it to /root/ldap/dangling.txt. (One is hiding in a group loaded by 30-legacy.ldif.)

A group's member holds only a DN string, and the server does not enforce that the DN actually exists. You can find out by querying each member DN as the base.

Clean up and re-verify

Remove the broken member found in step 7 from its group, and make orgcheck.sh return exit code 0 when run again. The group entry itself must remain.

Deleting just one attribute value is done with the delete operation of ldapmodify. You must not delete the whole entry.