I've seem to have noticed a problem with using sssd with LDAP SudoHost's that contain CIDR addresses.
We break our clusters into subnets and each have a few rules explicitly for those systems Lets call them
cluster_a 192.168.1.0/24 cluster_b 192.168.2.0/24 cluster_c1 192.168.3.0/25 cluster_c2 192.168.3.128/25 cluster_d 192.168.4.0/23 cluster_f 192.168.6.0/24
... cluster_z: 192.168.26.0/24
Each one may (or may not) have individual sudoUser / sudoCommand allowing certain groups access.
So in LDAP for cluster b we have for example dn: cn=cluster_b,ou=sudoers,dc=EXAMPLE,dc=COM objectClass: top objectClass: sudoRole cn: cluster_root sudoHost: 192.168.2.0/24 sudoUser: Buser1 sudoUser: Buser2 sudoCommand: su - sap
But then we have few additional sudo rules (mostly for administrators) which encompass that whole group of clusters:
dn: cn=cluster_all,ou=sudoers,dc=EXAMPLE,dc=COM objectClass: top objectClass: sudoRole cn: cluster_all sudoHost: 192.168.0.0/19 sudoUser: Admin1 sudoUser: Admin2 sudoCommand: ALL
This worked fine when just using sudo pointing to our ldap server. As sudo apparently on execution grabs all the rules and figures out if our host is in it. It has been working like this for us for years.
But it is no longer working now that we are attempting to implement sssd caching. Namely because sssd sends an ldap query for sudoHost={ALL, current hostname, current IP, and just the currently used subnet (say 192.168.8.0/24) }. Not all possible larger sub ranges to which it belongs.
We've worked around it for now by putting in all the various subranges we use, but that has made the sudo rules in LDAP really messy and worse always subject to change as we add an delete specialized equipment.
Can someone confirm this behavior?
Kelley Cook wrote:
I've seem to have noticed a problem with using sssd with LDAP SudoHost's that contain CIDR addresses.
We break our clusters into subnets and each have a few rules explicitly for those systems Lets call them
cluster_a 192.168.1.0/24 cluster_b 192.168.2.0/24 cluster_c1 192.168.3.0/25 cluster_c2 192.168.3.128/25 cluster_d 192.168.4.0/23 cluster_f 192.168.6.0/24
... cluster_z: 192.168.26.0/24
Each one may (or may not) have individual sudoUser / sudoCommand allowing certain groups access.
So in LDAP for cluster b we have for example dn: cn=cluster_b,ou=sudoers,dc=EXAMPLE,dc=COM objectClass: top objectClass: sudoRole cn: cluster_root sudoHost: 192.168.2.0/24 sudoUser: Buser1 sudoUser: Buser2 sudoCommand: su - sap
But then we have few additional sudo rules (mostly for administrators) which encompass that whole group of clusters:
dn: cn=cluster_all,ou=sudoers,dc=EXAMPLE,dc=COM objectClass: top objectClass: sudoRole cn: cluster_all sudoHost: 192.168.0.0/19 sudoUser: Admin1 sudoUser: Admin2 sudoCommand: ALL
This worked fine when just using sudo pointing to our ldap server. As sudo apparently on execution grabs all the rules and figures out if our host is in it. It has been working like this for us for years.
But it is no longer working now that we are attempting to implement sssd caching. Namely because sssd sends an ldap query for sudoHost={ALL, current hostname, current IP, and just the currently used subnet (say 192.168.8.0/24) }. Not all possible larger sub ranges to which it belongs.
We've worked around it for now by putting in all the various subranges we use, but that has made the sudo rules in LDAP really messy and worse always subject to change as we add an delete specialized equipment.
Can someone confirm this behavior?
If I understand you correctly you're implementing something like netgroups in sudoHost CIDR values. In general I'd say: use a decent user management to avoid the need for that. ;-)
I'd try to set in sssd.conf:
ldap_sudo_use_host_filter = false
Ciao, Michael.
On 04/23/2016 01:33 PM, Michael Ströder wrote:
Kelley Cook wrote:
I've seem to have noticed a problem with using sssd with LDAP SudoHost's that contain CIDR addresses.
We break our clusters into subnets and each have a few rules explicitly for those systems Lets call them
cluster_a 192.168.1.0/24 cluster_b 192.168.2.0/24 cluster_c1 192.168.3.0/25 cluster_c2 192.168.3.128/25 cluster_d 192.168.4.0/23 cluster_f 192.168.6.0/24
... cluster_z: 192.168.26.0/24
Each one may (or may not) have individual sudoUser / sudoCommand allowing certain groups access.
So in LDAP for cluster b we have for example dn: cn=cluster_b,ou=sudoers,dc=EXAMPLE,dc=COM objectClass: top objectClass: sudoRole cn: cluster_root sudoHost: 192.168.2.0/24 sudoUser: Buser1 sudoUser: Buser2 sudoCommand: su - sap
But then we have few additional sudo rules (mostly for administrators) which encompass that whole group of clusters:
dn: cn=cluster_all,ou=sudoers,dc=EXAMPLE,dc=COM objectClass: top objectClass: sudoRole cn: cluster_all sudoHost: 192.168.0.0/19 sudoUser: Admin1 sudoUser: Admin2 sudoCommand: ALL
This worked fine when just using sudo pointing to our ldap server. As sudo apparently on execution grabs all the rules and figures out if our host is in it. It has been working like this for us for years.
But it is no longer working now that we are attempting to implement sssd caching. Namely because sssd sends an ldap query for sudoHost={ALL, current hostname, current IP, and just the currently used subnet (say 192.168.8.0/24) }. Not all possible larger sub ranges to which it belongs.
We've worked around it for now by putting in all the various subranges we use, but that has made the sudo rules in LDAP really messy and worse always subject to change as we add an delete specialized equipment.
Can someone confirm this behavior?
If I understand you correctly you're implementing something like netgroups in sudoHost CIDR values. In general I'd say: use a decent user management to avoid the need for that. ;-)
I'd try to set in sssd.conf:
Hi,
ldap_sudo_use_host_filter = false
yes, this option should solve your problem. You can also try ldap_sudo_ip to specify what subnets you'd like to fetch, but it probably won't scale well with your environment.
Ciao, Michael.
sssd-users@lists.fedorahosted.org