Am Mon, Apr 29, 2024 at 03:25:49PM +0900 schrieb [email protected]: > 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
Hi, my first guess would be that the `uid=search_id` object does not have the permissions to read the `objectClass` attribute from other objects. Please check the ACIs on the LDAP server side for this user. HTH bye, Sumit > > 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 -- _______________________________________________ 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
