Learn more about these different git repos.
Other Git URLs
sssd forgets about the supportedControls retrieved from the rootDSE.
sssd-1.5.1-34.el6.2.x86_64
setup a ldap server with server-side password controls.
see log attached to original BZ
things like password expiration warnings should work
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.
== 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. }}}
rhbz: 726483 => 726438
patch: 0 => 1 status: new => assigned
Fixed by
master: - 83a7d67 - b0b9c38
sssd-1-5: - 723df23 - b3d6f83
resolution: => fixed status: assigned => closed
milestone: SSSD 1.6.0 => SSSD 1.5.12
rhbz: 726438 => [https://bugzilla.redhat.com/show_bug.cgi?id=726438 726438]
Metadata Update from @sgallagh: - Issue assigned to jhrozek - Issue set to the milestone: SSSD 1.5.12
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/1982
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.