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 * ... 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. (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.
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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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%20Sequen....
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 sbose@redhat.com 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 setHi,
'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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
sssd-users mailing list -- sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org mailto:sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o... https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue https://pagure.io/fedora-infrastructure/new_issue
Am Thu, Aug 25, 2022 at 04:55:14PM -0500 schrieb Jarett DeAngelis:
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%20Sequen....
Hi,
I suspect that the 'insufficient access' does not only refer to the 'highestCommittedUSN' attribute but to the whole request to read the rootDSE. Can you try manually if
ldapsearch -H ldaps://test.ldap.test.com -x -b '' -s base
works or returns 'insufficient access' as well?
bye, Sumit
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 sbose@redhat.com 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 setHi,
'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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
sssd-users mailing list -- sssd-users@lists.fedorahosted.org mailto:sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org mailto:sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o... https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org 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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
sssd-users@lists.fedorahosted.org
-
Jarett DeAngelis -
Sumit Bose