SSSD is not recognizing the "ldap_user_object_class" configuration, and attempting to search based on "posixAccount"

[Surfrock66]

I have an openLDAP and Kerberos-v5 server on Ubuntu Server 22.04, and an SSSD client running Ubuntu 22.10. The LDAP has a custom schema called "domainAccount". I've configured sssd.conf on the client with the "ldap_user_object_class = domainAccount" configuration, however once I restart sssd, then I run "getent passwd username" per this guide https://ubuntu.com/server/docs/service-sssd-ldap-krb I get no output. If I go to the LDAP server and cat the logs, I see the following:

Dec 23 11:31:33 ldapserver slapd[6070]: conn=2604 fd=44 ACCEPT from IP=clientIP:55434 (IP=0.0.0.0:389)
Dec 23 11:31:33 ldapserver slapd[6070]: conn=2604 op=0 BIND dn="cn=admin,dc=subdomain,dc=domain,dc=com" method=128
Dec 23 11:31:33 ldapserver slapd[6070]: conn=2604 op=0 BIND dn="cn=admin,dc=subdomain,dc=domain,dc=com" mech=SIMPLE bind_ssf=0 ssf=0
Dec 23 11:31:33 ldapserver slapd[6070]: conn=2604 op=0 RESULT tag=97 err=0 qtime=0.000049 etime=0.000158 text=
Dec 23 11:31:33 ldapserver slapd[6070]: conn=2604 op=1 SRCH base="dc=subdomain,dc=domain,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=username))"
Dec 23 11:31:33 ldapserver slapd[6070]: conn=2604 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Dec 23 11:31:33 ldapserver slapd[6070]: conn=2604 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000022 etime=0.000227 nentries=0 text=
Dec 23 11:31:33 ldapserver slapd[6070]: conn=2604 fd=44 closed (connection lost)

When I restart sssd with debug_level 9 on the client, in the log file for the domain block, I see this:

(2022-12-23 11:25:49): [be[subdomain.domain.com]] [sdap_get_map] (0x0400): Option ldap_user_object_class has value domainAccount

So sssd is reading the config in sssd.conf, but does not appear to be respecting it when binding to the ldap server? I'll paste my sssd.conf, though the current state is a snapshot of what has been an extreme iterative process of slinging syntax at it from various guides.

[sssd]
config_file_version = 2
debug_level = 9
domains = subdomain.domain.com

[domain/subdomain.domain.com]
debug_level = 9
cache_credentials = True

id_provider = ldap

ldap_uri = ldap://subdomain.domain.com
ldap_search_base = dc=subdomain,dc=domain,dc=com

ldap_user_object_class = domainAccount
ldap_group_object_class = domainGroup

ldap_default_bind_dn = cn=ldapbinduser,ou=accounts,dc=subdomain,dc=domain,dc=com
ldap_default_authtok = -----
ldap_id_use_start_tls = True
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/subdomain.domain.com.rootca.2032.08.24.pem
ldap_tls_cacertdir = /etc/ssl/certs

auth_provider = krb5

krb5_server = ldapserver.subdomain.domain.com
krb5_kpasswd = ldapserver.subdomain.domain.com
krb5_realm = SUBDOMAIN.DOMAIN.COM

#enumerate = true
#chpass_provider = ldap
#access_provider = ldap
#ldap_search_timeout = 50
#ldap_network_timeout = 60
#ldap_access_order = filter
#ldap_access_filter = memberOf=cn=family,ou=groups,dc=subdomain,dc=domain,dc=com

[Athos Ribeiro (athos-ribeiro)]

Hello,

Thanks for taking the time to report this bug.

Would you mind also providing the full client/server log files (with any sensitive information removed) and also your kerberos/openldap setup (config files, etc)?

I am setting this bug to incomplete for now. Once you provide the requested information, please, set this bug back to new.

[Surfrock66 (surfrock66)]

Ok, it's a ton of config files, but let me see if I can get everything that might be relevant together. I use a custom schema called "domainAccount" and "domainGroup" so let me drop in the ldif/schema files I use to populate the openldap server and all config files in "config.txt" which is attached.

Log files attached for today (and the 22nd for some logs that didn't rotate, which is when I did a lot of testing) and an auth attempt on 12/28/2022 at 8:18AM PST in the logs; if you need others let me know

[Paride Legovini (paride)]

Thanks for providing the full config files. I didn't try to setup a full reproducer, but this does seems to be valid bug. I have to say that we can't be sure of when we'll be able to begin working at this, as the specific setup (custom schema) means that the number of affected systems is likely low.

What can help speeding up the debugging work here is identifying a fix (e.g. in a newer upstream release of sssd), or at least finding out that the bug is not present in an older (or newer) Ubuntu release. Moreover, if the bug is still present in the devel release of Ubuntu (lunar-proposed packages sssd 2.8.1) there is a good chance that the bug is still present in the latest upstream release, so it may be worth filing it upstream [1]. If you do so please let us have a link to the upstream bug. Thanks!

Thanks Andreas (@ahasenack) for having a look at the config and logs.

[1] https://github.com/SSSD/sssd/issues

[Surfrock66 (surfrock66)]

Confirmed that this exists in lunar. I will file a bug upstream.

[Surfrock66 (surfrock66)]

Upstream bug filed: https://github.com/SSSD/sssd/issues/6517

[Surfrock66 (surfrock66)]

They actually had me pull /etc/nsswitch.conf, and that's what the problem was. Per this doc, I didn't mess with that file at all:

https://wiki.ubuntu.com/Enterprise/Authentication/sssd

Specifically from there:

"SSSD automatically modifies the PAM files and /etc/nsswitch.conf with pam-auth-update. You do not need any other NSS or PAM backend such as pam-ldap."

Someone in the other bug suggested pam-ldap was installed after, but gong through my shell history, here's the apt installs in order:

apt install ldap-utils
apt install sssd libpam-sss libnss-sss
apt -y install vim
apt install openssh-server
apt install ldb-tools
apt install authconfig
apt install ldap-auth-config
apt -y install libnss-ldap libpam-ldap ldap-utils
apt -y install sssd-ldap sssd-krb5 ldap-utils krb5-user

I don't know if that's useful, if there's some check to do to make sure that file is in the right state?

The contents of /etc/nsswitch were the following:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: compat systemd ldap
group: compat systemd ldap
shadow: compat
gshadow: files

hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files

protocols: db files
services: db files sss
ethers: db files
rpc: db files

netgroup: nis sss
automount: sss

[Paride Legovini (paride)]

Glad to hear that you fixed your specific issue and thanks a lot for sharing those steps! I couldn't however reproduce the issue starting from a clear Lunar LXD container:

  lxc launch ubuntu-daily:lunar paride-l
  lxc exec paride-l bash

I executed the commands you provided in order and in the the /etc/nsswitch.conf has:

passwd: files systemd sss
group: files systemd sss
shadow: files systemd sss
gshadow: files systemd

No 'ldap' entry for 'passwd'. Could it be that some step is missing?

[Paride Legovini (paride)]

Also note that the Ubuntu Server Guide now lives on Discourse:

  https://discourse.ubuntu.com/t/ubuntu-server-how-to-guides/29950

See the "Network user authentication with SSSD" section.