If this is the incorrect list to discuss nssov on please accept my apologies and point me in the right direction. the docs don't indicate a better place.
First let me start with saying what I am trying to achieve. If there is an alternate way to do this using memberof/dynlist I have not been able to figure it out. I am trying to get host access based on group membership working. Consider the following definition for 2 hosts:
dn: cn=host1,ou=hosts,dc=example,dc=com objectClass: ipHost objectClass: myHostAccessObject cn: host1 ipHostNumber: 10.1.2.3 hostAccessGroup: admins hostAccessGroup: dbas authorizedService: sshd
dn: cn=host2,ou=hosts,dc=example,dc=com objectClass: ipHost objectClass: myHostAccessObject cn: host2 ipHostNumber: 10.2.3.4 hostAccessGroup: hrpeople hostAccessGroup: dbas authorizedService: sshd
The hostAccessGroup refers to the name of a group whose users can access the machine. For example:
dn: cn=admins,ou=access,dc=example,dc=com objectClass: groupOfNames cn: admins member: uid=user1,ou=people,dc=example,dc=com member: uid=user2,ou=people,dc=example,dc=com
dn: cn=dbas,ou=access,dc=example,dc=com objectClass: groupOfNames cn: dbas member: uid=user1,ou=people,dc=example,dc=com member: uid=user3,ou=people,dc=example,dc=com
dn: cn=hrpeople,ou=access,dc=example,dc=com objectClass: groupOfNames cn: hrpeople member: uid=user1,ou=people,dc=example,dc=com member: uid=user4,ou=people,dc=example,dc=com
Given the above, user1, user2 and user3 will be able to access host1, and user1 and user4 will be able to access host2.
It seems to me access based on group membership should be easy to do but I have struggled with it immensely. I am new to LDAP so it is most likely a lack of knowledge on my behalf but I have done a lot of research and have not been able to find a way to do what I want. I know the nssov documentation says the prefered mechanism is to use hostservice, and I would like to, but I can't see how to create an ACL that would implement the above. An alternative would be to use some existing group entry, such as a posixGroup but that has even more complications as the memberUid is just the UID and not a DN for a person.
Given that I can't see a way I would like to propose either extending nssov or perhaps writing a dynacl module that could help implement this. Before I rush off and attempt a design I would like input from this list to see if you think its a worthwhile idea.
Thank you for your time. Kean.
Kean Johnston wrote:
If this is the incorrect list to discuss nssov on please accept my apologies and point me in the right direction. the docs don't indicate a better place.
The nssov docs have no reason to say anything about that. The OpenLDAP mailing list charters are all pretty clear. Software usage questions belong on the -software list. The -devel list is for active OpenLDAP developers discussing OpenLDAP coding issues.
First let me start with saying what I am trying to achieve. If there is an alternate way to do this using memberof/dynlist I have not been able to figure it out. I am trying to get host access based on group membership working. Consider the following definition for 2 hosts:
dn: cn=host1,ou=hosts,dc=example,dc=com objectClass: ipHost objectClass: myHostAccessObject cn: host1 ipHostNumber: 10.1.2.3 hostAccessGroup: admins hostAccessGroup: dbas authorizedService: sshd
dn: cn=host2,ou=hosts,dc=example,dc=com objectClass: ipHost objectClass: myHostAccessObject cn: host2 ipHostNumber: 10.2.3.4 hostAccessGroup: hrpeople hostAccessGroup: dbas authorizedService: sshd
The hostAccessGroup refers to the name of a group whose users can access the machine. For example:
dn: cn=admins,ou=access,dc=example,dc=com objectClass: groupOfNames cn: admins member: uid=user1,ou=people,dc=example,dc=com member: uid=user2,ou=people,dc=example,dc=com
dn: cn=dbas,ou=access,dc=example,dc=com objectClass: groupOfNames cn: dbas member: uid=user1,ou=people,dc=example,dc=com member: uid=user3,ou=people,dc=example,dc=com
dn: cn=hrpeople,ou=access,dc=example,dc=com objectClass: groupOfNames cn: hrpeople member: uid=user1,ou=people,dc=example,dc=com member: uid=user4,ou=people,dc=example,dc=com
Given the above, user1, user2 and user3 will be able to access host1, and user1 and user4 will be able to access host2.
It seems to me access based on group membership should be easy to do but I have struggled with it immensely. I am new to LDAP so it is most likely a lack of knowledge on my behalf but I have done a lot of research and have not been able to find a way to do what I want. I know the nssov documentation says the prefered mechanism is to use hostservice, and I would like to, but I can't see how to create an ACL that would implement the above. An alternative would be to use some existing group entry, such as a posixGroup but that has even more complications as the memberUid is just the UID and not a DN for a person.
The above is not going to work.
Given that I can't see a way I would like to propose either extending nssov or perhaps writing a dynacl module that could help implement this. Before I rush off and attempt a design I would like input from this list to see if you think its a worthwhile idea.
No. There is already a documented way to do group-based access. Adding multiple methods to do approximately the same thing == bloat.
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
Further refinements can of course be made but you should focus on mastering the basics first.
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
On Mon, 12 Apr 2010, Kean Johnston wrote:
Thoughts?
Use sets? http://www.openldap.org/faq/data/cache/452.html and its subcategories (plus, obviously, man page/etc.).
-
Aaron Richton -
Howard Chu -
Kean Johnston