SSSD / sssd

#1836 Support user credentials in during rebind
Closed: wontfix by pbrezina. Opened by sbose.

Closed: wontfix
Reopen Issue

Currently sdap_rebind_proc() can rebind with a simple-bind only with the default user DN and password as given in the configuration options ldap_default_bind_dn and ldap_default_authtok. This works well for user and group lookups when referrals are present.

Another case where referrals are send is when any kind of modification operation is send to a read-only replica. The only modification on the server SSSD currently support is a password change. Passowrd changes are special because the bind to the LDAP server is not done anonymously or with the default credentials, but with the credentials of the user who would like to change his password. If now a password change request is send to a read-only LDAP server the rebind to the LDAP server mentioned in the referral response is either done anonymously or with the default credentials, depending on the configuration. Both are wrong in this case.

The rebind logic should be enhanced to handle user credentials as well so that in the case described above the correct credentials are used when re-binding to a writable LDAP server.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.12 beta
rhbz: 905619 => [https://bugzilla.redhat.com/show_bug.cgi?id=905619 905619]
type: enhancement => defect

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=905619 (Red Hat Enterprise Linux 7)

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=905619 905619] => [https://bugzilla.redhat.com/show_bug.cgi?id=905619 905619], [https://bugzilla.redhat.com/show_bug.cgi?id=905619 905619]

We tested have workarounds for the most common case which is password change against a read-only replica. Because those workarounds work well, I think we can move this ticket out of 1.14, which is already getting quite full.

changelog: =>
mark: => 0
milestone: SSSD 1.14 beta => SSSD 1.15 beta
review: => 0
sensitive: => 0

Metadata Update from @sbose:
- Issue set to the milestone: SSSD Future releases (no date set yet)

Hi all,

any news on this?

I think this bug is kinda severe as a master/slave ldap-setup is not that unusual. We're using several slaves with one master for load balancing and sssd fails miserably most of the time when trying to update one's password using passwd.

version

sssd-1.15.2-50.el7_4.11.x86_64

how to reproduce

ldap-servers
  1. set up two ldap servers ldap1 and ldap2
  2. configure ldap2 to replicate from ldap1
  3. set updateref on ldap2 to ldap://ldap1
sssd.conf
[domain/foo]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
# connect to ldap2 to force a referral
ldap_uri = ldap://ldap2/
ldap_id_use_start_tls = true
ldap_referrals = true

.

what happens

command line
$ passwd
Current Password: ...
New password: ...
Retype new password: ...
Password change failed. Server message: only authenticated users may
change passwords
passwd: Authentication token manipulation error
passwd: password unchanged

.

ldap2

First, sssd binds to ldap2 using my username and tries a PASSMOD with the given id. ldap2 returns err=10 which is a referral. Good.

ldap2 slapd[49194]: conn=1108 fd=96 ACCEPT from IP=10.10.10.10:51317 (IP=0.0.0.0:389)
ldap2 slapd[49194]: conn=1108 op=0 EXT oid=1.3.6.1.4.1.1466.20037
ldap2 slapd[49194]: conn=1108 op=0 STARTTLS
ldap2 slapd[49194]: conn=1108 op=0 RESULT oid= err=0 text=
ldap2 slapd[49194]: conn=1108 fd=96 TLS established tls_ssf=128 ssf=128
ldap2 slapd[49194]: conn=1108 op=1 BIND dn="uid=me,dc=example" method=128
ldap2 slapd[49194]: conn=1108 op=1 BIND dn="uid=me,dc=example" mech=SIMPLE ssf=0
ldap2 slapd[49194]: conn=1108 op=1 RESULT tag=97 err=0 text=
ldap2 slapd[49194]: conn=1108 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1
ldap2 slapd[49194]: conn=1108 op=2 PASSMOD id="uid=me,dc=example" old new
ldap2 slapd[49194]: conn=1108 op=2 RESULT oid= err=10 text=
ldap2 slapd[49194]: conn=1108 op=3 UNBIND
ldap2 slapd[49194]: conn=1108 fd=96 closed

.

ldap2

Next, sssd connects to ldap1 and binds anonymously. This should not happen, sssd must use my username in order to change my password.

ldap1 slapd[72690]: conn=1117 fd=142 ACCEPT from IP=10.10.10.10:55087 (IP=0.0.0.0:389)
ldap1 slapd[72690]: conn=1117 op=0 EXT oid=1.3.6.1.4.1.1466.20037
ldap1 slapd[72690]: conn=1117 op=0 STARTTLS
ldap1 slapd[72690]: conn=1117 op=0 RESULT oid= err=0 text=
ldap1 slapd[72690]: conn=1117 fd=142 TLS established tls_ssf=128 ssf=128
ldap1 slapd[72690]: conn=1117 op=1 BIND dn="" method=128
ldap1 slapd[72690]: conn=1117 op=1 RESULT tag=97 err=0 text=
ldap1 slapd[72690]: conn=1117 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1
ldap1 slapd[72690]: conn=1117 op=2 PASSMOD                                                                                                                                            
ldap1 slapd[72690]: conn=1117 op=2 RESULT oid= err=8 text=only authenticated users may change passwords
ldap1 slapd[72690]: conn=1117 op=3 UNBIND
ldap1 slapd[72690]: conn=1117 fd=142 closed

Hi all,

still no news on this? :sweat_smile:

-- Phil
Edited by philfry

Metadata Update from @thalman:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

Hi,

not sure if this issue is still relevant in your environment but does adding ldap_chpass_uri = ldap:://ldap1 to the [domain/...] section of sssd.conf help?

bye,
Sumit

Metadata Update from @sbose:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

Hi Sumit,

not sure if this issue is still relevant in your environment but does adding ldap_chpass_uri = ldap:://ldap1 to the [domain/...] section of sssd.conf help?

yes, that's a pretty neat workaround, thanks!

Yet this remains a bug as the sssd-client needs to be aware of the current (rw-)master; a dynamic re-routing of writes is still not possible.

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

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

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/2878

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.
Metadata
None

Candidate to close

None
None
Normal
defect
LDAP Provider
1.9.4
false
false
https://bugzilla.redhat.com/show_bug.cgi?id=905619, https://bugzilla.redhat.com/show_bug.cgi?id=905619
false
false
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.