Quanah, hello.
On 6 Feb 2024, at 16:03, Quanah Gibson-Mount wrote:
Questions about slapo-unique aside, this is a horrific way to organize your data tree. I'd strongly advise creating a tree for people, like:
cn=people,dc=example,dc=com
uid=x,cn=people,dc=example,dc=com uid=y,cn=people,dc=example,dc=com
Store what department(s) they belong to as attribute in their user entry.
I take the point, and I certainly wouldn't organise things this way if _I_ were king.
In this case, though, dept1, dept2, and so on, are separate administrative domains, in both IT terms and real bureaucratic ones, and this is an attempt to bring some sort of coherence to a bit of historic anarchy (and yes, there is an ou=staff layer in the middle of the real trees).
Everyone more-or-less agrees on the names and uidNumbers in dept1, but there might be a local 'norman' in both dept2 and dept3, or people in those trees with historically colliding UIDs. The result is that systems in dept2 will acknowledge users in ou=dept1 and ou=dept2, users in dept3 acknowledge ou=dept1 and dept3 but ignore ou=dept2, and so on. I expect that names will soon no longer be created in the deptN trees (pretty please?), in favour of the dept1 tree, and the ou=staff parts of those will atrophy, but I'll be retired by then.
If there's a different way of approaching that particular problem, though, right now is the time for me to be rethinking this, so I'm open to challenge.
Best wishes,
Norman