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]
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
