Hi,
I have recently installed sssd 2.6.3 on Ubuntu 22.04.3 LTS (sssd-ldap, sssd-tools, libsss-sudo packages). I have a very simple OpenLDAP (2.5.16) server running with a basic schema (core, cosine, nis and the sudo.schema from sudo-ldap; the package isn't installed, only the schema from it).
Everything other than sudoers is working fine with sssd on my test client. Here's my sssd.conf:
[sssd] config_file_version = 2 domains = test services = nss, pam, ssh, sudo
[sudo]
[nss]
[pam]
[ssh]
[domain/test] id_provider = ldap auth_provider = ldap chpass_provider = ldap sudo_provider = ldap cache_credentials = False enumerate = False ldap_uri = ldap://ldap ldap_search_base = ou=users,dc=ldap ldap_group_search_base = ou=groups,dc=ldap ldap_sudo_search_base = ou=sudoers,dc=ldap ldap_netgroup_search_base = ou=netgroups,dc=ldap ldap_id_use_start_tls = True ldap_tls_reqcert = demand ldap_tls_cacert = /etc/sssd/ca.crt ldap_group_object_class = posixGroup ldap_sudorule_object_class = sudoRule
nsswitch.conf is correctly set to 'sss files' for most things that I care about (passwd, group, shadow, suders). User lookup works, group lookup works, logins work, netgroup lookups work. All is fine, except sudo rules are not found.
My LDAP tree is bare bones, with four OU's:
ou=users,dc=ldap ou=groups,dc=ldap ou=netgroups,dc=ldap ou=sudoers,dc=ldap
ou=users,dc=ldap has ONE posixAccount in (nuser1). This test account works correctly, can log in, his home directory and password are all correct. ou=groups,dc=ldap has ONE posixGroup in (ldapgroup). This is the primary group of the account from above. It is found and correctly sets the textual name of the users GID, all good. ou=netgroups,dc=ldap has ONE nisNetgroup in (sshhosts), this is intended to map sudo rules to groups of servers, but isn't being used yet. ou=sudoers,dc=ldap has ONE sudoRule in (ssh), which is as follows:
dn: cn=ssh,ou=sudoers,dc=ldap objectClass: top objectClass: sudoRole sudoCommand: ALL description: Access to root role on any host in the Interactive SSH Servers netgroup sudoUser: nuser1 sudoHost: testclient # <--- the name of the single host I have temporarily configured for this test, would normally be +sshhosts sudoRunAs: root cn: ssh
My problem is that this rule is never found by sssd when it starts up and attempts to scrape all of the rules for the host it is on. This is what the sssd log says when I enable debugging:
[sdap_search_bases_ex_next_base] (0x0400): Issuing LDAP lookup with base [ou=sudoers,dc=ldap] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRule)(|(&(!(sudoHost=*))(cn=defaults))(sudoHost=ALL)(sudoHost=testclient)(sudoHost=testclient)(sudoHost=192.168.2.168)(sudoHost=192.168.0.0/16)(SNIP SNIP SNIP LOADS OF IPV6 ADDRESSES HERE)(sudoHost=+*)))][ou=sudoers,dc=ldap]. sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAs] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAs] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsGroup] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_search_bases_ex_done] (0x0400): Receiving data from base [ou=sudoers,dc=ldap] sssd_test.log:(2023-10-29 8:38:39): [be[test]] [sdap_sudo_load_sudoers_done] (0x0200): Received 0 sudo rules
More bizarrely, if I take that ldap_search_ext filter and paste it into my LDAP browser (Apache Directory Studio), I still get no results, even though the damn tree is open, in front of my very eyes! Even if I change the filter so that it is only objectClass=sudoRule, I get no results:
#!SEARCH REQUEST (61) OK #!CONNECTION ldap://boxxy-ldap:389 #!DATE 2023-10-29T08:50:34.262 # LDAP URL : ldap://boxxy-ldap:389/ou=sudoers,dc=ldap?objectClass?sub?(objectClass=sudoRule) # command line : ldapsearch -H ldap://ldap:389 -ZZ -x -D "cn=admin,dc=ldap" -W -b "ou=sudoers,dc=ldap" -s sub -a always -z 1000 "(objectClass=sudoRule)" "objectClass" # baseObject : ou=sudoers,dc=ldap # scope : wholeSubtree (2) # derefAliases : derefAlways (3) # sizeLimit : 1000 # timeLimit : 0 # typesOnly : False # filter : (objectClass=sudoRule) # attributes : objectClass
#!SEARCH RESULT DONE (61) OK #!CONNECTION ldap://ldap:389 #!DATE 2023-10-29T08:50:34.264 # numEntries : 0
.... but cn=ssh,ou=sudoers,dc=ldap (with objectClass=top, objectClass=sudoRule) is there, open, in front of me.
Has anyone any recent experience of implementing sudo.schema in a recent version of OpenLDAP and utilising it from sssd? It feels like slapd doesn't know what a sudoRule object class is... even though I'm doing a "include sudo.schema" in slapd.conf (and without it, the slapadd to import the directory clearly falls over, not knowing sudoHost, sudoUser, sudoRunAs etc). I don't think I have anything wrong in my slapd.conf, either, but am willing to be proven wrong:
include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/sudo.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 tlscacertificatefile /etc/ldap/ca.crt tlscertificatekeyfile /etc/ldap/ldap.key tlscertificatefile /etc/ldap/ldap.crt security tls=1
access to dn.base= by * read
access to attrs=userPassword by self write by anonymous auth by users none
access to * by * read
modulepath /usr/lib/ldap moduleload back_mdb.la database mdb directory /var/lib/ldap suffix dc=ldap maxsize 1073741824 rootdn cn=admin,dc=ldap
John