Hi, I am trying to authenticate a user on a server (Rocky Linux release 8.9) using the combination of id_provider=files and auth_provider=ldap since our organization's LDAP server does not have a posixAccount object class. It almost works but has an authentication problem, as follows:
1) Failure case (initial binding by a search_id followed by user_id(hogehoge)) /etc/sssd/sssd.conf has the following default_bind_dn for searching a user DN to log in. ldap_default_bind_dn = uid=search_id,ou=System,dc=example,dc=com ldap_default_authtok = password_for_searchid
This initial search binding works fine and returns the user DN to log in, for example, uid=hogehoge,ou=staff,ou=Users,dc=example,dc=com
However, as shown below, the user (hogehoge) cannot be authenticated. /var/log/sssd/sssd_local.log (2024-04-28 21:57:11): [be[local]] [sdap_call_op_callback] (0x20000): [RID#2] Handling LDAP operation [3][server: [xxx.xx.xx.x:636] filter: [(&(uid=hogehoge)(objectclass=inetOrgPerson))] base: [ou=Users,dc=example,dc=com]] took [2.910] milliseconds. (2024-04-28 21:57:11): [be[local]] [sdap_parse_entry] (0x1000): [RID#2] OriginalDN: [uid=hogehoge,ou=staff,ou=Users,dc=example,dc=com]. (2024-04-28 21:57:11): [be[local]] [sdap_parse_entry] (0x0020): [RID#2] Unknown entry type, no objectClasses found!
/var/log/secure Apr 28 21:57:11 server sssctl[1635756]: pam_sss(system-auth:auth): authentication failure; logname=dummy uid=0 euid=0 tty= ruser= rhost= user=hogehoge Apr 28 21:57:11 server sssctl[1635756]: pam_sss(system-auth:auth): received for user hogehoge: 4 (System error)
/var/log/secure says that the authentication ends with "System error(4)", which implies "Unhandled Exception." Meanwhile, the authentication process succeeds without the error by changing the ldap_default_bind_dn from search-only DN to user DN to be logged in, as follows:
2) Success case (initial binding by a user_id(hogehoge)) /etc/sssd/sssd.conf now has the user DN as a default_bind_dn. This is, of course, only for testing and useless for actual operation. ldap_default_bind_dn = uid=hogehoge,ou=staff,ou=Users,dc=example,dc=com ldap_default_authtok = password_for_hogehoge
Now, this setting enables the user (hogehoge) to log in, as follows: /var/log/sssd/sssd_local.log (2024-04-28 21:54:54): [be[local]] [sdap_call_op_callback] (0x20000): [RID#2] Handling LDAP operation [3][server: [xxx.xx.xx.x:636] filter: [(&(uid=hogehoge)(objectclass=inetOrgPerson))] base: [ou=Users,dc=example,dc=com]] took [2.006] milliseconds. (2024-04-28 21:54:54): [be[local]] [sdap_parse_entry] (0x1000): [RID#2] OriginalDN: [uid=hogehoge,ou=staff,ou=Users,dc=example,dc=com]. (2024-04-28 21:54:54): [be[local]] [sdap_parse_range] (0x2000): [RID#2] No sub-attributes for [objectClass] (2024-04-28 21:54:54): [be[local]] [sdap_parse_range] (0x2000): [RID#2] No sub-attributes for [uid]
/var/log/secure also shows no error. Apr 28 21:54:54 server sssctl[1635713]: pam_sss(system-auth:auth): authentication success; logname=dummy uid=0 euid=0 tty= ruser= rhost= user=hogehoge
I would appreciate it if someone could let me know how to correctly use the search-only bind first, as in case 1). This might not be related to the mixed-use of id_provider=files and auth_provider=ldap, though. FYI, the combination of id_provider=files and auth_provider=ldap seems fine; UID and GID are referred correctly from /etc/passwd as in the output of sssctl:
[root@server dummy]# sssctl user-checks hogehoge user: hogehoge action: acct service: system-auth
SSSD nss user lookup result: - user name: hogehoge - user id: 5000 - group id: 1002 - gecos: - home directory: /home/hogehoge - shell: /bin/bash
SSSD InfoPipe user lookup result: - name: hogehoge - uidNumber: 5000 - gidNumber: 1002 - gecos: not set - homeDirectory: /home/hogehoge - loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment: - no env -
The whole /etc/sssd/sssd.conf follows (credential info has been modified): [sssd] debug_level = 9 config_file_version = 2 services = nss, pam, ssh, sudo domains = default, local
[domain/default] ...truncated...
[domain/local] debug_level = 9 id_provider = files auth_provider = ldap chpass_provider = none ldap_search_base = ou=Users,dc=example,dc=com ldap_user_object_class = inetOrgPerson ldap_uri = ldaps://xxx.xxx.xxx.xxx.xxx ldap_default_bind_dn = uid=search_id,ou=System,dc=example,dc=com ldap_default_authtok_type = password ldap_default_authtok = password_for_searchid ldap_id_use_start_tls = False ldap_search_timeout = 3 ldap_network_timeout = 3 ldap_opt_timeout = 3 enumerate = False ldap_connection_expire_timeout = 600 ldap_sudo_smart_refresh_interval = 600 ldap_sudo_full_refresh_interval = 10800 entry_cache_timeout = 1200 cache_credentials = False
[nss] homedir_substring = /home entry_negative_timeout = 20 entry_cache_nowait_percentage = 50 filter_groups = root filter_users = root
[pam] debug_level = 9
[sudo]
[autofs]
[ssh]
FYI, sssd-related rpms installed are the following: sssd.x86_64 2.9.1-4.el8_9.5 @baseos sssd-ad.x86_64 2.9.1-4.el8_9.5 @baseos sssd-client.x86_64 2.9.1-4.el8_9.5 @baseos sssd-common.x86_64 2.9.1-4.el8_9.5 @baseos sssd-common-pac.x86_64 2.9.1-4.el8_9.5 @baseos sssd-dbus.x86_64 2.9.1-4.el8_9.5 @baseos sssd-ipa.x86_64 2.9.1-4.el8_9.5 @baseos sssd-kcm.x86_64 2.9.1-4.el8_9.5 @baseos sssd-krb5.x86_64 2.9.1-4.el8_9.5 @baseos sssd-krb5-common.x86_64 2.9.1-4.el8_9.5 @baseos sssd-ldap.x86_64 2.9.1-4.el8_9.5 @baseos sssd-nfs-idmap.x86_64 2.9.1-4.el8_9.5 @baseos sssd-proxy.x86_64 2.9.1-4.el8_9.5 @baseos sssd-tools.x86_64 2.9.1-4.el8_9.5 @baseos