> 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.