#940 LDAP auth does not check rootDSE for supportedControls
Closed: Fixed None Opened 7 years ago by sgallagh.

Description of problem

sssd forgets about the supportedControls retrieved from the rootDSE.

Version-Release number of selected component (if applicable)

sssd-1.5.1-34.el6.2.x86_64

How reproducible

setup a ldap server with server-side password controls.

Steps to Reproduce

  1. setup 389-ds w/server-side pw controls
  2. create an account and set the password
  3. change the expiration date to within the expiration warning period
  4. turn sssd debugging way up

Actual results

see log attached to original BZ

Expected results

things like password expiration warnings should work

Additional info

irc.freenode.net/#sssd:

<roysjosh> hello all.  I'm having some trouble with LDAP server-side password
policy.  with debugging on, I get: [sdap_control_create] (3): Server does not
support the requested control [1.3.6.1.4.1.42.2.27.8.5.1].  but a search of
supportedControls on the rootDSE shows this control.  this means that I don't
get warnings when passwords are about to expire, etc.
<roysjosh> and further debugging shows sssd getting that control:
[sdap_set_rootdse_supported_lists] (1):  10 : 1.3.6.1.4.1.42.2.27.8.5.1
<roysjosh> sssd-1.5.1-34.el6.2, by the way
<roysjosh> also, for a possible future enhancement, 389-ds returns a control
for expiration notification that sssd doesn't handle: [simple_bind_done] (9):
Server returned control [2.16.840.1.113730.3.4.5].
<roysjosh> I don't think the supported controls are ever copied from the main
connection to the binding connection...?
<roysjosh> I also have debugging in the loop in sdap_check_sup_list which
doesn't print out anything
<sgallagh> sdap_connect_send() is *supposed* to re-request the RootDSE, I
think.
<sgallagh> Let me check
<roysjosh> sdap_cli_connect_send does
<roysjosh> sgallagh, ^
<sgallagh> Ahh, ok.
<sgallagh> I see the problem, then.
<sgallagh> You're right, we should be either re-requesting the RootDSE or
copying it from the original connection.
<sgallagh> roysjosh: Please file a Bugzilla with this information and we'll get
it fixed.

Fields changed

description: == Description of problem ==
sssd forgets about the supportedControls retrieved from the rootDSE.

== Version-Release number of selected component (if applicable) ==
sssd-1.5.1-34.el6.2.x86_64

== How reproducible ==
setup a ldap server with server-side password controls.

== Steps to Reproduce ==
1. setup 389-ds w/server-side pw controls
2. create an account and set the password
3. change the expiration date to within the expiration warning period
4. turn sssd debugging way up

== Actual results ==
see log attached to original BZ

== Expected results ==
things like password expiration warnings should work

== Additional info ==
irc.freenode.net/#sssd:
{{{
<roysjosh> hello all. I'm having some trouble with LDAP server-side password
policy. with debugging on, I get: [sdap_control_create] (3): Server does not
support the requested control [1.3.6.1.4.1.42.2.27.8.5.1]. but a search of
supportedControls on the rootDSE shows this control. this means that I don't
get warnings when passwords are about to expire, etc.
<roysjosh> and further debugging shows sssd getting that control:
[sdap_set_rootdse_supported_lists] (1): 10 : 1.3.6.1.4.1.42.2.27.8.5.1
<roysjosh> sssd-1.5.1-34.el6.2, by the way
<roysjosh> also, for a possible future enhancement, 389-ds returns a control
for expiration notification that sssd doesn't handle: [simple_bind_done] (9):
Server returned control [2.16.840.1.113730.3.4.5].
<roysjosh> I don't think the supported controls are ever copied from the main
connection to the binding connection...?
<roysjosh> I also have debugging in the loop in sdap_check_sup_list which
doesn't print out anything
<sgallagh> sdap_connect_send() is supposed to re-request the RootDSE, I
think.
<sgallagh> Let me check
<roysjosh> sdap_cli_connect_send does
<roysjosh> sgallagh, ^
<sgallagh> Ahh, ok.
<sgallagh> I see the problem, then.
<sgallagh> You're right, we should be either re-requesting the RootDSE or
copying it from the original connection.
<sgallagh> roysjosh: Please file a Bugzilla with this information and we'll get
it fixed.
}}} => == Description of problem ==
sssd forgets about the supportedControls retrieved from the rootDSE.

== Version-Release number of selected component (if applicable) ==
sssd-1.5.1-34.el6.2.x86_64

== How reproducible ==
setup a ldap server with server-side password controls.

== Steps to Reproduce ==
1. setup 389-ds w/server-side pw controls
2. create an account and set the password
3. change the expiration date to within the expiration warning period
4. turn sssd debugging way up

== Actual results ==
see log attached to original BZ

== Expected results ==
things like password expiration warnings should work

== Additional info ==
irc.freenode.net/#sssd:
{{{
<roysjosh> hello all. I'm having some trouble with LDAP server-side password
policy. with debugging on, I get: [sdap_control_create] (3): Server does not
support the requested control [1.3.6.1.4.1.42.2.27.8.5.1]. but a search of
supportedControls on the rootDSE shows this control. this means that I don't
get warnings when passwords are about to expire, etc.
<roysjosh> and further debugging shows sssd getting that control:
[sdap_set_rootdse_supported_lists] (1): 10 : 1.3.6.1.4.1.42.2.27.8.5.1
<roysjosh> sssd-1.5.1-34.el6.2, by the way
<roysjosh> also, for a possible future enhancement, 389-ds returns a control
for expiration notification that sssd doesn't handle: [simple_bind_done] (9):
Server returned control [2.16.840.1.113730.3.4.5].
<roysjosh> I don't think the supported controls are ever copied from the main
connection to the binding connection...?
<roysjosh> I also have debugging in the loop in sdap_check_sup_list which
doesn't print out anything
<sgallagh> sdap_connect_send() is supposed to re-request the RootDSE, I
think.
<sgallagh> Let me check
<roysjosh> sdap_cli_connect_send does
<roysjosh> sgallagh, ^
<sgallagh> Ahh, ok.
<sgallagh> I see the problem, then.
<sgallagh> You're right, we should be either re-requesting the RootDSE or
copying it from the original connection.
<sgallagh> roysjosh: Please file a Bugzilla with this information and we'll get
it fixed.
}}}

Fields changed

rhbz: 726483 => 726438

Fields changed

patch: 0 => 1
status: new => assigned

Fixed by

master:
- 83a7d67
- b0b9c38

sssd-1-5:
- 723df23
- b3d6f83

resolution: => fixed
status: assigned => closed

Fields changed

milestone: SSSD 1.6.0 => SSSD 1.5.12

Metadata Update from @sgallagh:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.5.12

2 years ago

Login to comment on this ticket.

Metadata