Hi, I've put a much longer copy of the log here: https://pastebin.com/uT4L7NgW <https://pastebin.com/uT4L7NgW>
I suspect the "insufficient access" message is real; the server is denying us access to the highestCommittedUSN attribute there. I don't know why SSSD should need this; it doesn't seem necessary to authenticate users: https://ldapwiki.com/wiki/Update%20Sequence%20Number#:~:text=Update%20Sequence%20Number%20(USN)%20is,counters%20on%20every%20Domain%20Controller. If it was, logging into web services with credentials from this server wouldn't work either, but it does. Additionally, I now know how to map other attributes into uidNumber and gidNumber, so that won't be a problem. If for whatever reason the way SSSD is written "can't" ignore all these extraneous things it checks for, do you (or anyone else) know of a way to auth + create users from SAML logins? Those are easy/free for us to set up. Thanks, J > On Aug 22, 2022, at 1:07 AM, Sumit Bose <[email protected]> wrote: > > Am Sun, Aug 21, 2022 at 01:24:29AM -0000 schrieb Jarett DeAngelis: >> Hi everyone, >> >> I am trying to get SSSD to auth against an LDAP service provided by an IAM >> SaaS company that goes out of its way to make its LDAP interface as minimal >> as possible. All I want SSSD to do is check usernames and passwords against >> the service (which allows the systems in question to be secured by MFA) and >> grab UIDs and GIDs from two specified attributes in each user object. It >> seems to be able to connect fine, but it seems to choke on some missing >> attributes, as seen in these logs: >> >> ``` >> (2022-08-20 21:17:18): [be[test.ldap]] [sdap_get_generic_op_finished] >> (0x0400): [RID#6930] Search result: Insufficient access(50), no errmsg set >> (2022-08-20 21:17:18): [be[test.ldap]] [sdap_get_generic_op_finished] >> (0x0040): [RID#6930] Unexpected result from ldap: Insufficient access(50), >> no errmsg set > > Hi, > > 'Insufficient access' means that the user > (uid=ldap-bind,ou=users,dc=test,dc=ldap) does not has the needed > permissions to perform the requested operation. Unfortunately the > related request is not part of your log snippet, can you sen more of the > log? > >> * ... skipping repetitive backtrace ... >> (2022-08-20 21:17:18): [be[test.ldap]] [generic_ext_search_handler] >> (0x0020): [RID#6930] sdap_get_generic_ext_recv request failed: [5]: >> Input/output error >> * ... skipping repetitive backtrace ... >> (2022-08-20 21:17:18): [be[test.ldap]] [sdap_get_server_opts_from_rootdse] >> (0x0200): [RID#6930] No known USN scheme is supported by this server! >> (2022-08-20 21:17:18): [be[test.ldap]] [sdap_cli_auth_step] (0x0100): >> [RID#6930] expire timeout is 900 >> (2022-08-20 21:17:18): [be[test.ldap]] [sdap_cli_auth_step] (0x1000): >> [RID#6930] the connection will expire at 1661045538 >> (2022-08-20 21:17:18): [be[test.ldap]] [simple_bind_send] (0x0100): >> [RID#6930] Executing simple bind as: uid=ldap-bind,ou=users,dc=test,dc=ldap >> (2022-08-20 21:17:19): [be[test.ldap]] [simple_bind_done] (0x0080): >> [RID#6930] ldap_parse_passwordpolicy_control failed. > > During the bind the LDAP server returns the data about the server side > password policy in an LDAP control. The function > ldap_parse_passwordpolicy_control() from OpenLDAP's libldap cannot parse > this control and since it might contain information about if the > password is expired and how many grace logins are still left SSSD > currently prefers to fail instead of ignoring the error. If you set > > ldap_library_debug_level = -1 > > in the [domain/...] section of sssd.conf you should get detailed debug > output of libldap which might help to understand why the parsing fails. > > bye, > Sumit > >> (2022-08-20 21:17:19): [be[test.ldap]] [sdap_cli_connect_recv] (0x0040): >> [RID#6930] Unable to establish connection [1432158209]: Internal Error >> * ... skipping repetitive backtrace ... >> (2022-08-20 21:17:19): [be[test.ldap]] [fo_set_port_status] (0x0100): >> [RID#6930] Marking port 636 of server 'test.ldap' as 'not working' >> (2022-08-20 21:17:19): [be[test.ldap]] [fo_set_port_status] (0x0400): >> [RID#6930] Marking port 636 of duplicate server 'test.ldap' as 'not working' >> ``` >> >> sssd.conf is as shown: >> >> [sssd] >> services = nss, pam >> config_file_version = 2 >> domains = test.ldap >> >> [nss] >> >> [pam] >> >> [domain/test.ldap] >> debug_level = 7 >> ldap_id_use_start_tls = True >> cache_credentials = True >> ldap_search_base = ou=users,dc=test,dc=ldap >> id_provider = ldap >> auth_provider = ldap >> chpass_provider = ldap >> access_provider = permit >> #sudo_provider = ldap >> ldap_uri = ldaps://test.ldap >> ldap_default_bind_dn = uid=ldap-bind,ou=users,dc=test,dc=ldap >> ldap_default_authtok = some_good_password >> ldap_user_uid_number = employeeNumber >> ldap_user_gid_number = managerNumber >> ldap_user_name = uid >> ldap_tls_reqcert = allow >> ldap_tls_cacert = /etc/pki/tls/cacert.crt >> ldap_tls_cacertdir = /etc/pki/tls >> ldap_search_timeout = 50 >> ldap_network_timeout = 60 >> #ldap_access_order = filter >> #ldap_access_filter = (objectClass=inetOrgPerson) >> auto_private_groups = true >> >> Can someone help me figure out how to get around this? Open to all solutions >> including doing something with a server in between proxying communications >> between the "broken" LDAP server and our equipment. >> _______________________________________________ >> 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] > <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > <https://fedoraproject.org/wiki/Mailing_list_guidelines> > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > > <https://lists.fedorahosted.org/archives/list/[email protected]> > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > <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
