Using sssd sudo with CIDR addressing

[Kelley Cook]

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?

[Michael Ströder]

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.

[Pavel Březina]

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.