Re: (ITS#6487) Nssov pam_authz authorizedUserService

[kean.johnston@gmail.com]

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