The most basic example for your case is access to dn.exact=cn=host1,ou=hosts,... attrs=authorizedService by group.exact=cn=dbas,ou=access,... compare
That is exactly what I currently have. The problem is this. There are multiple hostAccessGroup's possible for each host. Its a list, not a single group. The example you give works only for a single group. I guess it would be possible to list the access groups in the ACL's rather than using an attribute of the host, but that doesn't seem scalable to me. It also has implications of security, as to change a host's access an administrator will need permission to change ACL's which is considerably more "powerful" operation than giving a sysadmin teh ability to add or remove hostAccessGroup (or whatever attribute) from a host entry. It is also moving the data away from where its relevant. The ou=hosts entries are supposed to describe hosts. But this:
access to dn.exact=cn=host1,ou=hosts... attrs=authorizedService by group.exact=cn=dbas,ou=access... compare by group.exact=cn=admins,ou=access.. compare
access to dn.exact=cn-host2.....
access to dn.exact=host3....
etc etc ... seems to be less optimal than:
dn: cn=host1,... hostAccessGroup: dbas hostAccessGroup: admins
dn: cn=host2... ... etc etc.
It also has implications for management tools. In the one case (yours), information about the host is split between the ou=hosts and the ACLs. In the other, all information about the host is in the ou=hosts entry. In a large organisation, I can see considerable problems if a basic sysadmin requires rights to change ACL's (think: can grant himself access to HR attributes) versus just being able to grant or deny access to ssh for a given host.
Thoughts?
Kean