OK, I finally managed to get a successful login using an ldap access filter. The filter
wasn't the real issue. I noticed from the debug logs in sssd that the DN didn't
look right (cn=compat instead of cn=accounts):
[sdap_save_user] (0x2000): Adding originalDN
[uid=markj,cn=users,cn=compat,dc=ipa,dc=domain,dc=com] to attributes of
[markj(a)ipa.domain.com]
Also noticed this when looking through the logs:
(2021-10-27 21:25:10): [be[ipa.domain.com]] [sdap_get_initgr_user] (0x4000): Receiving
info for the user
(2021-10-27 21:25:10): [be[ipa.domain.com]] [sdap_get_initgr_user] (0x0200): The search
returned 2 entries, need to match the correct one
(2021-10-27 21:25:10): [be[ipa.domain.com]] [sdap_get_initgr_user] (0x4000): Storing the
user
So, the access search looked like this
[sdap_get_generic_ext_step] (0x0400): calling
ldap_search_ext with
[(&(uid=markj)(objectclass=posixAccount)(memberOf=cn=serveraccess,cn=groups,cn=accounts,dc=ipa,dc=domain,dc=com))][uid=markj,cn=users,cn=compat,dc=ipa,dc=domain,dc=com].
These findings seems to suggest that the user account can be found both via ldap, but only
one is correct and sssd is choosing the wrong one, hence the access failure. So, I added
the following to the domain section of sssd.conf and now the search works correctly and I
can now restrict access based on group membership:
ldap_default_bind_dn = uid=admin,cn=users,cn=accounts,dc=ipa,dc=domain,dc=com
I also added the following line, but I don't see any noticeable difference with or
without it so far. Leaving it in there because it might be important for something:
ldap_schema = IPA