So let them edit the host permissions. Delegate the privileges to groups, and give them write access to their respective groups.

...

Irrelevant. Using slapd.conf doesn't preclude delegation of privileges or dynamic updates to privilege memberships.

I have read the admin guide from cover to cover, several times. I am not an LDAP expert (yet) so perhaps some things you take for granted are not obvious to the newcomer. Everything I have read just makes me confused about how the above can work. If you can point me at a relevant place in teh the man pages, or the admin guide, or an example of how this is possible, I will both be very grateful and have a deeper understanding of why this patch isn't necessary.

The documentation says:

Authorization is checked by performing an LDAP Compare operation looking for the PAM service name in the authorizedService attribute. slapd ACLs should be set to grant or deny Compare privilege to the appropriate users or groups as desired.

As the OpenLDAP architect and someone who has been using LDAP for decades, that may seem obvious to you. It is not to others. As I understand that to mean, I would have to have something like:

access to dn.exact="cn=host1,ou=hosts,dc=example,dc=com" attrs=authroizedService by dn="uid=user1,ou=people,dc=example,dc=com" compare by dn=uid=user2,ou=people,dc=example,dc=com" compare by group.exact="cn=somegroup,ou=groups,dc=example,dc=com" compare by * none

which is how I would give access to a group of people as well as individuals.

Now I want to grant special access to user3, who isn't part of any particular group, just a random user who needs access to the host. Now I have to change the above ACL. That ACL is in slapd.conf. How to I delegate being able to give a non-root user permissions to add user3 to that host. How do I delegate a non-root user to set permissions for host2 and host 3 etc.

I realise this may be incorrect but thats how I understand the docs. I am not particularly dumb so if thats what I took away from the docs, chances are others did too, and at best, the documentation needs beefing up.

On the contrary - for security management, it's the BEST thing. Keeping your authorization rules scattered across the data space not only makes it harder to administer, it also makes it easier to subvert. Keeping it all isolated in a single administrative space negates both of those problems.

Clearly you have never worked in an organisation with several tens or even hundreds of thousands of users. I don't see how putting everything in the one place helps at all. In fact it makes it a bottleneck of the worst kind. But being able to partition things and giving team A responsibility over access to this group of hosts and team B responsibility over that group of hosts and having the host access and authorization information actually be in the host entry just makes more sense, and it scales better.