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 -- _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
