#3451 When sssd is configured with id_provider proxy and auth_provider ldap, login fails if the LDAP server is not allowing anonymous binds.
Closed: Fixed 2 years ago Opened 3 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1459609

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Description of problem:
When sssd is configured with id_provider proxy and auth_provider ldap, login
fails if the LDAP server is not allowing anonymous binds.

Version-Release number of selected component (if applicable):
All

How reproducible:
Always

Steps to Reproduce:
1. Configure sssd with id_provider proxy and auth_provider ldap. Make sure LDAP
server is not allowing anonymous binds. i.e:

# cat /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
debug_level = 10
domains = ds
services = nss, pam

[nss]
debug_level = 10

[pam]
debug_level = 10

[domain/ds]
auth_provider = ldap
case_sensitive = false
chpass_provider = ldap
debug_level = 10
id_provider = proxy
ldap_default_authtok = <pw>
ldap_default_bind_dn = <dn>
ldap_id_use_start_tls = false
ldap_search_base = <dn>
ldap_tls_reqcert = never
ldap_uri = URI
ldap_user_object_class = person
proxy_lib_name = files

2. Now try to login as an user.

3. Login will fail with (system error 4) and following can be seen in
sssd_domain logs during that time.

-------
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_search_user_next_base]
(0x0400): Searching for users with base [REDACTED]
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_print_server] (0x2000):
Searching 1.2.3.4:636
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with
[(&(uid=gmiralla)(objectclass=person))][REDACTED].
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [objectclass]
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [uid]
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_get_generic_ext_step] (0x2000):
ldap_search_ext called, msgid = 1
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_op_add] (0x2000): New operation
1 timeout 6
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_process_result] (0x2000):
Trace: sh[0x7fb1249e4e20], connected[1], ops[0x7fb125211160],
ldap[0x7fb1249dd7c0]
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_process_result] (0x2000):
Trace: end of ldap_result list
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_process_result] (0x2000):
Trace: sh[0x7fb1249e4e20], connected[1], ops[0x7fb125211160],
ldap[0x7fb1249dd7c0]
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_process_result] (0x2000):
Trace: end of ldap_result list
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_process_result] (0x2000):
Trace: sh[0x7fb1249e4e20], connected[1], ops[0x7fb125211160],
ldap[0x7fb1249dd7c0]
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_process_result] (0x2000):
Trace: end of ldap_result list
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_process_result] (0x2000):
Trace: sh[0x7fb1249e4e20], connected[1], ops[0x7fb125211160],
ldap[0x7fb1249dd7c0]
(Thu May 11 15:03:52 2017) [sssd[be[ds]]] [sdap_process_result] (0x2000):
Trace: end of ldap_result list
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [sdap_process_result] (0x2000):
Trace: sh[0x7fb1249e4e20], connected[1], ops[0x7fb125211160],
ldap[0x7fb1249dd7c0]
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [sdap_process_message] (0x4000):
Message type: [LDAP_RES_SEARCH_RESULT]
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [sdap_get_generic_op_finished]
(0x0400): Search result: Success(0), no errmsg set
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [sdap_op_destructor] (0x2000):
Operation 1 finished
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [sdap_search_user_process] (0x0400):
Search for users, returned 0 results.
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [get_user_dn_done] (0x0040): No such
user
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [sdap_handle_release] (0x2000):
Trace: sh[0x7fb1249e4e20], connected[1], ops[(nil)], ldap[0x7fb1249dd7c0],
destructor_lock[0], release_memory[0]
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [remove_connection_callback]
(0x4000): Successfully removed connection callback.
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [dp_req_done] (0x0400): DP Request
[PAM Authenticate #3]: Request handler finished [0]: Success
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [_dp_req_recv] (0x0400): DP Request
[PAM Authenticate #3]: Receiving request data.
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [dp_req_destructor] (0x0400): DP
Request [PAM Authenticate #3]: Request removed.
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [dp_req_destructor] (0x0400): Number
of active DP request: 0
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [dp_method_enabled] (0x0400): Target
selinux is not configured
(Thu May 11 15:03:53 2017) [sssd[be[ds]]] [dp_pam_reply] (0x1000): DP Request
[PAM Authenticate #3]: Sending result [4][ds]
-------


Actual results:
Local user is unable to login with his ldap password.

Expected results:
Login should be successful.


Additional info:
This is a known issue with SSSD.
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/
thread/AA7RKAVMFYO4ZDTRKDWHRWOYOADUPBGP/

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1459609

3 years ago

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1459609

3 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.0

3 years ago

Metadata Update from @jhrozek:
- Issue priority set to: major

3 years ago

Metadata Update from @jhrozek:
- Issue tagged with: bug

3 years ago

Metadata Update from @fidencio:
- Issue assigned to fidencio

3 years ago

Since we are required to release a new upstream tarball no later than Friday Oct-20, I'm moving tickets that will not be closed by that date to the next milestone, 1.16.1

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.1 (was: SSSD 1.16.0)

3 years ago

Since we are required to release a new upstream tarball no later than Friday Oct-20, I'm moving tickets that will not be closed by that date to the next milestone, 1.16.1

Metadata Update from @fidencio:
- Custom field patch adjusted to on

3 years ago

master:

Metadata Update from @lslebodn:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

There seems to be a regression caused by these patches:
https://bugzilla.redhat.com/show_bug.cgi?id=1602172

Metadata Update from @pbrezina:
- Issue status updated to: Open (was: Closed)
- Issue tagged with: regression

2 years ago

Metadata Update from @pbrezina:
- Issue set to the milestone: NEEDS_TRIAGE (was: SSSD 1.16.1)

2 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.4 (was: NEEDS_TRIAGE)

2 years ago

Metadata Update from @fidencio:
- Assignee reset

2 years ago

Metadata Update from @jhrozek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 2.1 (was: SSSD 1.16.4)

2 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4478

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata