Hi,
Thank you for your quick response. Yes, that was the reason. In this regard, let me allow to add the following question.
Is there any way to remove objectClass from the filter, such as to be (uid=hogehoge) but not (&(uid=hogehoge)(objectclass=inetOrgPerson)) as in the failure case?
Even though I tried to remove the objectclass filter in sssd.conf, I couldn’t. Removing “ldap_user_object_class" statement in [domain/local] automatically gives the following: (&(uid=hogehoge)(objectclass=posixAccount)) (as mentioned before, posixAccount is not used in the LDAP database.) Or, is the declaration of objectclass mandatory in the filter? I would greatly appreciate any assistance.
2024/04/29 19:55、Sumit Bose sbose@redhat.comのメール:
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)